I was reviewing the agile manifesto and this is one of the core principles of it. What does it mean?

I feel that people need processes to work efficiently, especially in large scaled matrix organisations. I have seen projects run where there were none and devs had free reign only to turn into a chaotic mess.

  • 1
    Just that interactions have more value than static processes/tools. [W]hile there is value in the items on the right, we value the items on the left more. – Todd A. Jacobs Jan 21 '18 at 21:00
  • 1
    It would be great if the principle were quoted properly: "Individuals and interactions over processes and tools" – Alan Larimer Jan 22 '18 at 13:14

Here is how I always look at it:

The items on the right should serve the items on the left.

Individuals and Interactions over Processes and Tools

We have all known processes or tools that help us do our job better. We've also all known processes or tools that may have once served a purpose, but now just get in the way. As long as the process or tool helps individuals with their interactions with others, they're good. When they hinder interactions, we should look at more effective processes and tools.

Working Software over Comprehensive Documentation

There is documentation that helps us build great software. There is documentation that helps us maintain the software after it is done. Then there is documentation that sits in a drawer, never to be read. We should write a sufficient amount of the type of documentation that we need, not more.

Customer Collaboration over Contract Negotiation

Many contracts are about protecting parties from each other, not improving how the team and their customers interact. A good contract can form the basis for a great, collaborative interaction between the two parties.

Respond to Change over Following the Plan

Plans change all the time. When we invest too heavily in a plan, we become attached and it feels safe to follow, even if we know we're following it off a cliff. If a plan is built by a committee of smart, high-payed people and it fails, it's their fault, not mine. But if I see it failing and I change, I take responsibility. This is why there are so many examples of massive failures where the people following the plan kept following it long after it was clear it wasn't working.

That doesn't mean planning is bad though. With emergent just-in-time planning approaches, we can gain enough context to make educated guesses about how the future will unfold while at the same time we can be ready to pivot as soon as the need is apparent.



The phrase means that interactions have more value than static processes/tools, but that processes and tools have value as well. It's really no different than my repeated calls for people to define and agree on their processes, and then find tools to support or automate the things they want to do. Valuing tools and processes more than people or interactions doesn't lead to rigor; it leads to rigidity, which is the opposite of embracing change; but note that a complete lack of rigor is bad, too!


The phrase [i]ndividuals and interactions over processes and tools from the Manifesto for Agile Software Development is often abused as permission for teams or individuals to do whatever they like and call it agile. However, this type of "cowboy agile" is definitely not what is meant by the phrase. See Ron Jeffries' excellent We Tried Baseball and It Didn't Work for a great example of how this phrase can be used as an excuse for lack of framework rigor, and how disastrous that can be.

The four values of the manifesto are carefully structured. The manifesto also says: [W]hile there is value in the items on the right, we value the items on the left more. So, the manifesto isn't saying processes and tools have no value; it's just saying:

(people + interactions) > (processes & tools)

For example, user stories aren't specifications. They are placeholders for conversations with stakeholders or end users, and act as a sort of shorthand to aid communications. So, on the one hand, user stories are a tool; on the other hand, they are simply there to facilitate interactions with people!

See Also

The values of the manifesto are further clarified by the Principles Behind the Agile Manifesto. For example, you are expected to understand individuals/interactions over processes/tools through the lens of the people-centric principles such as:

  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

None of these things say formal process is irrelevant, or that tools are verboten. It just says people and interactions first; then mix in the right amount of tools and processes to support those people and interactions, and to help the project run sustainably.

Agilists don't let tools drive the project! People drive, and then tools and processes are deliberately selected (and continuously re-evaluated and adapted) to help the team reach its ever-evolving destination.


Individuals and interactions over processes and tools means that where possible we favour people talking to each other.

When I encounter an impediment that is stopping my team making progress, my preference is to talk to people and collaborate to finding a resolution. In some organisations there may be a more rigid process in place or you may be required to use a particular tool.

Examples might be:

  • I want to use a new Java library but my organisation requires that I fill out an online form and await a committee sitting to discuss my request. My preference would be to talk to somebody to explain what the library is used for and quickly find a resolution.
  • We have an urgent need to reboot the continuous integration server, but the administrators require that a request is put in to JIRA before proceeding. My preference is to talk to the administrator, explain the problem and get a quick resolution. Perhaps we can agree a better way to work that speeds up the resolution of this kind of request?
  • Our team could do with some help from a DBA, but the process in place means that DBA's cannot work directly with the teams. My preference is to talk with the DBA and explain my problem. If they have the time, they can offer some help and we quickly move on.

Processes are really important and people do really need processes to perform task effectively, but this is relevant to a kind of standard tasks. There could be however some tasks which would take much more time to resolve using the established process rather than a simple conversation between two persons.

I would rephrase this statement to "Processes are for the people but not vice versa".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.