What tools to use when (re)starting your Agile transformation ?
Tl;dr: I'll be fit because I downloaded the same fitness app that fitness world champion endorses ;)
Tl;dr 2: Use the simplest and most flexible thing which could possibly work: aka whiteboard, Excel and whatever requirement management tool you are using at the moment.
The long version ....
When starting an organizational transformation, it's soooo tempting to focus on processes and tools. I mean, those things are easy and familiar compared to having to deal with the "annoying things called people" (Bas Vodde). Especially with all those tools sales guys telling you that just buy this tool that BigCorp also uses ... and this will make you TrullyAgile(tm). /s
Well, picking a tool early in the transformation is a BIG mistake.
But Paul, you don't understand! Our organization is very complex, and we want this Agile thing now because it promises HUGE efficiency improvements and everybody else is doing it anyway. We need a tool to manage our complexity *!
Yeah, been there, done that; And nope, you are probably wrong. And here's why!
Reason 1: As every good ERP consultant will tell you, you either follow the workflow defined by the tool (hello SAP) or you spend a small fortune customizing it.
In other words, by selecting a tool early in the process you will limit yourself to what the tool supports. And even an almost endlessly customizable tool like Jira will limit you and lock you in! You'll also spend a huge amount of time trying to manage your un-Agile organization reporting structures to fit into the tool's workflow or customize the Agile tool to fit your un-Agile organization.
Hint: the problem is your un-Agile organization, not a tool or process.
Reason 2: Once a tool and workflow are selected I can guarantee that the workflow will almost never change because muh historical data! (this is valid for both Product Backlog and Sprint Backlogs).
Congrats, you just made a very important decision at a point in time where that organization had very little experience **.
This is problematic for both organizations and teams. For organizations, if you start with a messy organization then add a tool to manage that, will end up with an "automated mess" (LeSS book), Conway's law ftw!
At team level you'll want the people to experiment with what's the best format for them which is kind of impossible if there is a "mandatory sprint backlog tool", selected because someone somewhere might want to look at what the individual team members are doing.
Btw, Scrum is micro-manager’s dream come true with the amount of transparency it provides.
What do instead ?
For Sprint Backlog: let the teams use whatever they want and use active coaching to make them realize when things are not yet visible enough!
For Product Backlog: use a whiteboard or Excel (no scripts allowed) on top of whatever masochistic requirement management tool you are currently using*** ; if your organization is too complex and can't be handled with Excel that is a BIG sign that you have to start simplifying your organization!
And yes, descaling your organization is the thing which might make your organization Agile and not buying some expensive tool.
In conclusion: simplify your organization first, introduce a tool if you really have to later.
* Anecdotical I've seen a product organization (~400 people) who started with Excel but ended up with 100+ columns so they decided to create their own inhouse tool to manage the mess.
** This is also one of the reasons why tool salespeople can be very pushy - they know that once their tool is selected they will have a lock down and almost eternal license fees.
*** I had the "luck" of having to work with both Doors and FocalPoint