In the few last years I have repeatedly heard people describing “Agile” as a methodology and using “Agile” and “SCRUM” as interchangeable words and concepts with no distinction between the two.

“Agile” is not a methodology but a set of values ​​and principles that was established in 2001, when 17 people met in order to search for points common to best practice in software development. This meeting resulted in the so-called Manifesto for Agile Software Development. The manifesto expresses values ​​and principles that determine a type of approach and there are methodologies that align with the said approach. For example, SCRUM is an “Agile” methodology. This means that the SCRUM methodology shares values ​​and principles stated in the Manifesto and that it is therefore a methodology that follows an agile project management approach.
Agile methodologies have two fundamental characteristics: they follow an approach that is both iterative and incremental. Iteration means working in short cycles of interaction. This allows feedback to be received before the job is finished in order to modify the product and improve it on the fly, adapting it to the client’s expectations. Having an incremental process means that you do not have to wait until the final version of the product is developed in order to implement it. The idea is that as soon as you have something that adds value to the customer, it goes live in the market and you can then make improvements based on the behavior of the product in the market.

Ms. Winters* raises a key issue by saying that Agile and Waterfall solve different problems. Waterfall focuses on solving the problem: “Are we delivering the project on time and within budget?” While Agile is designed to solve the problem: “Are we delivering the right product?” Through the earned value technique, Waterfall measures schedule variations and budget variations, trying to answer the first question; Agile tries to answer the other question through iterative demonstrations and productions of the product that increase in functionality and characteristics.
If I had to define “Agile” with a single word, I would say: “listening”. Listening more to the team, listening more to the user, listening more to the client and, in general terms, listening more to all project stakeholders. It is about listening in order to understand and improve.

Finally, it is worth clarifying that agile approaches are not new; the Manifesto just brought together practices that were already in use. In the 1930s Shewhart was already developing iterative cycles to improve products and processes. Organizations such as NASA, IBM, Honda and Toyota also applied Agile practices many years ago.

If you want to go further back, whether or not you have faith, the creation of the Earth in The Book of Genesis describes a process that follows Agile principles; a series of releases are verified and developed day by day until the seventh day.

Myths and Values

In the Manifesto for the Agile Development of Software, the authors state that they value:

  1. Individuals and interactions over processes and tools
    2. Working software over comprehensive documentation
    3. Customer collaboration over contract negotiation
    4. Responding to change over following a plan

Although the manifesto clarifies that: “while there is value in the items on
the right, we value the items on the left more”, it seems that our tendency for neurosis (thinking in terms of White or Black) leads to the creation of 4 myths associated with the agile approach, which I expose below:


  1. There is no governance; everyone does what they want.
  2. There is no documentation; the organization does not keep records.
  3. The client does not assume responsibility; they change the rules of the game all the time.
  4. Nothing is planned; nobody knows what is expected or against what base line work is to be compared.

Agile approaches have clear rules but they are different from the ones we are used to following. The members of the team have a high degree of autonomy and participation in decision-making in relation to the tasks required to complete the deliverables. They also have high relative levels of responsibility. This way of working generates a greater sense of purpose in the team and leads to higher levels of involvement and productivity.

Agile approaches document the work done, compare the predicted and real outcomes and yield lessons through hindsight, but they do it in a way that is different to that which we are used to. In predictive approaches, we are accustomed to undertaking a high degree of documentation regarding plans, requirements, construction, testing and implementation, while in agile approaches the documentation is less extensive and occurs only during iteration.

Documentation is considered important to the extent that it helps us to understand the work needed and that way in which it needs to be done. In the environment of constant change, however, it is not possible to completely document all requirements at the beginning of the process. In an Agile process, it is less important to have exhaustive documentation and more important to get working products to the market in order to use client feedback to support continual improvement of the product.

The rules of interaction between the client and the provider are clear: the client frequently interacts with the team to give feedback, and everyone considers themselves part of one team with a common goal. Agile approaches are suitable for changing business environments in which there is clarity of vision but no clear definition of scope. Therefore, a contract made at the beginning of the project, with a high level of detail, does not add value to the solution. On the contrary, being able to read the market after the solutions generated have gone live in each incremental cycle is vital to continual development of the product.

In projects that apply an Agile approach, planning does take place, but instead of the majority of the planning taking place at the beginning of the project, the Agile methodologies disperse the planning throughout the process. They value more highly the ability to adapt the plan to the context than the need to have a comprehensive plan and execute it perfectly without variations. In the predictive approach there is also scope to adapt but it happens in response to change requests; in the Agile approaches (for example, in SCRUM) the task list is reviewed and prioritized periodically, as change is inherent in the model.

In summary

It is not about having a black and white perspective in terms of People vs Processes, Working Products vs Documentation, Collaboration vs Contracts and Planning vs Adaptation to change. It is about understanding the iterative and incremental essence of the Agile approach and deciding in which cases and contexts it applies, in which cases a predictive approach is preferable and in which contexts a mix of approaches is required during different phases of the project.


*See: Why Agile is Failing at Large Companies; Geri Schneider Winters