Rants, rambles, news and notes from another geek

The Key to Adopting Agile Methods

On Monday Alan Ridlehoover and I presented “Incorporating Agile Development Into Your Organization” at Microsoft Tech Ed 2006. We had the pleasure of having our talk at the first talk of the first day in the Architecture track. As it turns out that was good, but that is a story for another post…

Alan and I met with many people including Brad Wilson, Michael Puleio, Mitch Lacey and Jim Newkirk discussing the various things that had enabled successful adoption of agile techniques. After listening to everyone we decided that most of the agile community has been writing books on all of the technial aspects of the problem instead of the softer parts. We have lots of books on TDD, Pair-programming, version control, unit testing, even emergent design.

And these are all good things to be talking about. They are important ingredients in the recipe for agile adoption.

But you will fail if you focus exclusively on these things.

And that is because the most important part of agile is not the technial “how to” parts. It is that agile teams have different values than non-agile teams. And changing values requires cultural change.

Cultural change is a softer thing that is hard to teach to technologists, so we shouldn’t really be all that surprised that we don’t get much coverage on it. The astute reader will be able to point me to dozens on paragraphs on dozens of books that talk about how you will have to promote cultural change, but then the next paragraph is about the next technique for writing the code or reporting on the status. We understand these things. These are tangible problems that we can identify, analyze, troubleshoot, measure and test. And again, I say, if you focus exclusively on these things, and ignore the cultural issues your agile adoption will fail.

The most interesting thing about this to me is that the agile manifesto guys got it right. They quite clearly recognized that this thing is about culture and values and is not about specific techniques or tools. And then almost every one of them went off and wrote a book or a tool that talk about the techniques and not about how to change people’s values.

So, that is what we need. We need a book that tells us how to change people’s values and attitudes about software development. If you we can teach that, then the rest will just fall into place for free. The techniques become obvious when people’s minds are in the right place. And the techniques become obstacles when they aren’t.