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:

Value Stream Map

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.

4 thoughts on “I want to start agile, how can I do that?

  1. Hi Matthias and Dan,
    Starting “smart and small” the adoption of Agile practices has many advantages – one of them being that the resistance to change might not be as significant as with a “big bang” approach. Moreover the impact of this small (but smart) change may be more measurable! Was that the case in your team?
    Fighting on several fronts at the same time can be quite exhausting and reduces the chances of successfully making the switch (or at least makes it a lot harder). On the other hand, I think the expectations are set right from the beginning with the “big bang” and can act as motivator in the team / organization.
    Selecting the way to make the shift depends largely, in my opinion, on the team’s / organization’s culture as well as driving forces (a typical approach to change management).
    All in all a very interesting post! Keep up the good writing!

    Like

  2. There’s a number of reasons why our particular development cycle works for us, but we give some info about our numbers at the bottom of http://code.flickr.com. At the moment, it says:
    “Flickr was last deployed 62 minutes ago, including 9 changes by 4 people.
    In the last week there were 66 deploys of 883 changes by 25 people.”

    Like

  3. …and I also very much agree with Nathan: having the right culture is imperative for rapid development/change to happen successfully. A culture of responsibility, IMHO, is an absolute must. The stereotype of “tossing the ball over the fence” between development, QA, operations just doesn’t work in a place where change is frequent.

    Like

  4. Nathan: The change was measurable very easily: We got down to 2-3 releases every week (instead of one every 6 months) and our customer care team got so much more relaxed, not shouting at us anymore ;-). Interestingly, the question whether to do a big-bang change or incremental ones is recurring, we even discussed it here on this blog at: https://www.agileweboperations.com/visible-ops-rolling-out-change-management/ … Maybe I should try to blog more about it 😉

    John: The amount of change you guys manage at flickr is simply awesome!

    I fully agree with you that a culture of responsibility is an absolute must. Without it you’re lost. Only if you can rely on people you can go fast. And only if everyone cares for what they do you can rely on them…

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.