For simple work, like choosing what a good tool would be to drive a nail into a board, there are some pretty simple and best answers we can apply. But even a simple sounding question like, “What tool should we use to express our Product Backlog most effectively?” can lead you in a multitude of directions. When selecting a tool for complex, knowledge work involving humans, consider the following guidelines to help bring down the emotion and find a tool that helps you get your work done.
People > Processes > Tools
We’re trying to help people get their job done better, so we must remember that people are part of the equation and are the thing that matter most. People are messy, and that’s what makes us great. Processes help us with some of that messiness, in service of accomplishing something in a better way. Tools are meant to help us automate processes and make it easier for people to work together. For complex work, tooling should emerge. Pick your tools last.
There’s another important note here, which is to keep your tooling simple. Remember, tools are here to help us solve a problem and work better. If the complexity of the tool gets in the way of solving the problem, or in other words when the tool becomes the problem, it might be time to re-evaluate if this tool is really serving its purpose and if we should continue using it. More on this later.
No tool is perfect, no tool is permanent
The tools we select to get our job done are selected with the limited set of knowledge and the options we have at the time to solve the problem at hand. Problems often change, as do work styles, processes, and the people involved in the work. Pick a tool that helps you get the job done with what you know at the time. If a tool is getting in the way of people being more effective at their work then change the tool, not the people or processes.
It should be noted though that once you start investing in using a tool to help get work done, a change away from a selected tool might become costly. This should factor into your initial tool choice as much as it can (remember, you can’t see the future - go with what you know) as well as your choice to move away from a tool. Beware the sunk cost fallacy in deciding to stick with a tool.
Start with what you already have
Do you know what you already have access to in your organization? If not, find out before making a tooling choice. You might be suprised to find that you already have access to a tool which fits closely to the problem at hand. Using it, while perhaps cumbersome at first, can have immense benefits such as simplifying communication and information sharing across your organization, leveraging the wealth of knowledge of people in your organization already using that tool, potentially cheaper licensing, and less mental overhead remembering which tool to use for which group/task/project. I’m often suprised to see teams picking out new UI automation frameworks for their application testing, when they don’t even stop to find out that their organization has two preferred tools which could likely get the job done just fine and people who can help them set it up.
Just because something isn’t well understood doesn’t mean we shouldn’t use it. Try, learn, and ask questions. Different people will absorb and master tools at different rates. You’re not likely to make everyone happy with any single tool selection, but that doesn’t mean the tool isn’t effective in its selected purpose across the organization. If the tool is really impeding work beyond a learning curve, perhaps it’s time to consider something else.
When you ultimately choose to pick a different tool to help solve a problem at hand, speak to the benefits it provides over existing options and also explaining what it will cost (mentally, effectiveness, monitarily, etc.) the organization. This will go a long way toward helping everyone understand how you made your informed choice. Another good thing to consider here is, could we not just add a tool, but replace and or remove multiple tools by selecting a new one?
Lastly on this, just because there is a tool or tools your organization uses to accomplish similar work doesn’t mean it has to be the thing you use. The points above about having the discussion about why are important here, but a key why is that tools are here to serve people. You’re a person. Make sure your tool serves you and try to do it without that use causing pain and lowering the effectiveness of those around you.
Less is more
Coming back to mental overhead, the more tools we use the more we have to remember which one to use where, and how they’re connected, and where we put the notes from last week’s impromptu meeting. By using less tools and tools with broader coverage, we can reduce this mental overhead. The cost is that any given tool is likely less tailored to your specific need. That’s okay, because your needs and problems are going to change. Remember, no tool is perfect.
I used to use older versions of Team Foundation Server as an example of this. For source control, it was okay and not overly complicated. It’s build processes were brittle and hard to extend. The work item tracking it had was sufficient, if not overly complex. It’s testing tools were definitely not the cream of the crop. However, as an integrated application lifecycle management tool connecting all of those pieces together and showing how work flowed through a system from idea to product it was hard to beat. No one else offered such integration of information, enabling more informed decisions that were quicker to act on. The whole was definitely greater than the sum of the parts.
This too will cause teeth gnashing
These are the thoughts that go through my head when picking tools to use. I’m sure some of you are disagreeing with me as you read this, and that’s perfectly okay. People get attached to the tools they use. They embue them with special powers like a talisman and feel a sense of loss when they their favorite tool isn’t available to them. It’s natural, but just stop to think for a moment if you’re truly impeded or if your response is purely emotional. Tools don’t have emotions. Be cautious how much of your emotional energy you invest in them.
What principles do you follow when selecting tools to help you do work? Comment below and help us all out!