Tooling

Tooling seems out of place in a discussion about processes and product development teams. But, especially in the long term, it has an impact on the processes you build and on your culture. I often frame conversations about tooling as a "building versus buying" conversation.

In most teams I worked, we didn't build any tooling for our workflow. We bought bug tracking software, task management, chat system, and so on. It seemed obvious to me that you should never build such a tool. My opinion changed a few years ago while I was doing research into digital Kanban applications.

I have "my own definition" of Kanban, so the research was quite frustrating. Tools did either too much or not enough. At some point, I started to consider building the simplest tool that could implement Kanban the way I wanted. And it was an intense fight with myself. I wasn't used to the idea of building workflow tooling for my own teams. What convinced me at the time was a mix of frustration for "X does too much, Y doesn't do enough" and my own obsession with Kaizen.

I've often found myself feeling limited by how much I could bend the tool at hand while trying to continuously improve processes. In most teams, it takes months to understand "how we use the bug tracker", even though it's the same tool you were using a month ago in another company. Continuous improvement is too vital to scaling processes in product development teams for anyone to overlook opportunities.

Be aware that I'm not trying to suggest you should build workflow tooling all the time. What I'm suggesting is that building some tooling can act as a high multiplying factor for improving your processes. As in every discussion about "building versus buying", the expected return on investment should drive your decision. Consider what to build for your workflow. A great starting point is a small tool that visualises your workflow. Shed some light on those dark corners in your processes, look for issues that come up too often.

A while ago, while leading a team, I noticed that people would ask at the stand-up why a story was blocked literally every time we had a blocked story. When we built our own digital Kanban application, we made it a requirement to leave a comment every time someone blocked stories. The questions went away.

This is a tiny improvement, but I wouldn't underestimate its power. Such improvements to your workflow allow individual contributors to change their workflow. Now I invite you to reflect on how often in your career you found yourself in a team that could change their workflow without hacking the tooling at hand. I would bet it didn't happen that often. In my experience, most teams give for granted that you only build tooling for your own infrastructure. You automate builds or the way you deploy localised content to your website. I'm not trying to undermine those initiatives, quite the opposite. They're important. Encouraging the team to look for improvements in these areas is part of your job as a leader. In practice, you won't need to do much about this because developers feel the pain of tedious or error-prone tasks every day, much more than their leaders. They work with these tools (or the lack of) every day. On the other hand, people busy with day-to-day tasks have a harder time looking for ways to improve workflow-related processes. There is even a cultural factor, a sort of social pressure among developers to accept processes as they are because someone else takes care of them. How many times have you heard a developer complain about issue tracking tools? Probably plenty of times. But you probably don't hear so many developers proposing a different tool. It's understandable because it would be a complicated change for a company; even though it would still be more constructive than just complaining. Even more rarely, developers propose changes to the processes they are part of. And if they don't, that's on their leaders. It is a leadership duty to make sure team members have the right to improve the way they work.

Which tools you buy and how you use them, which tools you build and why you choose to build them is part of your culture. Culture makes a big difference in scaling processes. There's no process that works forever. Processes could always be improved and the reason is simple: a process changes slower than your needs do.