The main slot of the evening was delivered by Georgie Mannion and Kev McCabe as a business analyst and developer duet in perfect harmony singing the praises of cross discipline, and mixed skill level, pairing. They were drawing from their experiences of implementing mandatory pairing across the whole software delivery team starting on the first day of the new year after some radical New Years Day desk restructuring.
Rather than simply encouraging team members to pair when they could they adopted a 3 month period where nearly all activities across the software delivery team were carried out by pairs. There was plenty of discussion during the presentation about the various permutations and strategies adopted to ensure success. Although traditional XP pairing (two people working together with a single computer to solve a problem) was tried, so too were other techniques such as side by side pairing (two people working alongside each other to solve a problem by partition, XP style pairing and frequent close communication) and mob programming (single room, big screen, shared computers with representatives from several disciplines working closely to solve a problem).
The benefits of shorter feedback loops and better quality collaboration were stressed over email ping-pong or large meetings. The business benefit of the experiment was improved knowledge transfer in an environment with a high proportion of contractor staff. There was discussion of an interesting metric in the form of a matrix of skills and knowledge levels by team member and a drive to use pairing to reduce 'skill silo' risks. The experience levels of the participants making up a pair was felt to give different benefits; from exploration in novice-novice pairs through “up-skilling” in expert-average pairs through to crackling productivity in expert-expert pairs. The diversity of perspective was felt to be a particular benefit when pairing across disciplines with the cost of hand-offs between activities reduced.
As Gwen Diagram pointed out at the July meet up the tools an agile team chooses can impact on their ability to shorten feedback loops and increase confidence in making change. Anyone who has had to work with large enterprise tools (looking at you Oracle and Microsoft) will know how hard it is to deploy and test systems using them. Lightweight frameworks from the open source community have been a response to this and Nancy in .NET, along with it's cool Ruby cousin Sinatra, are two such frameworks. Matt McLoughlin gave us a whistle stop tour of some of the features of Nancy such as the conciseness of the resulting code, the fact that testing is a first class citizen of the framework, the simplicity of convention over configuration. All this is summed up by the goal of the Nancy team - keeping to the Super Duper Happy Path. As an agile developer I was encouraged by the idea that the Nancy community is friendly and responsive - qualities we often do not consider when selecting technologies but perhaps we should. Another plus would be Nancy's relaxed attitude to it's friends - want to use ASP.NET MVC and Nancy in the same solution, no problem, thus avoiding the common situation of having to decide which gang you are in and then having to stick with that decision come hell or high maintenance costs.
Write-up by Neil McLaughlin
As always thanks to our sponsors and helpers for their support - the evenings would not be possible without them.
David Evans who, along with his partners at Neuri Consulting including Gojko Adzic, are blazing the trail in the world of Specification by Example (SBE) made some specific commitments at the start of his presentation to improve the artefacts coming out of the SBE process. These artefacts are examples which are in turn tests. He showed us how even when following the guide lines for good examples such as avoiding technical terms, using a formal notation like given/when/then and involving business stakeholders it can still fall short of the mark for a good example by hiding the essence of the business rule in a thicket of superfluous detail. This failure typically comes from having the example focusing on how to test rather than what to test. In a nice slide (full slides available here) which neatly summarised for me how SBE artefacts are more than just tests - they are specifications, tests and living documentation. It also gave a way of thinking about their evolution over their lifetime: SBE artefacts should provide specifications now, regression tests soon and documentation later. He also contrasted the long lived nature of specifications versus the short lived (burn it!) nature of a user story. Working through a number of examples of bad examples (see what I did there!) David brought out the desired qualities for artefacts of Focus, Balance and Contrast and why we should aim for hour-glass shaped scenarios with consistent levels of abstraction. Interestingly these are desirable qualities in all tests not just those of SBE.
In an interesting segment on the often debated topic of whether tests slow down development David made the pithy observation that tests slow down development in the same way that passengers slow down a bus. The speed of the bus (along with the speed of development) is not the point!
The final related segment addressed what will move organisations towards investing more in building a body of tests to support software making comparisons to with the costs of oil exploration. At this point in time the cost of tests is perceived to be high but as organisations start to realise additional value from tests either earlier in the software delivery life-cycle in the form of specifications or later in the form of live documentation then the value of the artefacts to an organisation increases and makes it more likely that time will be invested in building them.
The other half of the antipodean (dynamic) duo presenting on the evening was Gwen Diagram who gave a passionate presentation describing her journey to enlightenment from behind the waterfall into the world of multifunctional teams, close collaboration across the software delivery disciplines and high levels of tester autonomy. She stressed the need for testers to be able to chose their own tools and to not be afraid to ditch tools when they are no longer adding value. There was a lively debate on the issue of whether the testers in a team should all be technical and the need for developers to draw on testers experience and testers to pull in developers to help with test automation.
The lively discussions carried on afterwards in the pub (beers kindly sponsored by Sean Addy of iSourceIT) with both speakers present and actively engaged in the debates
Thanks as always to all our volunteer team who make the event happen and finally thanks to main sponsors Callcredit, Piksel & NewRedo and also to our prize sponsors O'Reilly, JetBRAINS, Manning, Wrox and PluralSight.
See you in August
The Agile Yorkshire Team
"There is no Agile"? A bold statement to make to a group that meets under the name of Agile Yorkshire. Nick McKenna was the main speaker at this month's meetup, sharing with us some of his experiences as a Scrum Coach/Master/Professional. "There is no Agile" becomes an even bolder statement when it is being made by someone whose career is so obviously entrenched in the stuff. The point being made was that the label of 'Agile' does not necessarily mean an organization, project or even person is going to demonstrate the qualities one might expect of something 'Agile'. Nick told us that he had met plenty of Agile teams that don't question why something is done beyond saying 'because that's what we do in DSDM/Scrum...'. Perhaps a 'by the book' style is not right for every team, Nick pondered, showing us of some Agile tools he'd invented for himself which just happened to revolve around delicious, rewarding cups of coffee.
Focusing on Scrum in particular, Nick questions the value of sprints. The fact that a team may only evaluate their productivity once every couple weeks can be very limiting and result in sizeable chunks of work that gets scrapped, which in turn could lead to an unhappy team -- another thing Nick has been saddened to see. To combat team malaise, Nick recommends TINYpulse
, a system for collecting anonymous feedback on the mood of a team via short, snappy surveys.
As a long term observation, Nick has also noticed that the velocity of Agile teams is generally on a downward trend. Another side-effect of time-boxed work, perhaps? An Agile regime can be relentless and draining, with few diversions and little opportunity to branch out and be creative. Nick's cure? Football stickers. Or whatever works for your team, but Nick reckons that a successful Agile team takes time out from work to celebrate their successes as well as regularly considering their shortcomings.
This month's support speaker was Craig Norton who gave us an introduction to Angular JS, an MV* framework used for building single page applications (SPAs). His half hour coding demo saw the construction of a 'ToDo' application based on the Angular-Seed
Thanks again must go to Matthew Wood from iSource, who sponsored the “after-drinks”. Thanks to all our volunteer team who make the event happen and finally thanks to main sponsors Callcredit, Piksel & NewRedo and also to our prize sponsors O'Reilly, JetBRAINS, Manning, Wrox and PluralSight.
See you in July
The Agile Yorkshire Team
Our main speaker this month was Geoff Watts, giving some Agile Yorkshire airtime back to Scrum. Opting to forgo the usual accompaniment of slides, Geoff's face and flipchart were what we expected to look at for the next hour. Not so, we soon learned, as Geoff's presentation quickly had us on our feet lobbing rubber balls about to the tune of a last-letter-first game, a technique he uses to encourage team members to interact with each other more effectively.
As an experienced Scrum Master, Geoff has observed many teams working well (and not so well) together. No two teams are going to be the same, but there are predictable areas to consider when trying to get the best out of any one of them. A certain level of informality helps, Geoff suggests, as people tend to feel more accountable to those they know better. To this end, in another game we tried to make connections between members of small teams formed from the Agile Yorkshire audience. The team I was part of learnt that two of its members were connected by injuries sustained dancing to the music of Pulp! A lifelong bond was formed that night.
Geoff highlighted areas often overlooked in considering why a team is failing to meet its targets -- the targets themselves, for example. Too short a sprint and the team can end up too focused on that short-term goal, killing potential creativity and longer-term success. Then again, short sprints can provide a lot of feedback, building a more resilient, responsive team. Geoff's talk showed that there's a lot to consider in building a good Scrum team, and a good servant-leader should help teams to solve their own problems, getting them to figure out what works best for themselves.
The other speaker for the evening was Agile Yorkshire regular Stew Able, with his talk entitled 'Architecture and Agile'. Good architecture aims to aid the building of effective software but also to give its developers ease of access to extend the system to which it is applied. It can however quickly become muddied by the need to consider cross-cutting concerns like auditing and logging.
Stew posits that architecture is everyone's responsibility, and that team members of all levels of ability should be able to make valuable contributions. Questioning why certain patterns exist in the code base can lead to a better end result and shared understanding of the system amongst more people. Different views of the architecture should exist for the different parties involved, to enable as much contribution and understanding of it as possible. Its documentation should be lean and up to date so it is as inviting to read and as relevant as it can be. Stew's talk made it clear that Agile development at its best has architecture as part of the process, as a system's architecture will certainly affect the work taken on by any Agile team. Stew's slides are available here
Thanks to all in the volunteer team who make the event happen, to our main sponsors Callcredit and Piksel and, finally, to our prize sponsors O'Reilly, JetBRAINS, Manning, Wrox and PluralSight.
Agile Yorkshire has a new sponsor. Piksel have stepped forward to support the Agile Yorkshire community and hence the agile movement in are region. Agile Yorkshire is only able to run in the way it does, attracting some of the best speakers and developing local industry leadership, through the help of sponsors like Piksel. Here's what Piksel have said...
"Piksel is proud to sponsor Agile Yorkshire - to support their mission to champion software development in the region and build a centre of excellence. Piksel has an extensive track record in the delivery of OTT Solutions to some of the world’s largest broadcasters and has been involved in some of the earliest pioneering implementations. Customers include; BSkyB, Liberty Global, OSN and 4oD. Delivering the best in OTT solutions, with the expertise to manage even the most complex integrations, Piksel stands with those redefining the frontiers of viewing.
Piksel's headquartered in New York with offices worldwide. Established in 2001 the UK Head Office is based in York Science Park. With circa 200 involved in software development and managed services, Piksel is an environment where technical people thrive, where they can be hands on and find variety from the breadth of high profile clients. The company continuously invests in new approaches and strives to improve its delivery processes. Piksel looks to Agile Yorkshire as one source of inspiration in a pragmatic approach to project delivery."
Once again a capacity audience of software delivery professionals, drawn from across the disciplines, came together for the monthly Agile Yorkshire meetup.
The number of people arriving early for the great networking opportunity at the start of the evening seems to be increasing and there was already a substantial buzz in the room at 6:30.
The main speaker for the evening was Jose Casal (@jose_casal) who, whilst being based in the south east, is a frequent visitor to Yorkshire for engagements with large and medium sized organisations. These organisation typically want some of the kool-aid associated with progressive software development processes but are often typified by islands of agility in more traditional organisational structures.
Jose asserted that, compared to the industrial revolution, the information revolution has barely started and is currently at the “Model T” stage. He posed the hypothesis that in order for organisations to transform to hyperproductivity then the low levels of efficiency of software delivery teams (given as between 1% and 5%) needs to be addressed. Jose emphasised the impact of people and culture in the transformation process which itself should be evolutionary not revolutionary. There was a lively debate in the Q&A session around the theme of “slack” and how organisations might best build that into their software delivery process. This debate carried on enthusiastically into the pub where the beers were kindly sponsored by iSourceIT.
The support slot for the evening was taken up by Richard Tasker (@ritasker) - an exile from across the Pennines who is now resident in Yorkshire. Richard gave a tour of the different flavours of tools available in .NET for driving software development from examples (aka BDD - Behaviour Driven Development ). In the process he also gave a useful overview of the difference between TDD and BDD, the strengths of each and where BDD adds value to software delivery by clarifying requirements through examples which, in turn, can act as living documentation.
Thanks to all in the volunteer team who make the event happen and finally thanks to our other main sponsors Callcredit and NewRedo and to our prize sponsors O'Reilly, JetBRAINS, Manning, Wrox and PluralSight.
See you next month,
If the audience at this month's Agile Yorkshire is taken to be a reasonable representation of the development community at large, it would seem that most organisations have not roamed far beyond Scrum or Kanban in their approach to Agile. So it was with great interest that many listened to Rachel Davies' experiences as an Agile Coach doing XP (eXtreme Programming) at Unruly. We were warned up front that XP is 'not like Scrum', despite the familiar looking whiteboards and Post-it notes. Unlike Scrum, XP dictates that pair programming is a non-negotiable part of the development process. At Unruly, only a pair of developers working together may make changes to production code, even going to the 'eXtreme' (!) of limiting the number of workstations to fewer than one per person in order to ensure this collaboration takes place. We were assured, thankfully, that their developers do at least get their own chair.
It has not all been without its problems, however. As an exercise in demonstrating that people don't always know what's good for them, a successful change Rachel has been involved with at Unruly has been to break their development teams into smaller units. Though it initially met with some resistance, people soon saw the advantages to working in smaller groups in the form of much more streamlined meetings and the consequent time savings and improvement in communication. With small teams working in relative isolation, Rachel told us that it sometimes became hard to maintain consistency as different development teams began to work in slightly different ways, making it difficult for developers outside of a given team to quickly engage in that team's work. To combat this developers are offered the chance to move between teams on a quarterly basis, sharing knowledge and encouraging consistent cross-team practice along the way.
With no staging environments or test team, Rachel feels that good Test Driven Development is an important part of Unruly's success with XP. Software developers at Unruly are expected to have knowledge of the full development stack, with many of the traditional roles in a development team eschewed in favour of a team of generalists. Requirements are written by developers talking directly to stakeholders within the business, often facilitated by an Embedded Project Manager who can provide direction as to where the knowledge on a particular subject lies in the company. In terms of the organisation of projects -- well, apparently Unruly don't actually have projects. Instead the developers manage a constant stream of imminent potential work, where development time is estimated and stories composed then eventually prioritised in a Story Prioritization meeting with other members of the business.
In this evening's support slot was Ray Edgar, who presented observations of the use of Agile Development in enterprise businesses. Ray has recently been studying to become a BCS Agile Practitioner, giving him an opportunity to reflect on the value of Agile Software Development to the enterprise business. He has found that there is often a discrepancy between 'doing' Agile and working in a way that provides the benefits that Agile Development should. Ask most people what Agile Development is and typically they'll respond with a list of fancy sounding acronyms (SAFe) and initialisms (XP!). What it's really about, Ray argues, is focussing on the business value of development and doing it in a way that provides quick feedback. To some organisations, adopting Agile has amounted to a reshuffling of the business processes that were already in place; losing sight of the benefits a more thorough implementation could bring, they stick to the comfort of the familiar. For this reason, some companies remain unaware that their confused implementation limits the potential advantage they hoped to gain by engaging in Agile Development in the first place. Finally, Ray encouraged the audience to promote some risk-taking in their workplaces, as a failure to make sufficiently drastic changes can leave a business miles behind the competition.
It’s great to announce that iSource IT
, one of Yorkshire most familiar local recruitment companies, will now be sponsoring Agile Yorkshire and contributing to it ongoing success and quality. Agile Yorkshire’s mission is to stimulate innovation in the way organisations create software products for greater commercial effectiveness. By supporting Agile Yorkshire iSource IT are also supporting businesses across the whole region.
iSource IT pride themselves on developing long term relationships and delivering a high quality service through fast, accurate delivery. They operate a vertical model covering all areas of IT and work predominantly with clients across Yorkshire and the North of England. They also founded the Yorkshire Mafia and run the annual Buy Yorkshire business conference."
Matthew Wood from iSource IT commented “I have attended Agile Yorkshire and found it to be a very stimulating event which has allowed me to build my knowledge and network. As a business we’re committed to building our Software & Testing vertical whilst developing the all important relationships which underpin our business. This sponsorship is a natural extension of our commitment to this market and Yorkshire as a region.
On an evening with heavy sleet showers, Agile Yorkshire attendees could have been forgiven for heading to the warmth of their homes. It was, however, fantastic to see yet another packed house. We could have filled the room twice over as for the first time, we saw more names added to the waiting list than places available. This month's first speaker was Andy Burgin, the founder of the Leeds Devops group, speaking on that very topic in the 30 minute slot. Andy was followed by Seb Rose who discussed what makes a unit test good or bad.
Andy took the audience through the history of the devops movement while telling the group about 5 definitions of devops and discussing the problems devops attempts to resolve. It was demonstrated, that as with many development practices, the culture around devops is hugely important. Andy suggested that it is not a good idea to try jumping straight in with automation, but allow a culture to develop which can then be supported with technology.
What makes a unit test good or bad? Seb Rose posed this question, even going as far as asking the entire room to ponder it in silence for a minute! In order to answer the question, Seb discussed why we even write unit tests in the first place. It was discussed that unit tests should be specifications of the code under test, the tests therefore need to read well and become documentation. Seb showed that tests should be repeatable, that they must be necessary; if a test has served it's purpose, and another test covers the same functionality, delete it. The group were shown a number of design patterns which can help to keep tests maintainable and readable.
See you next month,
A few weeks ago I attended an event where James Allen of @Creative_Huddle
ran a session on group creativity techniques. It felt so useful and inspiring (and agile) that talking to him afterwards seemed essential. One thing led to another and James has agreed to visit Agile Yorkshire sometime this year.
In the mean time he has kindly offered a small number of FREE tickets to two of his upcoming events:
Both events are happening in the next few days so you'll need to be available but hey, they're FREE. If you can make it along to either come and grab me at tonight's meetup (Feb 11th) or tweet us a message at @AgileYorkshire
(priority will be given to tonight's attendees).
Also if you'd like to reserve space for other colleagues Creative Huddle have offered Agile Yorkshire attendees a 50% discount code which we'll give out tonight or try tweeting us.