pliantalliance.org

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.

With increased traffic, comes increased spam. In an effort to combat comment spam I’ve installed a captcha plugin for Wordpress. I realize this is kind of a pain and I hope it won’t deter people from commenting since I like getting feedback and generating discussion. You can always register and then login before commenting, in which case you won’t see the captcha. Of course, I’ll delete any account if spam gets posted through it.

Ravi is at it again and he really hits the nail on the head. In this post he discusses Steve Yegge’s now infamous Good Agile, Bad Agile post, the wrath that post has incurred from the Agile community and his thoughts on the whole mess and Agile in general.

He sums it up like this:

Ok folks, listen up. Agile/XP is no panacea. It is just what worked for Kent Beck in certain contexts. The fact that there are a whole bunch of “agile consultants” both individuals and companies, out to part you from your money in exchange for the arcana of “True Agile” does not absolve you for thinking for yourselves.

That last part is really the key to all this. We must think for ourselves, because no one else will. The only people who are going to be able to determine what is best for your organization and how your organization should develop software with the people, culture and environment you have is the people who are in your organization. If you don’t have the expertise, then hire it. You can still ask for advice from consultants or books or whatever but it is your responsibility to distill and evaluate what they say and how that impacts on your context. Remember, everyone has their own agendas and your organization’s well being is not everyone else’s top priority. No one is going to do your work for you. Think. Evaluate. Change.

In my last blog post I talked about making sure your practices are delivering business value and changing things up if the value isn’t being produced. What I failed to mention was that this process of determining what works and doesn’t work for your context and organization is really difficult.

Fortunately, Marc Evers was paying attention and posted his thoughts on knowing if your practices are working. My first reaction to Marc’s post was, “Crap, that all sounds like it would be a pain and a lot of work.” And then I realized I had that reaction because that’s the truth.

Maybe this isn’t brain surgery and for the large majority of software being developed people’s lives aren’t at risk, but that doesn’t mean developing an organization that excels at software development is easy. There are no easy answers. It requires thought and time and effort. People looking for a quick fix should look elsewhere. You aren’t going to find it here or anywhere else (but you are welcome to keep looking while the rest of us get even better at what we do).