The Agile Manifesto set forth a revolution in the software industry when it was introduced, until today. The use of Agile Methodology has grown well beyond software, however, the original focus of the Agile Manifesto was Software Development (The title of the Manifesto is, “Manifesto for Agile Software Development”). Not only has it grown beyond software, but it has grown beyond commercial organizations as well.
As Agile became more widely known, an ecosystem formed that included the people who were doing Agile software development and the people as well as organizations who helped them through consulting, training, frameworks, and tools. The concept of agile seems elusive and continuously changes, but no business leader can hope to be successful in the current market without using Agile.
History of Agile Manifesto
Due to a development boom, there were multiple ways to develop software in the beginning. But there wasn’t a consistent way of describing the different ways to develop software until a group of 17 people thought, “We’re all doing these different approaches to developing software. We ought to get together and see where there are commonalities in what we’re thinking about.” The result was a meeting at a ski resort in Snowbird, Utah in 2001.
When they got together, they did some skiing and also discussed where their approaches to software development had commonalities and differences.
They didn’t agree upon a lot of things, but there were a few things that they were able to agree upon, and that ended up becoming the Manifesto for Agile Software Development. The two main things the Agile Manifesto did was to provide a set of value statements that form the foundation for Agile software development and to coin the term Agile software development itself.
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.
1. Individuals and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is easy to understand, because people respond to business needs and drive the development process. If processes or tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.
2. Working Software Over Comprehensive Documentation
Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.
The Agile Manifesto values documentation, but it values working software more.
3.Customer Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work out the details of a delivery, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This meant the customer was involved in the process of development before development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.
4.Responding to Change Over Following a Plan
Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.
On the whole, this document has aged better than most of the software written. While a few of the principles of the Manifesto show their age, it is still clear what the intention of those principles are. It is an extraordinary document that, although created by very technical-oriented people, stays away from technical solutions and is more value-driven.
With the increase of development speed, new movements like the DevOps movement have added to these values to create a better way to look at software development in a broader context. As Eric Naiburg mentions in his article in Scrum.org, here are some things to take from the Agile Manifesto,
Have a goal for why what you are doing what you are doing and ways to measure the impact of what you may be doing no matter what it is.
Be willing to accept feedback. Feedback can be difficult to accept, especially if it goes against your initial thinking, however, consider that feedback with an open mind and get out of your comfort zone of what you know and learn from those providing the feedback. That said, don’t just change based on one person’s feedback for example as it may be an anomaly vs. the norm, so be sure to consider all feedback and interpret it.
Try and get tangible results to get that feedback based on reality vs. interpretation.
Don’t lock yourself into a plan that cannot be changed or adjusted as you learn.
Assume that change will happen and be prepared and set up to succeed when the unknown occurs.