Charitable Agility

The company I work for is big on Corporate Social Responsibility, so over two days last week everyone at Landmark Information Group had the opportunity to do a day’s work for a charity to improve two playgrounds in Bristol. In order to make sure we could still have a business operating over the course of the build we were divided into four groups i.e. one group for each site for each day, where is group consisted of roughly 75 people, and each site had eight different activities. Our organisers engaged a company called Splash Projects who specialise in running team building events and the design for the parks had been done with a great deal of input from the children who use them.

Ok, so what does this have to do with Agile? Well, like many things in life, it’s there if you look for it.

Team sizes ranged from four to thirteen people from Landmark, so not always the optimum Scrum team size, and one member of the Splash team with a member of staff from the charity on-hand all day too, so in agile terms we ended up with pretty good representations of Scrum in most teams. Landmark employees became the Development Team, as we were responsible for the creation of the product; the Splash guys billed themselves as Project Managers and they certainly do have those skills, however looking at how they worked with us then it is clear to me that they were the teams’ Scrum Masters. The staff members from the charity were our Product Owners and the children who has designed the new play park and who turned up after school to check on our progress and help clear up, were our stakeholders.

The “Scrum Masters” had the plans (i.e. the Sprint Goal), which they shared with us, and explained the priorities attached to the various tasks to ensure that the job would be completed on time, with the most important work being done first. The Sprint Goal was to complete the slide section which meant completing the bridge which connected a raised platform to the main walkway, finishing the platform and attaching the slide. In addition to these high level goals we had to ensure that we implemented specific business rules too, for example when adding railings to the platform we had to ensure they were between 25-89mm apart with a gap at the bottom of 25mm. I was in two minds whether this role was Scrum Master or Product Owner and I finally decided that the guys from Splash were fulfilling the Scrum Master role for two reasons. Firstly, they were ensuring that we followed the process, which in this case was the plan for the slide and to ensure that we met an acceptable definition of Done, but secondly, and crucially, they told us what we needed to do but did not tell us how we should do it. Although advice was given when requested.

Our Development Team were made of women and men from different offices so although we knew each other, few of us had worked closely together but good collaboration and communication would play a key part in the success of the project. Plenty of the team had experience of these kind of DIY projects and these multi-skilled developers were able to turn their hands to a wide variety of tasks. Those with slightly more limited skills were able to contribute by picking up new skills and ensuring that the batteries for the drills were kept charged up or bringing the building materials to the build site thereby ensuring the site was kept tidy and that a smooth flow of work could be maintained. As a team we collaborated very effectively to ensure we met our goal but we also had to collaborate with other teams on the site as some of the tools had to be shared across teams and success was judged on the overall site not on any one project.

For me, the most rewarding aspect of the day was that we were allowed to own the problem we were tackling. We had plenty of guidance and coaching from our “Scrum Master” in terms of ensuring we met of Definition of Done, and fulfilled all the necessary requirements. We were told that the old slide needed to be demolished to make space, and we that needed to keep the metal sheet to re-use on the new one BUT our self-organising team had to work out how to reinstall the slide against the new platform which had a different height and orientation to the old one. On several occasions we had to adapt the plan in the light of the real world situation such as digging a hole to ensure the large slide still fitted. Even when digging the hole we initially expected earth and stones but immediately hit some previously forgotten rubber matting placed years before and long since overgrown so we had to work out the most efficient way of removing it – it turns out that shovels won’t work but secateurs do a great job!

So we had a Goal and a Backlog of requirements, a Development Team, a Scrum Master and Product Owner and a whole load of eager stakeholders and two days to do something genuinely worthwhile. While I can’t say this is the perfect metaphor for Agile we had all the elements for a successful collaboration to deliver a meaningful project and above all the team took the opportunity to own the build and adapt the plan to the conditions on the ground in a truly agile fashion. All in all it was a great day!

The Agile Peloton

«L’Enfer du nord, Paris-Roubaix, La Côte d’Azure et St Tropez»
Tour de France, Kraftwerk

Phillipe Gilbert is presented with the World Champion’s Rainbow Jersey Valkenburg

It’s almost that time of year when the thoughts of all right minded individuals turn to cycling and especially the spectacle that is the Tour de France. It was this that started me thinking about the parallels between the professional peloton and agile projects – although the latter tends to involve a lot less Lycra.

Having watched plenty of road racing already this year I was struck by a number of parallels between the professional peloton and agile development teams and the more I thought about it, the more similarities came to mind.

Grand Tours

Grand Tours of the Tour de France, the Vuelta and the Giro are a single race consisting of 20 stages, where each stage is it’s own race within a race.  Each team works towards the goal for the day which may be getting the teams sprinter in a good position for the last 500 metres of the day or it may be supporting their grimpeur on the gruelling climbs. Most teams plan their tactics for the stage the night before or in the bus on the way to the stage so the whole team know what the goals are for the day.

Team Size

A Grand Tour team (ignoring the support crew) consists of 9 riders and in the smaller stage races such as the Tour of Britain the team size is six. Likewise Scrum has an optimum team size of six +/- 3. Six people is deemed to be a big enough team to be effective, with 9 being the largest effective size that can work effectively without providing additional documentation and more complex interactions.

