Rigid Agile
I was meaning to get around to commenting on this post about preventing work not in the Agile iteration plan interrupt what the developers are working on. I had some problems with the post but I couldn’t quite put my finger on it. Before I could sit down and think, Joel Spolsky posted his comments and I realized what my problem was (and apparently Joel has the same issue).
The Agile environment described by Dimitri in the original post is too rigid. There is no flexibliity in the plan to be able to respond to urgent requests and do things that are critical to the business, but which weren’t foreseen during the iteration plan. Like Joel, I agree context switching is generally a bad thing, but so is closing the door on the business for two weeks at a time and ignoring what is going on with them. There needs to be some flexibility in software development processes.
From Joel:
Agile development is supposed to be about agility. It’s supposed to mean that you can change plans quickly. It’s not supposed to be about rigid programming teams who are so slavishly devoted to their Two Week Plans that they can’t rearrange their schedule a bit to serve the needs of the customer. Dmitri’s conclusion, I’m afraid, strikes me as the very opposite of agile development. Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn’t take customer’s needs into account.
Unfortunately, this is exactly what Agile is becoming to some. It is becoming a rigid set of procedures that we’ve swapped with the old set of procedures and declared progress. Dimitri’s example is exactly the opposite of “Customer collaboration over contract negotiation” described in the Agile Manifesto. Granted the “contract” has now become a 2 week iteration plan, instead of a 3 year, multi-million dollar deal, but their is still a contract and the Development Manager chooses to stick to that contract rather than collaborate with his customer.
Don’t get me wrong. I personally believe that iterative development is the way to go. We can argue about the details (length, parameters etc) of the iteration, but iterating and evolving software over time based on customer feedback, business needs, technical advancement etc, is the only way I’ve ever developed successful software. So yes, we need to make a plan. We need to know what we are doing. Don’t just sit there, ready for the business to come to you to put out the fires. That is the other extreme and it is not good either. Make a plan, but be flexible and don’t worry if in the middle of your iteration, something comes up that is deemed a higher priority and the plan has to be shifted on the fly. It is better to deal with change than it is to stick your head in the sand and have change destroy your business.