Open Mountain Blog

We moved to more of an agile mode of software development a year ago. We noticed some significant advantages, but also some pitfalls. In the end, the change the was the right decision for us and hopefully you will see why after you read about our observations.

I had a really good reason for being hesitant to adopt Agile development. This process is always brought up to me when I must explain that delivering X,Y and Z in the product will take some period of time like 3 months instead of 3 weeks. The product manager/senior exec person in front of me inevitably asks the question:

“Why can’t we do iterative development?”

Iterative development to them represents a way to go faster. The implication is that if we changed the way we managed development, the team could code faster. Iterations are definitely faster than releases in the waterfall sense. You can of course release more often. However, I have a hard time believing that changing the way you develop can’t change the fact that the coding and testing of X, Y and Z takes time. Like it or not, coding is physics and the time to do the actual work is what it is no matter how you slice it.

I throw out the usually compromises of course. Can I have more people? No. Can we cut something else? No. We’re already working more hours. Check. So given the same amount of people and no changes in the functionality, X,Y and Z can’t be done in 3 weeks.

I sat down with my good friend, Steve Greene, an industry veteran and the champion of Agile at Salesforce.com, and explained my delima. I asked him if I was wrong. If I move to iterations, can I compress 3 months of development time into a much, much shorter period of time?

Steve’s answer was definitely reassuring. The reality is, moving to Agile is not about going faster, but about going better. My response to the product manager/senior exec should be we can achieve more flxibility in releases. This allows us to be more responsive to customers. But no, Agile can not provide a unified theory for physics and code development.

Steve continued and of course I am paraphrasing what I heard versus what he may have actually said over the course of a lunch You are right, Bob. Completing all of X, Y and Z takes the same time* whether you use waterfall or Agile. But what you do get is**:

1) More predictability in your development – Checking in every month is better than waiting 3. Developers make a mental shift. They no longer get X merely to 80% knowing they can finish up during the mad dash bug fixing in the end. They get to 100% in month 1. There is a better focus on completion.

2) Better quality in your result – Waiting to the end to do quality increases the complexity of quality issues. Stabilizing X, then Y, then Z is easier then stabilizing X,Y and Z as a group.

3) Better flexibility in releases – We all know how expensive it is to be ramping on Y, and then find out we need W. Product teams fight hard to get W in because waiting for the next 3 month cycle for W puts the release of W out 5 to 6 months. With Agile, W can be slipped in and released, and that only pushes something else out a month.

In case you have any doubts about the benefit, I refer you to a presentation by Steve and others in his group at Salesforce.com about how releases are more frequent, customers are happy, and the development organization is not floundering under their own success. The most important part of this presentation, to me anyways, starts at slide 31 which simply states, “How’d we do it?”. I have already purchased this book on Agile development by guru Ken Schwaber. I am creating my product backlog in Google docs this weekend.

Back to my original topic, the key to a successful rollout of Agile development must include setting appropriate expectations with your product manager/senior exec stakeholders. They won’t get everything the want in month 1. But perhaps that desire comes from the fact that they don’t see anything until month 3. And worse, if they want anything else they have to wait to month 4 even to discuss it. With Agile, each month is a new day!

* Steve made the point that Agile is a bit more efficient than waterfall so really you might get X, Y and Z in 2.5 months with Agile versus 3 months with waterfall. This made sense to me.

** I did not list better product as one of the benefits simply because I doubt anyone would debate this. More collaboration within product teams and more interaction with customers will of course lead to a better product. That said, there is no reason why that can’t also be part of the waterfall process which is something I will discuss in a future post.