Be careful with agile tools! They can ruin agility.
Contrary to popular definitions, Agile is not a methodology, it is a culture. One that is created and nurtured by specific values and behaviors and not defined by processes or tools.
Actually, implementing strict rules and complex tools will likely deter organizations from achieving agility.
Helping agile teams on their agile adoption journey for more than a decade, we came to the conclusion that four of the key ingredients of the agile mindset becomes endangered by so-called "Agile Tools":
- Self-organization
- Transparency
- Focus and creativity
- Adaptability
Unfortunately, these four traits are often bypassed when middle-managers advocate for enterprise-grade tools that present the illusion of "control", rather than driving the team to success in an agile mindset.
A common scenario that we've seen in many organizations is that managers ask team leaders to find a solution for handling projects and work. Through their research, teams often select highly customizable and complicated tools with known names, with the misconception that those will bring the best agile practices to their team.
The issue is that: rather than facilitating agility, tools often ruin adaptability, a key ingredient of successful agile teams. Overly complicated tools add bureaucracy and feed into the controlling environment that is against the core values of agile.
From our experience working with all types of companies and organizations, we've encountered the following problems when implementing enterprise-grade "agile" tools.
Here are 4 of them:
1. Replacing consent with control
Most managers like the idea that they can regulate productivity with strict workflows, easily enforced by the work management tool. Sloppy (or inattentive) team members often break agreed rules either intentionally, or unintentionally.
To stop deviations against processes, it's easier to set up a rule in the tool than establishing strong agreements about certain standards within a team.
There is nothing wrong with using the Tool's capabilities to warn a team member if she is about to mistakenly break an important agreement. The problem arises when the default answer to irregular behavior becomes: let's set up a rule in the Tool. This practice transforms important team values such as empathy and shared understanding, into regulations and control.
2. Sacrificing transparency for process compliance
As a carefully configured Tool can be a viable solution for assuring process quality, it often comes at the cost of decreasing transparency. Unexpected situations and changes could prevent teams from complying with the preset processes in the tool.
For example, if a team member with the appropriate access level to move an issue to a certain stage goes on a sudden leave, strictly configured tools make it difficult for other members to make changes to the issue status.
The result: the issue stays in the current state and there's no accurately updated information about the process. In turn, instead of being an up-to-date source, the process set within the tool is preventing the tool to serve an important value of agile: transparency.
3. Luring the teams focus away from valuable work
Tools become incredibly clever and sophisticated these days. The possibilities for customization are endless. When configured appropriately, the tool offers a solution for almost every possible situation. Moreover, becoming an expert in The Tool turns into a valuable skill in the labor market.
The Tool becomes so interesting, that the creative energies and productive time of the team are spent on hacking The Tool to make sure its capabilities are fully utilized. The tool becomes a goal and the team constantly split their attention between tuning the Tool and delivering valuable work.
Often, time is allocated to work on the specs of the tool just because the tool provides a specific possibility - rather than because it is a needed step for a process. When, which is not so uncommon, a tool can't be configured to support a unique idea of the team, they may abandon the idea.
Instead of serving them, The Tool starts to rule the team.
4. Favoring conformity over autonomy
Once a company invests a good amount of money in a sophisticated tool (that promises never-before-seen transparency and a sense of order), they try to solve everything with the tool. When the company tries to manage everything with a single tool, it will face interdependencies and conflicts in process requirements across teams.
The solution?
A dedicated Agile Tool administration team, which is responsible to maintain the organization-level integrity of the system.
As it is usual, someone from the IT Department will be in charge, which takes ownership of the tool away from the development teams' control (ironically, the team will need to submit a ticket in the Tool for the Tool administration department to modify the setup of the Tool).
This situation attempts against agile's core value of "autonomy". Because the development team now depends on a third-person to manage specific aspects of their own process, there's a lack of flexibility and the adaptability and productivity of the team slow down.
Summing up
We have listed various reasons why we believe that some Agile tools could really hurt agility and prevent teams from a successful adoption of the agile mindset.
Although teams could configure complex agile tools to be more permissive, the tool itself is still unfriendly because it is designed to limit freedom and enforce processes.
As we said in the beginning, becoming Agile is more about getting immersed in the right values as a team, with the goal of moving towards the successful delivery of work.
Our advice is that organizations shouldn't expect tools to make their teams more agile, as the more they rely on a tool, the more rigid it will make the process. Instead, focus on the core values of agile and in finding a tool that works without slowing the team down.
