Agile Manifesto
On 11-13 February 2001 at the Snowbird ski resort in Utah, 17 attendees, (two of which are the co-inventors of Scrum,) agreed upon and signed the “Manifesto for Agile Software Development” as a symbolic gesture that sets out the values and principles for Agile software development. The attendees also formed the “Agile Alliance” as a “…group of independent thinkers about software development.” [2]
The manifesto can be viewed at http://agilmanifesto.org and describes 4 values and 12 principles that were agreed upon.
The four values have quite deep meanings and inferences and are discussed a little more in the following sections.
Individuals and Interactions over Processes and Tools
At the core of the manifesto, there is a common belief that software development should be done in an environment that acts as though people are the most important with a strong focus on values and culture.
This value focuses on how people interact, collaborate and inspire each other rather than applying the perfect process or tool. For example, if a team are working well together but are not following the process as it was defined, then should their behaviour be corrected to comply with the process, or should we simply adjust the process to match how they are naturally working?
Traditionally, we might have placed too much emphasis on the process and tools, so much so that they may have become even more important than the people and the software product that we were supposed to be producing.
Hence, this value is about bringing things back into balance, in that, we value our people and their close interactions to collaborate, create and innovate a fantastic product as being more important than the process or tools that they used to produce it.
We still might need some processes and tools, however, these should be used to support and enhance our people’s efforts and what they are trying to do rather than constrain them.
The keyword in the values is “over” in contrast to “instead of”, where the Agile Manifesto states, “That is, while there is value in the items on the right, we value the items on the left more.” [1]
Working Software over Comprehensive Documentation
When the manifesto was written there was typically a great deal of effort, time and cost devoted to creating and maintaining documents such as requirements and software designs, which would inevitably need to be changed as soon as the software started to be written.
In some cases, the requirements documents became a fixed contract, setting expectations of what the teams could do with little more than a guess (estimate) as the key indicator of whether this was possible or not within the timeframes.
Hence, this value encourages us to focus our efforts to produce the end product, rather than just writing and thinking about it.
Having only written artefacts about what we want to do is really just theoretical and may well introduce a whole range of assumptions into the project, whereas having built something provides real evidential feedback about what is really working and what isn’t, how long things might take and the complexity of what we are asking the teams to do.
We still need some documentation and information, especially on how to support and maintain the product going forwards. Hence, there is a balance between providing just enough information to be useful, and delivering actual working software that is valuable and of high quality, which should be placed in higher esteem.
Customer Collaboration over Contract Negotiation
This value reminds us to focus more on collaborating with our customers to objectively work through problems and satisfy their needs, rather than focussing too heavily on the clauses in a fixed contract, which may well lead us into an adversarial and distrusting relationship.
Most contracts are written at the start of a project, which is when we know least about what is needed and what form the project will take. Hence, there should be a balance between the useful boundaries in a contract and our relationship with the customer, which is of higher value.
Responding To Change over Following A Plan
Typically most, if not all, software projects are more aligned to research and development activities rather than manufacturing activities, as new ideas are developed and each project provides a unique and novel solution to a problem.
Hence, our original ideas at the outset of a project may be out of date quite quickly, and will need to be changed and adapted as the project continues to provide evidential feedback about what works, what doesn’t and what needs to happen next.
The Agile movement accepts and embraces that change will almost always happen with any software development project or initiative, and the ability to foster and incorporate change effectively may actually be an indicator of a successful outcome.
If our focus is too heavily on creating and relying on the perfect plan then it probably won’t last very long before it needs to be changed to remain relevant. Hence a balance between a high level plan and the continuous adaptation to the current situation in the project is more useful than blindly following our first assumptions.
Foundation
The Agile Manifesto sets out the values and principles as a foundation to all Agile frameworks and approaches.
Scrum is an example of an Agile framework that encourages individuals to interact during and outside of its events.
Sprints are intended to provide a firm focus on delivering done software product increments regularly.
The Product Owner role represents the customer needs and enables a team to collaborate freely to arrive at a software product that is valuable.
The Sprint Review and Sprint Retrospectives are events that allow a Scrum Team to inspect the project, solicit feedback and adapt accordingly.
References
- Manifesto For Agile Software Development, http://agilemanifesto.org, accessed 25 July 2017
- History: The Agile Manifesto, http://agilemanifesto.org/history.html, accessed 25 July 2017