Some years ago, I inherited a way of tracking a coarse-grained backlog. It ran across three separate places, and there was a method for keeping the pieces lined up with each other. The system wasn’t documented, but it hung together, barely. I don’t love inheriting things, especially fiddly ones.
Eventually we dropped the fiddly part. It was an easy change-over and the backlog functioned. I would 100% do the same thing again.
On the downside, the backlog has grown steadily. There are many items now and the links between them are looser than they were.
The part I removed was doing two jobs, and only one of them was obvious.
What the fiddly part was doing
The team could see the three places and the effort of keeping them all lined up.
The effort was also the point. Keeping the pieces aligned cost enough that we were careful about what we added. The number of big items stayed small because adding one was a lot of work.
That was a limiter, and it was doing a job. We didn’t notice it or talk about it until it was gone.
An absence of failure doesn’t mean success
Nothing fell apart with the changeover. The team picked up the new backlog practice easily. We didn’t lose any work, and the fiddly step stopped eating our time. Good outcomes.
A mechanism can do more than one job, though. Removing it can have the obvious desired outcome and a hidden effect. In this case, the hidden effect was the limiter on the expanse of the backlog. This limiter slowly gave way and we only noticed much later.
Six months without a limiter is indistinguishable from six months with a working one.
Six months without a limiter is indistinguishable from six months with a working one. The difference is the size of what accumulated.
The symptom looked like something else
By the time the hidden effect became visible, it did not track back to the migration. It looked like a prioritization problem.
The backlog got large and diffuse. We had more conversations about priorities. Which items matter, how to rank them, whether the list needs a cleanup. Those are reasonable conversations, given the backlog, but they were about the wrong thing.
The list got long because the thing keeping it short was gone, and nobody in those conversations connected the two. Why would they. One is a tooling change adopted years earlier and the other is a meeting about ranking today’s backlog.
What to write down before you take something out
When a mechanism is a candidate for removal, ask the questions about how it works and who depends on it. Standard questions with straightforward answers.
Here’s a question that isn’t obvious. What is this mechanism doing that nobody mentions? Ask whoever has operated the thing longest, because the answer might only exist in them and not in the system.
Write the full answer to what the mechanism does next to the decision. Not a specification of the mechanism, which the migration makes obsolete anyway. One or two sentences on what the old thing was causing or preventing.
Say what you would watch for if the mechanism disappeared. If the honest answer is that the fiddliness was keeping a number down, write the number down before the change and look at it in six months.
Recording these two answers is pretty quick and gives you something to come back to later to validate your decision.
A mechanism annoying enough to remove has usually been complained about for a while.
What is working has to be written down, because once it is gone there is nothing left to remind you.
If something on your team has been getting worse slowly and no single change explains it, the diagnostic takes about 10 minutes and shows you where your work stopped keeping its own record: https://amykennedyleadership.com/choose-your-diagnostic/