The Agile Values

The Agile Manifesto recognizes that the use of processes, tools, documentation, contracts, and plans can be important for successful product development, but even more important are the so-called Agile Values: the individuals and interactions between them, a working product (software, originally), collaboration with the customer, and responding to changes.

Manifesto for Agile Software Development

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.

There is no denying that Agile has its origins in software development. Today, even though its application extends to different types of products and services, I would not dare modify the original Manifesto.

Next, I discuss the meaning of each of these values based on the vision of two original signatories of the Manifesto, Alistair Cockburn and Jim Highsmith, and a very relevant author, Craig Larman, creator of the LeSS framework based on Scrum (HIGHSMITH, 2002, 2004; LARMAN, 2003; COCKBURN, 2007). Nevertheless, I will take the liberty of adapting this explanation to a more general product development context.

Individuals and interactions

Valuing individuals and interactions over processes and tools acknowledges that, ultimately, product development work is a human activity and thus depends on human factors for its success. In other words, the people who develop the products have unique characteristics both individually and as a team, such as talents, skills, and knowledge. In addition to these factors, the personalities and peculiarities of the individuals, their interests, their moments in life, their social and family life, and how these elements affect and are affected by the work are fundamental to success.

Considering individual factors, we can say that product development is based on teamwork. The quality of the interaction between team members developing a product is critical to problem solving. In these interactions, the continuous use of communication and feedback is essential to agile practices, especially face-to-face conversations.

The people involved in product development cannot be interchanged like parts because they are more critical to success than their roles in process diagrams. While processes and tools may be important for guiding and supporting product development, they are not substitutes for the people and their teamwork. Relying on them alone will not yield good products. It is with the individuals and their collective effort that we can count on to make the critical decisions for good product development.

We look for processes and tools that can help a team, rather than dictating how their work should be done, so it’s the processes and tools that need to fit the team, not the other way around. In principle, good processes and tools should be the simplest possible that are effective in supporting the work of value creation.

Working product

The working product is the only indicator of what the team has actually built. Customers are interested in results – that is, in something that actually delivers business value.

A working product does not exclude the need for documentation. Documentation can be very useful for product development as it has the potential to facilitate communication and collaboration, improve the transfer of knowledge, preserve historical information and satisfy legal and regulatory needs. However documentation is merely an aid to product development and is less important than the working product itself. As such, we should produce only the amount of documentation that is necessary and sufficient to conduct the work.

A common mistake in product development work is the belief that documentation replaces interaction, serving as a means of communication. Documentation, in reality, can only facilitate this interaction, serving as its by-product in the form of documents, drafts, drawings, notes, etc., which may (or may not) be used as a permanent record. Another common misconception is that documentation can reliably indicate the status or progress of and provide feedback on the work process and the product that has been developed so far. Notwithstanding, the iterative delivery of working parts of a product solves these questions in ways that is impossible simply with documentation.

Customer collaboration

In product development, where there is high volatility, ambiguity and uncertainty, there can be no “us” and “them” in the customer-team relationship. There is only “we”, which means that the customers and team that develops the product are on the same side, collaborating to develop a product that brings value to those customers.

The collaboration between business and team is critical, and involves trust, companionship, joint decision-making, frequent interactions, and speed of communication, as opposed to antagonistic contract disputes in which one side seeks to protect itself from the other.

Respond to change

All product development work must balance planning with adapting, depending on the inherent level of uncertainty. When there is high uncertainty, inspection and rapid adaptation take precedence over planning and the strict execution of planned tasks.

Uncertainty is inherent and inevitable in product development processes, which requires great adaptability. As such, while building a plan in this context can be helpful, remaining glued to an outdated plan does not work in favor of success. In this sense, it will only be useful to follow the plan as long as it corresponds well enough to the current situation. If that is no longer the case, the plan loses its validity and must be modified. When developing a product, practically everything can change in a very short span of time, such as the scope, features, technology, architecture, etc., and thus any plan that may be constructed must be frequently adapted to respond to the new reality.

Short product development iterations allow changes to be made to the product more quickly.