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.
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!
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:
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".
[W]hile there is value in the items on the right, we value the items on the left more.