Skip to content

Baby steps into agile

January 28, 2008 by cspag

I was watching an old movie last night that I think is hysterical called "What About Bob?" starring Richard Dreyfus and Bill Murray. Bill Murray plays a guy with tons of phobias. Richard Dreyfus plays his doctor who is teaching him about taking baby steps to overcome his fears. Bill Murray has one particular phobia about riding in elevators. At one point in the movie, he decides to finally try getting on an elevator and says "Baby steps onto the elevator...baby steps into the elevator...I'm in the elevator" (the doors close) "HELLLLLLLLLLP!!!!!".

Seeing that movie was the perfect impetus for me to write this post. I've been doing a lot of thinking lately on how to take our company through the agile adoption process. I'm thinking baby steps (minus the "Help!" scream hopefully). Over the past few weeks I've spoken with a number of leading agile proponents about what they would do to adopt agile in an enterprise and the answer has been a resounding "baby steps". I'm glad to hear that because that's how our small development team first adopted agile ourselves. I don't believe that an organization can just throw the magic agile switch and change things overnight. I think that agile has to be grown organically in a series of steps that help organizations successfully adopt and accept agile practices.

The first step our team took was just getting into the agile "flow". We instituted some basic practices to get our team into a good rhythm and to introduce agile concepts. We decided to begin two-week iterations on a single project. We already had some half-way decent requirements definitions for the work. But, we didn't start prioritizing, building user stories, assigning story points, playing planning poker or anything else. We just started with a simple, two-week iteration in which we tried to decide what we could complete during that iteration. We planned the iteration collaboratively and really committed to completing everything we bit off for that iteration. We also started the practice of a daily stand-up, an iteration review, and a retrospective. That's it. We did that for quite some time until the team was comfortable with the flow of an agile, iterative development style. It was working well, and it seemed to fit for our team.

Once we became comfortable with our new agile practices, we started to slowly introduce others into the mix. We began re-writing our requirements as user stories. We started playing planning poker to estimate story points. And, we began to track our velocity. As the ScrumMaster, I started to really protect the team from distractions and did everything I could to remove impediments for them. Again, that was it for quite some time. When we were feeling good about those, we introduced our client to the idea of prioritizing his backlog of user stories (it was a fixed-scope fixed-price contract, but we thought this was a good exercise to learn from anyway). We also started to really emphasize acceptance testing. Once we were alright with this set of practices, we took a look at what we should be doing on the actual development side to become more agile. We introduced continuous integration, daily builds, lite versions of paired programming. Again, just a few small practices that helped us slowly become more agile. Our next step was release planning. Around that time, we introduced some tooling for managing the projects (Rally) and we also began doing serious defect tracking and fixes with some tooling as well. We had also decided to start implementing agile practices on some other projects that our team was responsible for.

When we felt that we had a handle on our own team, we started to evangelize to our peers and our organization. The organization caught on after some convincing and started sending other project managers to Certified ScrumMaster training. We were going to start sending members of our team out onto other project teams to help coach and guide them in their adoption of agile practices. However, we left our old organization before we got to realize the full enterprise adoption of agile, but we were well on our way to getting them there.

Now, with our new company, we get to do it again...and we're much smarter from our previous efforts. And our new company has an organizational culture which is very supportive of agile practices. As we move through our adoption process, I'll keep you posted on our progress, but I'm pretty sure we'll be taking baby steps first. Baby step into the flow...baby step into agile practices...baby steps into agile!!!

Comments

What estimates the planning poker?

April 16, 2008 by Anonymous (not verified), 1 year 42 weeks ago
Comment id: 1509

The story points that estimate with planning poker are days???

It can be pretty much

April 18, 2008 by Artem, 1 year 42 weeks ago
Comment id: 1511

It can be pretty much anything - planning poker is more about resolving disagreements, than about focusing on a concrete measurements. Usually planning poker is used for estimating the product backlog items in unitless story points or ideal days

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com