History of the Agile Manifesto

The industry was frustrating in the 1990s. The project management methodologies of that time did not allow producing quality products in an acceptable time. As we already know, the business requirements to software tend to be clarified or even changed during 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 used to work well, when technologies were developing slower, and the 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 actively used: Rapid Application Development (RAD), Scrum, Extreme Programming (XP), Feature-Driven Development (FDD) and others.

In 2001 seventeen software developers created these methods, including Jon Kern, Kent Beck, Ward Cunningham, and Alistair Cockburn, who met at Snowbird, Utah to discuss the approaches in the software development and the challenges it was facing by that time. On that meeting the Agile manifesto and the Twelve Principles were elaborated and written.

The original Manifesto does not describe anything in details but defines the idea extremely clear:

“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 see the four foundational values described in the Agile Manifesto in details.

4 Foundational Values of the Agile Manifesto

Each agile software development methodology delivers these foundational values in some way. They are the basis to deliver a well working and user friendly software.

1. Individuals and interactions over processes and tools

People are the force that moves the business and the responsible for the processes. People are more flexible to changes and transformations then tools and likely to meet customer needs more effectively. If the prices were driven by a tool, in the end we would have a big risk to deliver something what is not expected or outdated as the requirements or the environment have changed. What distinct people from tools is the communication. A good and timely communication is the key of agile processes management.

2. Working software over comprehensive documentation

The good documentation is ok, but yet the product should be working and delivered as soon as possible (better yesterday). Working on a precise documentations set including all the functional requirements, integrations, interface design documents, test scenarios, business approvals and other documentation may take significant time. Especially if we look at the PMBoK methodology where all the documentation to be prepared before the development starts, what is non-acceptable in the modern software development is that the requirements are being constantly corrected. The Agile approach says that the documentation is good, but let’s not overestimate it. The documentation in a form of the user stories should be enough for a developer to deliver a working function.

3. Customer collaboration over contract negotiation

In the traditional project management 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 understand how the project is going. If we go to the documentation, then again, the detailed functional requirements have to be documented completely, together with the Customer in the beginning of the project. The possible problem here is that the Customer 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 it will turn into a nightmare for medium and large software projects later. The problems is that the Customer is forced to participate in “kind of” the product development before that phase has even started. What Agile proposes is that in spite of 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 highlight the current state of the product and provide the Customer a clear visibility of what is done and how it meets their requirements. All if this will help to deliver a good and usable product.

4. Responding to change over following a plan

The software development is often a challenge - the number of problems which must be solved during the development is enormous: technical issues, UX problems, many variants on how to design the architecture and many other. And if constantly clarifying and changing requirements from the Customer, it will be clear that is not possible to predict precisely the project delivery date and cost. The traditional project management standards required a detailed plan of works to be created before the development starts, which would be impossible. Definitely the plan created on such a general view will be updated multiple times. To avoid that, the Agile Manifesto proposes to move with short iterations. Such approach helps to change priorities when is needed and correct the overall direction improving the product and moving it closed to the Customer expectations.

The Twelve Principles behind the Agile Manifesto

Additionally to the Four Foundational Values, were 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 if getting some minimal viable product (is where the MVP stands for) earlier, with further improvements and deliveries, than if receiving all at one and late.
2. If some requirements have to be changed, is fine, even if it happens during the development. It helps to deliver a product without any significant delay and meet customers needs.

3. When working in sprints, the short sprints are preferable because let the team deliver working functionality frequently. Again, it serves the idea that a short iteration helps direct better 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 and take 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. The personal communication is better than writing or calling. The team will reach better results if is co-located.

7. No matter what is the process and how people interact each other. The working software is always on the first place and defines the progress.

8. Agile ideas describe the delivery process as continuous. The project team including sponsors, stakeholders and users Agile processes promote a sustainable development at a constant speed. The sponsors, developers, and users should be able to work on that pace continuous time.

9. A good technical and design skills along with the attention to details of the team help to keep the functionality delivery pace and constantly improving the product.

10. Deliver the minimum needed to the Customer to meet the requirements and the solution will be simple and usable.

11. Self-organising teams having ownership over the development process, communicating with other teams deliver better quality results.

12. The team must reflect on the processes in order to become more effective and deliver better results.