Can using the wrong tool to track your work and help you communicate derail your Agile transformation? Based on my experience helping more than 60 organizations adopt Agile, I’d say yes.
Choosing the wrong tool is never the only issue that leads Agile transformations astray. But it is – or should be – an easy choice, and failure to make the right choice is often symptomatic of other underlying issues. Here are some of the mistakes that I see people make and what I recommend.
Mistake 1: Using the tool you've always used
A number of teams I’ve worked with have tried to use the tool that they have been using for years in non-Agile work. They justify this by saying something like, “Agile is going to introduce a lot of change. We shouldn’t add to the amount of change by also changing tools.”
On the surface, this sounds like a reasonable argument. But it often masks a lack of commitment to change.
[ Need to explain key Agile and DevOps terms to others? Get our cheat sheet: DevOps Glossary. ]
New tools encourage new habits. They encourage new ways of communicating and reinforcing the methodologies, practices, and values of Agile. Don’t put new wine in old bottles.
Mistake 2: Using a tool that wasn't designed for agile
Agile is popular. Tool vendors are well aware of this, and many tools that have been around for decades have added Agile to their marketing copy or tacked features onto systems that were designed to be ticket-based.
With ticket-based systems, IT organizations open a trouble ticket whenever a user reports a problem. They have also been used by software development teams to document new feature requests and to track bugs. You open and close a ticket.
Ticket-based systems introduce a check-the-box mentality: Should I open a ticket? Let’s not, because we’re not likely to close it anytime soon and we want to keep our close ratio high. Should I close a ticket? Let’s close it now to keep that close ratio high, even though we’re not sure that we’ve really met the user’s need or fixed their problem.
Ticket-based systems are not inherently visualization tools. Sure, many of them use status fields to create Kanban-like views of the tickets, but these views always have limitations. I’ll explain the importance of visualization below.
Mistake 3: Using a tool designed for software development (if you're not a developer)
I work primarily with marketing, financial operations, and IT operations teams, not software development. Sometimes these teams are asked to (or choose to) use the same tool that the software development team uses. The thinking goes, “We already have a license for one Agile tool, why shouldn’t marketing use the same one?” or “Using the same tool will increase communication between marketing and software development.”
This is almost always a mistake. Software developers have different needs than marketers, finance, or IT operations. They use a different language, and they usually have a different level of technical skill. Different teams need different tools.
Improving communication between these groups and software developers happens through means other than tools. Other departments and software developers do not share backlogs. They don’t share user stories. These other departments should learn to read the information contained in the tools used by software developers. They may suggest new features or comment on user stories, but they should not by default use the same tool as software developers.
My recommendation: Let's talk Kanban boards
Choose a tool that was designed from the ground up as an Agile tool. That usually means an electronic Kanban board.
Kanban boards are visual. The human brain processes images 60,000 times faster than text: 80 percent of people remember what they see. In comparison, 10 percent remember what they hear, and 20 percent what they read.
Visualization allows teams to see at a glance where a deliverable is in a process, compared to reading a status on a spreadsheet or within a ticket-based tool. Visual indicators can indicate blocked items, due dates, high-priority items, and the relationships between tasks.
Techniques like Portfolio Kanban allow teams to see the relationship between their work and larger projects, programs, and organization-wide strategies. They also allow management to visualize progress on big-picture programs or strategies.
Which electronic Kanban tool should you use? There’s no single best answer. Each has its own strengths and capabilities. Determine what’s important to you and choose a tool to meet your unique needs.
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
