The Agile Manifesto – Individuals and interactions over processes and tools

Here we have the agile manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Let’s look at the first one…. individuals and interactions over processes and tools

Often processes are put in place so that command and control structures can measure and control what is happening. For example they may have been put in place to control a high risk situation or to fix an actual problem that occurred. There are pitfalls in processes that you should be aware of:

• 1) Doing process activities that add no value.  Firstly my post on valuable activities (please read) highlights possible waste, your process may be insisting on activities that are not always valuable:

Valuable versus value – your customer’s needs

• 2) Poor information passing due to rigid process. Next consider tacit information, this is information that is it your head but difficult to pass along. This is linked to one of the seven wastes called motion (in manufacturing it’s called transport). Knowledge degrades as it is passed on. Your process may be insisting on outputs of a particular nature, such as a certain type of diagram to follow the process. This can ignore tacit information, people learn in different ways and people have different skills (and techniques) in passing information. A conversation can minimise the risk of poor information passing in a way that emailing a set diagram every time  never could.
• 3) Tracking using tools to give confidence that something is working even when it isn’t. I could look at a process and say that it is successful if it is followed. To see if it’s followed I use a tool. Let’s consider TDD, I track unit tests numbers and I see lots of unit tests so I assume it’s working. What if those unit tests are poorly written? Wouldn’t it be better to have a conversation to discuss with experts as there is a lot more complexity which cannot be determined by a measure. Note: there is no problem with measurements but be careful to understand what they do and don’t give you.
• 4) Choosing your tool to purely measure but not collaborate. What if I chose a tool that measured code quality over a tool that helped improve code quality?
• 5) Your process gets in the way of collaboration. If I insist on a specific way of doing something it may be hindering collaboration. For example, someone wants to work with you to drive out a solution, but the “process” is for them to provide the solution then pass it to you for review.