Surprise and Delight Customers

It’s a simple fact that professional cycling teams are only able to continue for any length of time with the support of businesses who are prepared to sponsor them. The professional cycling teams represent their sponsors and provide air time for their brands in some of the most prestigious and biggest sporting events in the world. By extension the team need to surprise and delight their sponsor’s customers as well as the sponsors themselves in order to ensure that funding keeps coming.

Collaboration

This is an interesting one! Teams clearly work together and on the rare occasions where discipline breaks down within a team the results are the poorer for it. In recent years teams like Sky have brought a more disciplined approach to racing and have perfected the art of increasing their effort marginally in order to chase down breakaway riders. These high performing teams have a keen awareness of the “effort” and “velocity” and work together towards the daily goals, which can sometimes be a sprint, and the overall goal of the race. It is even possible to argue that there is some Lean thinking here too as the intention with most stage races is preserve one’s energy (minimising waste).

As well as team collaboration there is the more interesting on-the-road collaboration where riders from different teams in a breakaway will work together for the chance of a stage win. Conversely the other teams will work together in order to minimise the loses for certain of their riders. It is  rare, but not unheard of for lone riders to win and the collaboration with their allies on the road is key.

Team Spirit and Camaraderie

Team Spirit and Camaraderie are key to a successful cycling team. Sprinters like Mark Cavendish always ensure the efforts of the team are recognised when he has successfully contested a sprint. Likewise he is quick to point out his own failings when he does not win a stage. This spirit transcends teams too. After a long breakaway has been caught the remaining breakaway riders very often shake hands in recognition of a job well done.

It is not uncommon to see World Champions  doing the domestique role of the bringing water bottles up from the car to deliver to the team – assuming he is not expected to contest the win that day. Such activities are good for  morale and ensure that the team will work for him when the time comes.

Flamme Rouge

In my opinion  there are a number of areas where similarities can be drawn between agile teams and professional cyclists where cyclists can act as good a good example for facets of agile thinking. So this summer while you’re sat watching the ProTour teams pedal more than 3,400 kms around the french countryside spare a thought for the Agile Peloton, you might learn something.

First time trainer

Last week I was asked by a colleague to pass on my experiences of using Behaviour Driven Development, which happens to be one of my favourite subjects. Since this was my first ever attempt at training of any kind I decided to prepare quite a few topics. I wanted to run it as a mini sprint where all the topics were represented by user stories and the team could choose which bits were most important to them. In the end I ended up doing a few that way but found I didn’t have time to put everything in that format especially as, for some things I needed to tell the guys but I guess that’s a good learning point for next time.

 

Working with my colleague we put ordered the backlog as we thought fit and included some user stories that we had collaborated on and were relevant to the team. I put the all the topics as yellow stickies on a fantastic web site called http://www.webwhiteboard.com and added a Done column on the righthand side so I could move the stickies once the topic was Done. I did some background stuff on user stories before doing BDD and Gherkin, then demonstrated some automation in Visual Studio using Specflow to prove it worked – these guys are sceptical bunch 🙂

 

The best part of the workshop was when we went through a real user story and the guys started identifying the scenarios they needed to complete the story. A few minutes in they were a little despondant that they were still talking about the first scenario. From my perspective it was awesome, and I told them so – I could see that they were really collaborating to identify what the story really meant and were going through real-world, concrete examples to demonstrate behaviour. To me, it’s all about the C-word, Collaboration!

 

By the end the guys had clearly understood the basic principles and were planning to use BDD in their upcoming project. From my perspective, I think should have carried on with a single theme for presenting the information, in this case the User ki,Story format as it would have given the participants a chance to prioritise and set a definition of done. One thing I would definitely change is to make sure I check that people have understood the concepts and somnething like a happiness door / wall to get some immediate feedback.
Lastly, I found out that I really enjoy this training thing and I can’t wait to do more.

Surprise and delight your clients by delivering less

I’ve been observing one of the projects currently underway in my IT department over the past few months and I’ve realised that we’re delivering too much.

The project was kicked off back in November with a duration of twelve months. Plenty of work was done upfront to scope the project and reduce risk as far as possible. The work was parcelled up into potential releases with much of the functionality being front loaded into Release 1.

The team were asked to produce estimates for each of the releases before any development started – and, yes, we know this is not how we do it in a perfect world. Almost as soon as development started it was obvious that progress was not as fast as originally hoped and we are now in the situation where we need to replan, add resources or descope functionality to hit the end date. This has led to lots of horsetrading which leaving the Product Management team disappointed that they won’t be getting all they asked for on their single go-live date.

So, what could we have done differently?

Collectively, we need to change how we engage and educate the Product Management team. These poor guys have been conditioned to a one-shot waterfall project process. All the analysis is done upfront, the development tasks are estimated and the development team do their best to deliver as much functioanlity as they can by the delivery date. Once delivered, apart from minor bug fixes the development team will move onto another project for another Product Management or be disbanded and the individuals redistributed amongst other teams. But now with our agile approaches we can deliver quality code at regular intervals and keep the team together until sufficient business value is delivered.

