Balancing Agility and Discipline: A Guide for the Perplexed
I mentioned briefly in my last post that I was reading Balancing Agility and Discipline: A Guide for the Perplexed. I managed to navigate my way through the end of the book and wanted to record my initial thoughts about the book and about my growing perspective on Agile software development in general.
On the book…
The fundamental question that the book answers is how do you take the best of Agile development and integrate it into your current software development methodologies. It neatly disguises this question under the auspicies of exploring the places where each method “belongs.” — their home ground. It does what appears to be a very thorough job of reviewing the strengths and weaknesses of both traditional (plan-based) development and agile development.
My current thinking about Agile development (and software development in general) is this…
1) Agile software development makes the same statement that traditional development does — better programmers make better projects. I was struck with how much emphasis good software development –whether traditional or agile — places on good developers. (It would be more accurate to say good participants.)
2) Agile software development is like Voodoo — at least in the movie Dogma’s definition “Do you know about voodoo? No constitution of faith, more an arrangement of superstitions.” In other words, it’s a collection of techniques — some shared between different agile variants, some shared with more traditional plan-based development, and some shared with project management practices. The percentage of people following a specific technique is very low.
3) Agile is akin to “Management by Wondering Around” one of the practices made popular by In Search of Excellence. It focuses on people actually talking to each other. Given the number of large scale projects I’ve worked on where that doesn’t happen — I’m all for people talking to each other. 😉 In a more serious way, the focus is on individual and personalized conversations with people. Answering their specific needs and coaching them into effective behaviors — one by one.
4) The arguments that are being used by both sides of the isle represent a fundamental lack of understanding. It reminded me of a recent set of posts on the Dilbert Blog about Intelligent Design vs. Evolution. [Warning: The preceding link may consume a huge amount of time as you try to figure out which of the arguments are the dumbest.]
5) We’re all missing the point … We start good development by getting good people involved. We get good people involved by DEVELOPING / CREATING / BUILDING good people. If we’re not all willing to go out of our way to help other people become other developers — every day whether it makes sense to the particular project or not — then we may be doomed to struggle with poor software developers forever.
The good news is, however, I’m more agile than I thought.