I want to start agile, how can I do that?

Last week a new colleague of a former colleague of mine 😉 asked me: “How can I get agile started? I really like the ideas but don’t know where to begin or how to convince others around me to try it out. What should I do?”

Getting started with agile is not easy. First, you have to convince everybody that it’s a good idea to try it and then, if you really managed to get the ball rolling, you begin to uncover all the hidden problems which have existed since decades in your development processes. Ouch. Only if you make it through these two phases will you be blessed with the advantages of an agile process: high speed, high quality, high visibility and high value of what you are doing.

Today I want to show you one way to tackle the first hurdle.

Identify the Biggest Problem

When I struggled to introduce agile processes and practices within my former organization, the single most useful tool which enabled my break through was a Value Stream Map as described by Marry and Tom Poppendieck in their first book about Lean Software Development.

I used the most simple version like the following picture shows:

The green lines are productive time spent to create value. The red lines represent the time that value sits around your office (not released to your customers) – wasted time. The x-axis shows the timeline. Just doing this simple exercise shows how badly out of proportion your value-added time is compared to wasted time. If you want to speed up feature delivery, you have to minimize the time wasted. There are a lot of red line segments, each of them pointing out an area of possible improvement. But you should focus your resources. Instead of trying to attack all problems at once you should only attack the biggest one. And the biggest problem is your biggest red line segment.

In my case, it was the waiting time from a feature being ready for release until the next release. We only did two releases a year so this waiting time could be close to six months in worst case. Compare that to the couple of days between development and testing and its pretty obvious which problem needs to be addressed first.

Attack the Biggest Problem

With such a Value Stream Map in hand you should be able to get the attention of your co-workers: “What? We really take up to two and a half years to deliver a feature :-O ?” Yes, we do. It wasn’t nice to be forced to accept that truth, but it set the stage for change. After identifying our 6 month release cycles as the biggest waste, it was rather easy to come up with an initial idea: Let’s do releases more often.

First, we decided to try to release something every two months. This was a classical “stretch goal” – a goal you can only reach by substantially changing the way you work because you’d never be able to attain it if you keep working like today. That need for a substantial, innovative change of our procedures gave us the required kick-start for agile.

Speeding up the process showed us one bottleneck after the other: Manual regression testing wasn’t possible anymore as there wasn’t enough time for it. So, we had to introduce automated tests. Month long design phases creating “perfect specs” were not possible anymore either. So we introduced user stories and acceptance test criteria. And so on. The Agile Train was rolling…

What are your experiences with introducing agile practices and processes? Did it work out well? How did you get it started? We would love to hear your story in the comments.