We also need to educate the Product Management in how to create a Minimum Viable product (MVP). MVPs allow the busines to do a number of things; they can be used to test assumptions; release a product to market early and allow us the learn from real customers. Once we collectively understand what the MVP is we need to ensure that those fetures required to deliver it are given the highest priority.

So, to bring it back to the title, if the Product Management identify a valuable, viable set of features as the initial delivery then the development team will deliver the first cut of the product far earlier than previous approaches making our Product Managers very happy, which we like! Subsequent deliveries of additional functionality will be guided by feedback from the MVP and ensure that we continue to deliver the most important functionality for our customers and ensures that we are aligned with and sensitive to our Product Management requirements.

Rime of the Ancient Manager

Recently I paid a visit to my local bar, a lovely old fashioned English pub full of dark corners. In the gloom I spotted a grizzled old chap nursing an empty glass. From the crazed look in his eye I deduced that he was a Project Manager and, taking pity, I offered him a drink.

He accepted – a double, of course – and shuffled his seat over to mine then stared into his glass.
“Son” he said, “Here’s some free advice for you!” I edged my chair closer to the exit in case things turned nasty.

He continued “A CIO once told me that in order to change your business you have to take IT off the table before you can put it back on.”

I asked him what he meant and he replied “You have to remove all the impediments in IT to gain trust from the rest of the business before recommending IT as a business enabler.”

This speech had clearly exhausted the poor fellow and he went back to staring at his now empty glass in sullen silence.
His words gnawed at me for rest of the evening and into the small hours. Why did I think he was wrong? On principle getting one’s own house in order seems very sensible. Then, after many fretful hours, an answer came to me followed soon after by sleep.

A few days later I paid a return visit to the pub and saw the old PM in his usual spot so I wandered over with a drink in each hand. “I’ve been thinking about what you said, and I have to say, I think there is a flaw in your argument.”

“Oh, yes,” he said drawing himself up in his chair “and what might that be?”

“I think your old CIO was viewing Development as a separate entity to the rest of the business – a silo. We need an agile approach where we view Development as part of a wider system with really good flow of information both ways. That way we can build trust through honesty and transparency”

He shot me a look of distaste but I pressed on regardless.
“If we can help those Product people to give us better, clearer requirements and to work out what the Minimum Viable Product for each project is then we all benefit from quicker time to market, a shorter learning loop and better experience for our customers.”

“Your way is like not putting fuel in the car until the squeaky fan belt is fixed!” I said.

I turned to look him in the eye, but he’d fallen asleep.

Developers as Users and Technical Debt

I was recently asked the same question twice on consecutive days about whether it was acceptable to have “Developer” as the user in a User Story although there were other related examples which perhaps need further consideration. I wasn’t sure how I would approach this but having been mulling it over ever since.

When I was asked about User Stories for an automated testing tool to assist with testing I was remembered the story of a traveller asking a farmer for directions to the big town and the farmer replying “Well, you don’t want to start from here”. Similarly with Scrum if we have a robust Definition of Done we should not be in a situation where we need to create specific stories for delivering testing tools as these would form part of the DoD for the original story against which the code that is being tested was developed. But we are where we are so in this example the automated testing application is being developed for the tester who will be the individual using and benefitting from the business value released by this story.

The more complex situation is when the user of a story is a developer. The situations where I have seen this are divided into two. The first is where the development has been asked to undertake work in a technology in which no team member has any experience. Again to hark back to Scrum, it assumes that the team has the skills necessary to deliver the product increment so this again falls outside of the approved process. The approach taken by the team in this case was to attempt to create stories where the developer was the user with the aim of gathering a better understanding of the technology. The other non-scrum alternative is to create time-boxed spikes to do the same thing although it is clear that neither case will provide an effect Definition of Done.

The other situation is where developers are tackling Technical Debt. This leads to the creation of stories to refactor code to improve maintainability etc where the beneficiary of the story is a developer (i.e. I am writing stuff to benefit myself). I have yet to see acceptance tests for these stories but I can imagine they would be difficult to define. This issue was raised in our Scrum training and was tackled by taking it outside of the Scrum process. In order to tackle Technical Debt the recommendation was to allocate a fixed percentage of developers time (i.e. a bit like a spike) and to work on addressing technical debt from the technical debt list in a structured fashion (i.e. ensuring all the tests pass) until the allocated time is exhausted. This has the advantage that it is time-boxed and does not require artificial stories to complete the work.

My first ever post

Here goes with my first ever blog post. The purpose is to write about my experiences of implementing agile techniques in software development (and beyond). Before I get started properly I would like to thank the brilliant Gojko Adzic who suggested that I should blog about one topic in particular.

As for the name? Well, I’ve got a couple of reasons

1) All the good names starting or including the word “Agile” seem to be in use and I couldn’ t think of an obscure enough or witty enough alternative.

2) Since change is such elemental to agile I thought I would misquote Franklin D Roosevelt’s quote that “the only thing we have to fear… is fear itself ” and choose changeitself – and anyway, I like it 🙂