(This is Part 2 of a four-part blog addressing Processes and Tools within Software Culture. This second part discusses the misuse and limits of Tools & Processes. Part 1 can be found here. Part 3 can be found here.)

We provide solutions – it's what we do.

We love talking processes & tools because it's often how we're valued, but it's also often how we value ourselves.

Our multi-billion dollar industry encourages us to jump to Process & Tools solutions quickly as a first option over determining if the problem could be solved with some sensible human dialog.

There seem to be three re-occurring reasons for that:

1. We have an engineering bent, and our first instinct when faced with an Individuals & Interactions "problem" is to rush to a sausage machine solution.
2. There's money in selling Processes & Tools (but not in Individuals & Interactions for our industry at least)
3. Most of us don't have the skills, nor did we sign-up to deal with the problems of human behavior. We are skilled in technology because that's what makes us individually marketable. 

What we're discussing…

By way of example to highlight our daily online professional predilection, here are a spattering of discussions I found today:

• "Best SCRUM tools in the market"
• "Agile vs Waterfall: Right vs Left Brain ?"
• "5 Reasons to choose Scrum over Kanban
• "Agile" vs "agile"
• "Do you even consider about (requirement) traceability in Agile"

Poor grammar aside, we think that we're providing the most value to our clients by promoting and publicly debating our pet Tools & Processes. But honestly, we'd be doing  much more good talking about our pet peeves. In fact, there's 5 times more value in asking why a Tool or Process failed than there is asking which one is best.  

Who's Listening…

Do you know who of our clients race to those discussion groups with baited breath to hear our deliberations….? 

None. That's right. Our customers aren't listening or even eaves dropping. But we're convinced that our professional value is best exercised by fiercely debating Processes and Tools as the answer to better Software Delivery…

Instead, we should be writing blogs about  "5 reasons why clients don't give a crap about Scrum over Kanban." Then we'd get some REAL data to make improvements. 

Some in our community even argue that Processes & Tools improve communication as justification for these debates. Yes – there is potential. But the potential is not in the tool – it's in the Individuals and Interactions. And, there's also a lot of potential for misuse. We often present new tools and processes with the good intention that after the last 5 previously failed Tools, this time around it'll be different – this time it might just correct the cultural problems we experience in our environments… 

A process or tool alone will not create a healthy software culture. Nor is it a surrogate for one.

Processes and Tools are only as successful as the quality of the Individuals & Interactions that support it. Put another way, failure of a process or tool is a function of Individuals & Interactions. That is a symbiotic relationship – not a substitute. 

Our Love Affair with Processes & Tools… 

Often, we propose tools that solve our Individuals & Interactions problems and we're dumbstruck by the lack of adoption by our users. The best tool in the world will fail if its adoption is poor; IT cannot propose a "solution" and expect it to be adored by clients the same way that we do. Adoption requires buy-in and potentially continual education to prove that the tool is actually making lives easier. Their lives too, that is, not just ours… Education also, requires Individuals & Interactions. Instead, we have "implementations…"

Here are some of the perennial problems that you can observe recycling with each new process and tool:

1. "Go look at the board"- A tool or process can be misused as an excuse to reduce face-to-face (or voice-to-voice) human communication:

2. "Why is nothing happening on the board?" – Perhaps my favorite irony: the board is telling us that we're not communicating… It takes human interaction and continual education to achieve adoption. 

3. "There are only 2 of us… Let's create a board to communicate…" – A tool or process might not even be needed, and yet we feel obliged to have one. Safety blanket?

4. "We should be driving the client to the board…" – Tools and Processes were never intended to replace human interaction. You should be driving better communication. 

5. "If you want something, put it on the board…" – Tools and Processes can be misused to completely marginalize client/user input leading to an inferior software product

6. "Don't bug the developers – Just use the tool. They can get more work done that way." – A tool or process can be misused to completely replace the need for human interaction

7. ”Our hope is that Agile will make us a high-performing team…" – A tool or process cannot correct a Company Culture issue

8. "Our tool tells us that we are running behind…" – If you haven't figured out that you're running behind schedule, a tool will not manage (or successfully complete) projects for you.

9. "What does the board think that we should do next?" – A tool or process will not organize people, inherently create better work-flow. The board is NOT your mother. 

Board Members and Customer Service…

The board, no matter how important to you, is an inanimate object and will never create the customer service interface levels necessary for a successful project for your client. You see, the client doesn't care about the board, they care about results. 

Tools or solutions have no inherent ability to change human behavior. If the quality of the Individuals & Interactions at your company is poor, implementing a tool as we love to do, won't fix that cultural issue. And to be fair, this isn't really IT's fault.

If you come to IT to solve a problem, chances are extremely high that you will get a process or a tool. If you come to IT to solve a Human or Cultural problem – chances are still high that you will get a Process or a Tool. 

Business is stuck in always turning to IT for "Solutions" (no matter the nature of the problem) and IT is stuck in providing Processes & Tools as solutions. Instead, we should be asking if we're solving the RIGHT problem.