
Agile value: 1 – Individuals and interactions
The Agile Manifesto describes four key Agile values which are expressed in pairs and each covered in separate articles:
While there is value in the items on the right, we value the items on the left more
Manifesto for Agile Software Development
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The first of the Agile value pairs is at the heart of what Agile represents. It’s worth a careful walk through.

Individuals and interactions over processes and tools
Manifesto for Agile Software Development
On the right we have “processes and tools”. This is the key domain of project management and “traditional” approaches. This side focusses on control and reductionism. There is traditionally a strong focus on Reductionism in Western thinking. We are taught any problem can be solved by decomposing it into predictive parts and solving these components.
Reductionism is very successful for complicated problems. There is a strong linkage between cause and effect. As a result it has been central to classical management but Agile rejects the idea of reductionism. Agile approaches are instead designed for complex problems which have less linkage between inputs and outputs and exhibit dynamic and adaptive behaviour.
Remember that the manifesto does not say that the items on the right are bad. It clearly states that we do value the items on the right, which are here analytic skills in planning.
It would be a mistake to imagine that Agile development “rejects rules”. Rigour in how we develop is important. All developers would agree that (for example) peer review of code adds value, although there may be different approaches taken. One team might use pair programming and integrate review into the development process by having two people working together at all times. Another team might mandate that each piece of code is assessed by a peer before integration into the final product. A third team might have a design authority such as a lead developer perform all reviews. When setting up a team you must address these basic processes. How do we code, how do we review, how do we measure progress?
We value more the item on the left, which is “individuals and interactions”. These are the key factors we need for managing complexity. Most of the Plays on this site relate to these. Process and tools have value initially. However, past a certain point you do not improve by adding more process and tools. Instead to perform at a higher level you have to focus on individuals and their interactions with each other.


Leave a Reply