Currently one of the hottest trends in software development is implementing Scrum. Scrum is a specific framework that, while predating it, adheres to the Manifesto for Agile Software Development (the Manifesto). This is not surprising. Ken Schwaber and Jeff Sutherland were two of the seventeen people whom came together and created the Manifesto. They had formally established Scrum as we know it today six years prior. The problem I see is people don’t understand why they implement Scrum or why Scrum has the roles, meetings, rules, and artifacts it does. The best way I know to start this dialog is with the Agile Manifesto.
This is the first part of a monthly (approximately) series of posts where I look into the Agile Manifesto. As Agilists this document is something we should be able to talk at length about. This is my attempt to break it down and remind us why we coach the behaviors we do whether in Scrum or not.
The Manifesto for Agile Software Development was established in February of 2001. It was conceived of by seventeen people from across the spectrum of “lean” software development. More had wanted to be involved but were unable to attend. The goal was to establish a widespread alternative to document driven, heavyweight processes. This was not driven by any single company’s desire for profit. In fact, some of these people were competitors with differing methods. That they came to any agreement surprised even some of the attendees.
What they agreed on is as follows:
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 plan
That is, while there is value in the items on
the right, we value the items on the left more.
Robert C. Martin
© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
At the heart this Manifesto was really about people. To paraphrase Jim Highsmith, people stop being resources and start being people again. In the basics of what they agreed upon we can see a departure from the classic mind-set of a business getting the most from its assets and a move to people providing the best value for those they serve. All of the project and people management techniques born of the industrial revolution were failing the technology revolution. The Manifesto was just a concise way of stating it while providing a solution.
The Manifesto was not a call to abandon process and methodology. It was a call to reign in the crazy that had evolved from initial good intentions. The dichotomies were not set up as “either or”, but as “both with preference to one.” It was also not meant as an end, but a beginning. The twelve principles were hammered out over the months following the initial meeting. The original seventeen people handed the whole thing over to a larger group of like-minded individuals in September which was followed by the formation of the Agile Alliance.
Today the Manifesto has a home both on the original site and the site of the Agile Alliance. The Agile Alliance now maintains the Manifesto and Principles. It does not do certifications or provide specific direction for training. It’s mission is to “support those who explore and apply Agile principles and practices to make the software industry productive, humane, and sustainable.” (http://www.agilealliance.org/the-alliance/)
See a brief history from one of the founders here: http://martinfowler.com/articles/agileStory.html