IT Conversations has an interview (mp3 41min) with Alistair Cockburn (pronounced koh-bern) that makes for a great listen. Doug Kaye hosts a great conversation with Alistair, discussing several topics, including the four principles of Agile development. Alistair explains that the wording is precise and intentional, and represents four sets of preferences, not four absolutes.
The Agile Manifesto
As Alistair explains – the manifesto is designed to show
“… What do we stand for? What would differentiate us from other groups that are trying to promote their approaches out there in the world?[…] We like this. You could like that, but in fact, we like this.”
They very intentionally want to point out that in each comparison, they aren’t defining the right way – but expressing a preference for one way over another.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, the above authors. this declaration may be freely copied in any form, but only in its entirety through this notice.
Uncovering is the key word here – the authors don’t promote themselves as the inventors of these ideas – they have selected them as the best of the ideas among teams that they have worked with and interviewed.
Individuals and Interactions
Alistair points out that while a lot of energy is spent debating and selecting processes and tools, what truly matters is the people on the team and how they interact. Communication and collocation are the two main elements that he stresses.
Collocation is important because it becomes a source of unintentional or incidental communication. Scott Ambler describes this as “osmotic communication.” The element that probably is most differentiated from classical project management is the notion of collaborative planning. A project manager doesn’t hand down a plan, the team works together to develop it. Design collaboration and pair programming are also highlighted.
Working Software
This point emphasizes the comparative element of the manifesto. Yes, documentation has value. Working software has more value. When faced with a choice, write the software.
Why should we create documentation? Documentation serves to help current team members stay on target, and helps new team members get up to speed on domain, intent, design, and implementation. At each stage in the development process, we can evaluate the relative priority of a piece of documentation, and the element of working software that would have to be deferred in order to write it.
Whenever the document is more important – write the document. A ruthless approach, but directionally correct. The risk is that we make those prioritization decisions incorrectly. The value of the working software is obvious – the value of the documentation is more elusive.
Customer Collaboration
While Alistair recognizes that contracts are often unavoidable, he presents an inspiring image. Instead of sitting on opposite sides of the table (contract), imagine what can happen when we all sit on the same side of the table (collaboration).
Contracts are explicitly a barrier to change. When working with a contract (explicitly, even if not legally), the contract binds people to do exactly what was predetermined would be done. When change happens, the contract must be updated or violated, or the change must be refused. Contracts are usually created with the intention of preventing failure. They can be used to prevent the predicted form of failure, but they also inhibit any number of forms of success.
Responding to Change
“The plan rarely survives three days into the project, most of the time,” posits Alistair. The point simply is that as we learn more, we should react to the new information. A fantastic and rational perspective – Alistair clarifies: Instead of saying “…but the plan says” we should say “What’s the best thing to do now?”
Summary
There is a lot of power in this manifesto. It really drives a philosophy or approach to software development. One that will lead to software product success more often than not. Get the right people, working together effectively. Keep their primary focus on creating working software. Collaborate with the customer to identify changes in requirements and prioritization. React to those changes by re-prioritizing.
