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.