One tool fits all
The problems that can be caused by mandating usage of particular tools
A common question I get asked when running agile courses is, “What tools should we use”? The answer is always a recommendation of some tools, with benefits and drawbacks I’ve seen from using them — but with the caveat that it should be within the team’s gift to choose the tools that fit them best.
There are very few tools that are expensive enough that it’s worth eliminating them as a cost saving measure — but the team should be mindful of the cost of their tools and if their company has access to a reasonable equivalent then fit in with that direction as much as possible.
One reason for homogenising the set of tools, is to allow large organisations to communicate better, “if we get everyone on one tool, we’ll create better communities and everyone will know each other’s work better”. This will only ever work to a degree, and is likely to just create a very noisy messageboard.
If we instead create communities with the same skills (like a scrum master group), and allow them to choose the tool they use to communicate, this is much more likely to succeed. No tool will ever create great communication, people need to meet face to face — but a tool can be the starting point for this journey, and help provide a sense of community.
“Individuals and interactions over processes and tools” — Manifesto for Agile Software Development
Organisations should err towards a recommended set of tools for particular types of team, project and community, rather than banning or discouraging use of particular tools. Will the team told that they’re using the ‘wrong’ tool feel empowered or trusted? Will the team feel that their expertise is recognised?
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” — Agile Principle #5
Empowerment and motivation take a long time to cultivate, and not much to kill. We want agile teams to be able to try new ideas without fear, otherwise it is unlikely the team will be able to continuously improve.
A team should be made up of experts, brought together to solve the set of problems that a project requires. It’s hubristic for someone outside this team to think that they know which tools are right and wrong for the team to use — but people will have their own experiences with tools which could be shared, with the team deciding they would like to try and see if these tools work for them.
A recurring discussion in teams I’ve been in, is whether we should be managing the backlog with Trello or Jira. They both have positive and negative points, and are both suitable tools. Imagine you are in a team using Trello — boards made up of lists of notes, but one day you are told by management that the team must move to Jira — a more complex tool that requires more set up and process.
That team might think that management don’t trust them, and want to track their work to a minute detail. The team will be disrupted while they move across to the new software, and will worry that this is time taken away from delivery — their next sprint review might not have much in the way of demos, and they will be held accountable. They will need to help each other learn to work with this new tool.
The reason for changing to Jira was innocent, management just wanted to be able to see backlogs across a few projects in Jira. Because it was imposed on the team, this was not explained to them, and wild theories grew. Jira is a perfectly good tool — it might be that it’s a more suitable tool for that team, but in choosing to impose this on the team, rather than collaborate and support the team in their choice, the management have caused drops in productivity, motivation and empowerment. Was it worth all this, for the simple act of a tool change?
