The Trouble with Agile Tools

“Individuals and interactions over processes and tools.” The Agile Manifesto

Is it just me, or have any of you noticed a gap between the software that agile teams produce and the software that agile teams use?  Think about it.  When an agile team develops software, they follow good design principles in an effort to make their software easy to use.  That’s good, but not good enough by itself. They demonstrate the software to stakeholders, partners, and end users to collect that all-important feedback, and then tweak, adjust, and even re-design as needed to make their software as usable as possible.  These teams know that just solving the problem is only half the battle. If the solution is too cumbersome to use, people won’t use it, and if people won’t use it, the project is a failure.

So why is it that many of these companies that produce amazingly usable software almost cripple their teams with agile tools that are difficult, confusing, and cumbersome to use?

Please don’t miss my point, I’m not indicting the tools themselves.  Tools like Jira and Azure are extremely flexible, and can be used for both good and evil, depending on their configuration.  I’ve seen organizations use these tools effectively and reap significant benefits, but all too often, these tools are implemented in a way that makes them an impediment to agility.  These tools can become so cumbersome that it can appear the enterprise is trying to kill the goose that lays the golden eggs.

These organizations usually believe that agility is critical when it comes to their offerings in the marketplace, but when it comes to deploying their internal tools, they forget every lesson that agile tries so hard to teach.  Tools are often configured by a specialized group, locked down, and rolled out to the agile teams. They are set up to standardize processes, centralize information, and provide simple reporting to management. I agree that these are worthy goals, and often necessary, but I believe we can meet these goals while enhancing the agility of our organizations instead of stifling it.

I was at one organization where this situation was particularly acute.  I was training people in scrum and agile concepts, and standing up new scrum teams.  The teams learned scrum easily enough, and began using sticky notes on a wall while they waited for access to the company’s electronic tool. The sticky notes worked very well, except for the lack of visibility for offshore team members and management located in other states.  Gaining access to the tool took almost a month, but that was only part of the delay. The tool configuration required 3 different backlogs for each team, one for creating the user stories, another for backlog refinement, and finally one the team could use for sprint planning and tracking work.  This caused a lot of confusion as the team migrated from the simplicity of sticky notes to the new tool. Navigation was also complex, and switching between the three backlogs was anything but intuitive. The tool defaulted to showing work items across all teams, requiring everyone to frequently filter and sort the items to find a story they were trying to update.

There were other complexities in this configuration, but I’m sure you get the point.  Imagine of the team in charge of this tool took an agile approach, and started with a couple of user stories like this:

As a manager, I need to be able to access sprint statistics in a uniform format across all of my scrum teams so that I can see how my teams are performing.

As a scrum team member, I need to quickly and easily update my PBIs so I can focus my time and effort on converting those PBIs to completed product increments.

Next, imagine if this configuration team took an iterative approach, demonstrating their progress to both management and scrum team users, and obtaining feedback on how the configuration helped or hindered the jobs each of these users were trying to accomplish.  Imagine that the config team then modified the configuration after each demo to better fit what the end users needed. Not only would this approach really show that we, as an organization, value individuals and interactions over processes and tools, but it could also set a very important precedent.  We might demonstrate that agility is not just for teams creating new software, but can help many types of teams to deliver better, more creative & innovative solutions. It can help these teams deliver their solutions faster, ensuring that they provide the most help possible to the areas that their customers most need it.

How are the agile tools in your organization configured, and would you say these tools enhance or hinder your overall agility?  What areas in your organization, outside of software development teams, could benefit from a more agile approach to solving problems?