Tooling, as it turns out can be a very emotive subject. Everyone has their favourites but often we find ourselves in situations where we don’t get to choose. And even when we do get to use our favourite, in all likelihood there are others using it under duress, waxing lyrical about the superior feature set of an alternative product and how pleasant life would be if only we were using that instead.
I have a few principles, guidelines or rules of thumb when it comes to tooling, and the tension, conflicts and friction it can cause across a team
Understand what you are trying to achieve
Before you even start thinking about tooling or any other type of software you need to understand what you are trying to achieve and why you think a tool might help. If you can’t answer that question than how can you expect to select and evaluate a solution.
Let’s say you want to select a tool to assist your software delivery. You might have team members in different locations so simply representing work items as sticky notes on a wall does not cut it. Therefore, the team needs something that enables the creation of work items that are visible across all team members. You also might be finding it hard to understand what work is being done, so you want something that makes it possible to see which work items are currently being worked on, and provide an indication of who is delivering a particular piece of work.
Once you understand what problems you are having you can determine what is required from the tool.
Understand how the tooling has been designed to solve a particular problem
For the software team building a tool, a problem such “as running a SCRUM team” is a wide problem space. That team will have had to build an understanding of how their software solves that problem, perhaps looking at best practice or by analysing a number of past successful projects. They will have also made their product adaptable and configurable in order to attract as many customers as possible.
When you look at the tooling from different vendors you may see that they may have solved the same problem in a different way. This might have been for a number of reasons which include understanding the problem differently, prioritising different features and trying to differentiate themselves in the market.
How you see the problem space and how the vendor does is likely to be different. They will see it from a wider and generic perspective, and you will see it from the narrow, specific point of view of the immediate problem you are trying to solve.
Adapt in both directions
Once you understand the problem you are trying to solve and how the chosen package aims to solve it, both sides need to compromise.
In an ideal world, the software would solve your problem, immediately, out of the box or maybe with some minimal configuration tweaks. More realistically you should expect to do some configuration to tailor it to your circumstances. It is likely that products will be design with this in mind.
However, if you are finding that you are having to warp the product out of all recognition to get it to work for you, even when you are both working in the same problem space, you need to ask yourself some searching questions.
- How much effort, time and money is required to maintain heavily customised software
If this much customisation is required are we really in the same problem space
I have seen a number of teams warp a software solution completely out of shape without asking themselves whether they should change their ways of working to better suit the software. It is highly likely that the software vendors understand the problem space better than you and have created a tool that deals with the majority of typical usage scenarios so why are you different, why are you not typical?
Standardise where possible
Standardise in this context means using the selected product across teams, business units and even organisations. This means you get the benefits of scale. Lessons learnt by one team can be shared by others. A standard solution also means that operating costs are likely reduced and there are only one set of administrators and one set of hosting costs.
This also may mean you don’t get to choose. The software might already be available so this is the default choice.
However, many organisations miss the next part. This is that choice still exists if the product really does not work in a given situation. Unfortunately, the lure of cost saving and efficiencies drown out the small teams who are greatly hindered when forced to use the wrong tool for the job.
Having a standardised solution is not the end – it is the beginning. The usage of the software needs to be continuously reviewed to see if it is still the right solution. The product needs to be upgraded and patched and there should always be an eye on the other solutions in the problem space. An alternative product that was previously discounted may now be a better fit.
Accept the choice
And finally, if the choice doesn’t go your way you need to accept it. You need to get behind the choice and make it work for you and your team. As technologists, there are always going to be better choices. It is often a case of the “grass is always greener”. And maybe you’re right this time but maybe you’re not. It is all too easy to fall into a trap, where you believe that a tool will solve all problems. Usually what happens is that the tooling will be switched only to find that you have all the same sort of problems. It wasn’t the tooling that was the solution after all.
In my experience the problem usually lies with people before it does with software. If your people can’t solve your problems, then you should not assume that software will.