The five failures of agile tools

For organizations transforming their technology delivery from traditional to agile approaches, there’s a need to evolve team practices, tools, leadership behavior and stakeholder change appetites in parallel to avoid realizing the risks of being agile while standing in a waterfall. Owing to the popularity of the agile movement coupled with mainstream obsession with DevOps, legions of tool vendors stand ready to sell you snake oil solutions to satisfy all of your agile delivery needs.

But before you sign that vendor contract, consider the following five failures of agile tools.

The inability to incorporate different perspectives

A tool suite’s ability to capture of relevant metrics, produce colorful reports or deliver sexy dashboards is worthless if process to enter or maintain the underlying information is not equally user friendly. While procurement decisions are normally taken by those consuming the output of the tools, not including evaluations by project team members will provide those decision makers with all the form but no substance.

An inability to integrate

Agile tooling presents two distinct options. Buy a comprehensive tool suite from a single vendor that covers the whole construction and delivery lifecycle or purchase distinct best-of-breed products and integrate them. If your company is fortunate enough to have limited technology standards, the former approach might work well, but for most larger companies heterogeneity is the norm so the decision is often made to go with point solutions. No harm in this approach, but if integration considerations are not part of the product evaluation process you could end up with functional siloes (e.g. development or testing) dictating the bells and whistles required for the point products which they would primarily use and no one will be focused on end-to-end operability.

No standards, guidance or governance

Few tools will be installed out of the box with the appropriate usage models for your organization baked in. While you could take a hands-off approach to guidance letting each team figure things out for themselves, the free-for-all which ensues will catch up with you when you look at supporting portfolio-level processes or when there is a need to align the work of separate agile teams. While we want to provide flexibility where beneficial at the project team level, there is a need to define a minimally sufficient set of standards and provide all users with tool training as part of their onboarding to ensure they don’t shoot themselves in the feet.

A lack of discipline

Agile success exposes the need for greater levels of discipline than with traditional delivery approaches. Planning and work management tools can help teams objectively forecast when their next release will be ready but only if the team is disciplined about entering and updating the status and size of all work items. Team collaboration environments are a great way to overcome geographic distribution challenges but only if the information uploaded is accurate and complete.

Tools don’t fit the practices

While most tools can be configured, few possess the ability to be fully customized nor is that a desirable practice unless a company wishes to assume the ongoing maintenance of such customizations. Given this, some compromises have to be made on how consistent the nomenclature or workflow is between the tools and the procedures they are expected to support. However if insufficient effort is spent up front in defining the must-haves from a lexicon or process perspective, these gaps will become a source of data quality and team member frustration issues.

Tools can be a powerful enabler, but a fool with a tool is just a more dangerous fool.