Agile Software Development

With all of the books with “Agile” in their title today why would anyone want to single out Agile Software Development in particular?  My reason was the author Alistair Cockburn.  Alistair has been a part of the agile movement being both an original signatory on the Agile Manifesto and the proponent of the Crystal Clear methodology.  In other words, the resume isn’t bad.

Agile Software Development is both interesting and unique because it’s unlike other books about agile development that you might read.  First, it’s in some ways more of an extension of Peopleware and The Psychology of Computer Programming.  It talks about why developers behave the way they do without condemnation or excuse.  It speaks about the way things are and what you can do to get better results.  Alistair’s understanding of the dynamics of communication can help you construct solutions that allow your team to communicate more effectively.  Either its “rearranging the furniture” or “vandalizing the walls” there is an understanding into the psychology of how things work – and why they work that can be effective whether you’re deciding to adopt an agile methodology or not.  (“rearranging the furniture” and “vandalizing the walls” aren’t his terms – their my colorful summaries of things like evaluating communications like the dispersion of heat or a gas and a concept that Alistair refers to as information radiators.)

On the topic of methodology there’s a lot to be had as well.  I’m preparing for a web cast titled Defining Your Own Software Development Methodology.  In that web cast we’ll be talking about how to create – or more appropriately tailor – a methodology for your organization.  In addition to having some great “sound bites” for that discussion, the model that Alistair uses to talk about methodology creation has influenced some of the web cast material.  Coverage of the characteristics of a methodology, the way to approach usage, and the impact of lighter and heavier methodologies have all been positively impacted.

I’ve always respected the simplicity and usefulness of Alistair’s breakdown of projects based on size and criticality.  The breakdown of criticality into Loss of comfort (C), loss of discretionary monies (D), loss of essential monies (E), and loss of life (L) has been quoted many places.  The reason I appreciate it so much is that it simplifies the task of speaking of the size and characteristics of a software development effort into something that can be quickly understood by all.

As both a word of caution and one of praise, Agile Software Development doesn’t take a formulaic approach to delivering the content.  Instead it gives you all of the components you need to understand how things work and leaves the exercise of making it work to you.  While I find this approach very appealing because I am looking for different views and perspectives which I can add to my toolbox, it may be frustrating for readers who want someone to tell them what “the answer is.”

I leave you with one of my favorite sound bites from the book (p71):

“Although heroes who work overtime may be needed to save poorly run projects, there is a much more interesting phenomenon to observe: ordinary people doing their work with a sense of pride and community and in doing that work noticing something wrong, passing information to someone who can fix the problem, or stepping out of their job descriptions to handle it themselves.  This is an indicator of a community in action, not an indicator of a poor development process.”