History of the Agile Manifesto
The 1990s were frustrating times in the industry. The project management methodologies of that time did not allow production of quality products in an acceptable time. As we already know, the business requirements of software tend to be clarified or even changed while the project is in the development phase. This is normal, but does not fit the Waterfall methodologies which would not adapt to drastic direction changes. These methodologies only worked well when technologies were developing more slowly, and customer needs did not change so quickly.
Seeing the problem becoming more and more serious, new, lightweight, software development methods, or frameworks, started to appear. By the end of 1990, there were several being actively used: Rapid Application Development (RAD), Scrum, Extreme Programming (XP), Feature-Driven Development (FDD), and others.
In 2001, seventeen software developers met in Snowbird, Utah to discuss the approaches in software development and the challenges being faced at that time. These developers included Jon Kern, Kent Beck, Ward Cunningham, and Alistair Cockburn. During that meeting, the Agile manifesto and the Twelve Principles were elaborated and written.
The original Manifesto does not describe anything in detail but defines the idea extremely clearly:
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.
Let's examine the four foundational values described in the Agile Manifesto in detail.
4 Foundational Values of the Agile Manifesto
Each Agile software development component delivers these foundational values in some way. They are the basis to deliver well-working and user-friendly software.
1. Individuals and interactions over processes and tools
People are the force that moves the business and are responsible for the processes. People are more flexible to changes and transformations than tools and are likely to meet customer needs more effectively. If the process was driven by a tool, in the end, there would be a big risk of delivering something that is not expected or has become outdated since the requirements or the environment has changed. What distinguishes people from tools is the communication. Good and timely communication is the key to Agile processes management.
2. Working software over comprehensive documentation
Good documentation is ok, but it is more important that the product should be working and delivered as soon as possible (better yesterday). Working on a precise documentation set, including all the functional requirements, integrations, interface design documents, test scenarios, business approvals, and other documentation may take significant time. This is especially clear if we look at the PMBoK methodology where all the documentation should be prepared before the development starts. This is unacceptable in modern software development because the requirements are constantly being corrected. The Agile approach says that documentation is good, but let's not overestimate it. Documentation in the form of user stories should be enough for a developer to deliver a working function.
3. Customer collaboration over contract negotiation
In the traditional project management scenario, all the agreements on what the product will be, what functionality it will have, and which problems it will solve (and how) are to be described during the initiation phase. Once agreed, they won't be changed later (as a rule) and serve as a checklist to understanding how the project is going. If we look at the documentation, then again, the detailed functional requirements have to be documented completely, together with the Customer, at the beginning of the project.
The possible problem here is that the Customer may have described all the functionality without clearly understanding what the results will be and how it will work. That may be ok for small software projects, but at later stages of development, it will turn into a nightmare for medium and large software projects. The issue is that the Customer is forced to participate in a kind of “product development” before that phase has even started.
What Agile proposes is that in spite of the fact that there should be major agreements that everyone follows, the collaboration with the Customer must be a continuous process in the foreground. The functionality elaboration events must involve the Customer if needed. Also, regular demos should highlight the current state of the product and provide the Customer with a clear visibility of what is done and how it meets their requirements. All of this will help to deliver a good and usable product.
4. Responding to change over following a plan
Software development is often a challenge. The number of problems which must be solved during development is enormous: technical issues, UX problems, many variants on how to design the architecture, and many other challenges. And if this includes constantly clarifying and changing requirements from the Customer, it will be clear that predicting the precise project delivery date and cost is not possible.
Traditional project management standards require a detailed plan of work to be created before the development starts, which would be impossible. Definitely, the plan created from such a general view will be updated multiple times. To avoid that, the Agile Manifesto proposes to move with short iterations. Such an approach helps to change priorities when needed and correct the overall direction, improving the product and moving it closer to the Customer’s expectations.
The Twelve Principles behind the Agile Manifesto
Additional to the Four Foundational Values, the team of seventeen developed the Twelve Principles which describe the culture of the environment where Agile is to be implemented.
1. The early and continuous delivery of valuable software is the main factor of the customers’ satisfaction. Customers would be happier in getting some minimal viable product (MVP) earlier with further improvements and deliveries as development continues, than receiving everything at once and late.
2. If some requirements have to be changed, it is fine, even if it happens during the development. It helps to deliver a product without any significant delay and which meets customers’ needs.
3. When working in sprints, short sprints are preferable because they let the team deliver working functionality frequently. Again, it serves the idea that a short iteration helps better direct the product towards a successful realisation of the customer requirements.
4. The project team and the Customer must work together closely on the product during the whole project. Certainly, it will help to have all the stakeholders and the project team aligned on how is it going and where in order to make better decisions.
5. Trust the team—support and motivate it. The results will be much better when a happy and engaged team is working on a product.
6. Personal communication is better than writing or calling. The team will reach better results if it is co-located.
7. No matter what the process is and how people interact with each other, the working software is always the first priority and is the definition of progress.
8. Agile ideas describe the delivery process as continuous. The project team includes sponsors, stakeholders, and users. Agile processes promote sustainable development at a constant speed. The sponsors, developers, and users should be able to work at that pace for a continuous time.
9. Good technical and design skills, along with the team’s attention to detail, help to keep the functionality delivery pace and constantly improve the product.
10. Deliver the minimum needed to meet the requirements to the Customer, and the solution will be simple and usable.
11. Self-organising teams should have ownership over the development process, communicating with other teams to deliver better quality results.
12. The team must reflect on the processes in order to become more effective and deliver better results.