Agile Manifesto

The Agile Manifesto, also called the Manifesto for Agile Software Development, is a formal proclamation of four key values and 12 principles to guide an iterative and people-centric approach to software development.

The Agile Manifesto is at the core of the Agile Movement. Application for Agile outside of software development has even been found, with its emphasis on lean manufacturing and collaboration and communication, and quick development of smaller sets of features under the guidance of an overall plan. The key to its success is that, it is always Agile and able to adapt to change. It is hard to imagine just how much software and activity has been born from the “The Agile Manifesto.” Before the “Manifesto,” software development wasn’t a particularly fast process. This situation often led to many projects in the pipeline being cancelled due to changing business needs. As a result, the software development industry was prime for disruption. The Agile Manifesto and the Twelve Principles of Agile Software sought to change things, speed up development time, and a produce a quality.

The Agile Values
The important thing to understand about the four value statements is that while you should value the concepts on the right hand side you should value the things on the left hand side (presented in red) even more.A good way to think about the manifesto is that it defines preferences, not alternatives, encouraging a focus on certain areas but not eliminating others. The values of the Agile Manifesto are:

• 1. Individuals and interactions over processes and tools. Teams of people build software systems, and to do that they need to work together effectively – including but not limited to programmers, testers, project managers, modelers, and your customers. Who do you think would develop a better system: five software developers and with their own tools working together in a single room or five low-skilled “hamburger flippers” with a well-defined process, the most sophisticated tools available, and the best offices money could buy? If the project was reasonably complex my money would be on the software developers, wouldn’t yours? The point is that the most important factors that you need to consider are the people and how they work together because if you don’t get that right the best tools and processes won’t be of any use. Tools and processes are important, don’t get me wrong, it’s just that they’re not as important as working together effectively. Remember the old adage, a fool with a tool is still a fool. As Fred Brooks points out in The Mythical Man Month, this can be difficult for management to accept because they often want to believe that people and time, or men and months, are interchangeable.
• 2. Working software over comprehensive documentation. When you ask a user whether they would want a fifty page document describing what you intend to build or the actual software itself, what do you think they’ll pick? My guess is that 99 times out of 100 they’ll choose working software. If that is the case, doesn’t it make more sense to work in such a manner that you produce software quickly and often, giving your users what they prefer? Furthermore, I suspect that users will have a significantly easier time understanding any software that you produce than complex technical diagrams describing its internal workings or describing an abstraction of its usage, don’t you? Documentation has its place, written properly it is a valuable guide for people’s understanding of how and why a system is built and how to work with the system. However, never forget that the primary goal of software development is to create software, not documents – otherwise it would be called documentation development wouldn’t it?
• 3. Customer collaboration over contract negotiation. Only your customer can tell you what they want. Yes, they likely do not have the skills to exactly specify the system. Yes, they likely won’t get it right the first. Yes, they’ll likely change their minds. Working together with your customers is hard, but that’s the reality of the job. Having a contract with your customers is important, having an understanding of everyone’s rights and responsibilities may form the foundation of that contract, but a contract isn’t a substitute for communication. Successful developers work closely with their customers, they invest the effort to discover what their customers need, and they educate their customers along the way.
• 4. Responding to change over following a plan. People change their priorities for a variety of reasons. As work progresses on your system your project stakeholder’s understanding of the problem domain and of what you are building changes. The business environment changes. Technology changes over time, although not always for the better. Change is a reality of software development, a reality that your software process must reflect. There is nothing wrong with having a project plan, in fact I would be worried about any project that didn’t have one. However, a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.

The interesting thing about these value statements is that most organizations completely agree with them, yet will rarely adhere to them in practice. Some senior management claim that creating software is the fundamental goal of the business, but will insist on spending months producing documentation describing the software instead of building it. Just keep in mind the ultimate goal of your project and if you are required to do something that hinders that goal, bring it up with your team and remind them of these four values.

In conclusion, it's the results that matter: The whole purpose of the Agile Manifesto is to deliver better software. We need to focus on value and results that add to a firm's competitive advantage. Of course, this was always the intention of Waterfall projects. It simply did not happen very often. All too often we focused on the process and documentation, which resulted in a false sense of security; and we didn't communicate with the people who, in the end, are most important. However, there are also examples of Agile projects in which people forget the importance of the "items on the right." This is also an improper choice. Delivering the proper software product is still very hard. Agile doesn't change that. Using an Agile approach gives us permission to lessen the need for formality, but we should not disregard it.

Agile Software Development Principles
The Manifesto for Agile Software Development is based on twelve principles:

• Customer satisfaction by early and continuous delivery of valuable software
• Welcome changing requirements, even in late development
• Working software is delivered frequently (weeks rather than months)
• Close, daily cooperation between business people and developers
• Projects are built around motivated individuals, who should be trusted
• Face-to-face conversation is the best form of communication (co-location)
• Working software is the primary measure of progress
• Sustainable development, able to maintain a constant pace
• Continuous attention to technical excellence and good design
• Simplicity—the art of maximizing the amount of work not done—is essential
• Best architectures, requirements, and designs emerge from self-organizing teams
• Regularly, the team reflects on how to become more effective, and adjusts accordingly

Agile Manifesto Authors

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• Robert C. Martin
• Steve Mellor
• Dave Thomas
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Ken Schwaber
• Jeff Sutherland

Further Reading

• Writing The Agile Manifesto Martin Fowler
• What's Missing In The Agile Manifesto: Mindset Forbes
• Embracing Agile {https://hbr.org/2016/05/embracing-agile HBR]
• To agility and beyond: The history—and legacy—of agile development Tech Beacon