I love Trello because there are very few ways you can screw it up. You simply don’t use Trello for the “more complicated” workflows because it fails miserably (thank god). It’s simple, fast, no frills, and helps you focus on collaborating with other people and getting work done. And that’s OK. I’m very happy that Atlassian — a company I respect and admire — has purchased Trello.

But John, Jira sucks! Maybe the Trello pixie dust will rub off on Jira… I think that is a vast oversimplification, and shows very little sympathy to the challenges faced by Atlassian (and the advantages the Trello team enjoyed)

. The problem isn’t Jira.

The problem is that we inevitably come to hate every issue tracking product we use. We hate them because we (the users) overload/customize them with the best of intentions, and then our needs change. And finally because businesses see these tools as some sort of necessary evil: a management tool instead of a catalyst to drive better customer outcomes and inspire continuous improvement. If front-line teams could link their use of said tools to better individual and customer outcomes, they’d like them.

Great case in point. My friend proclaimed “I hate Trello!” Turns out he started working at a company that had butchered it beyond recognition to “manage” an incredibly bloated process. It only takes one bout of food poisoning. And…we tend to graft team dysfunction on the tools we use. If we’re always frustrated when using Jira, we’ll associate it with Jira! A tangled process implemented in Jira remains tangled.

Discouraging Continuous Improvement

Tools tend to force premature convergence on a process, and then make it ridiculously inconvenient to change that process. The tool is running the team, and not the other way around. Teams should be encouraged to continuously improve on the way they work. Are two week sprints too long, or too short? Can we clarify our working agreements? Is the team driving a new value stream? Do we need to shift things around to address a bottleneck? Should we flag items for pairing? Mob? Add a new layer to the ticket hierarchy? Teams should be able to adapt accordingly.

Customized Into Oblivion

To complicate the issue, the more you try to customize tools to make everyone happy (and to make the job they have right now easier), the more bloated and inflexible the user experience becomes. That magic executive-level dashboard is now a reality, but at the expense of letting teams reflect and adapt on how they work (and likely burdening them with non-customer facing administrative work, aka the dreaded “update your tickets, everyone!”).

What you see in many cases is that the business is still in a waterfall mindset, and that a good bit of our tool customization is centered around that translation layer.

Benefits

You’ve gotta ask … how is the team actually benefiting from using the product? Is the tool helping them deliver more value to their customers? When I ask this, I’ll often hear about benefits like tracking, accountability, visibility, estimation, managing dependencies, status checks, notifications, executive roll-ups, and reporting. I hear very little about improved collaboration, better insights, improved quality, more effective retrospectives, and increased team motivation / sense of ownership / clarity of mission. I almost never hear about improved end-customer outcomes.

Ask an engineer or UXD “what tools help you build better more usable software” and they’ll have an answer. It won’t be the ticketing/workflow product.

Hmmmm

Anyway. That is what’s on my mind today. Are the tools running the team, and not the other way around? Is your tooling delivering better outcomes to your customers, or just making everyone feel better internally? Do all of those layers of customization really add value?

Also, do we always fail when trying to to mix workflow, continuous improvement efforts, and collaboration on tickets in a single tool? I always advise teams to work with a physical board to reflect on and tweak how they work. And THEN pick a tool. Instead, teams figure they’ll “do Agile”, figure everyone does Scrum to the book, and buy a tool to enforce said process. It rarely ends well.