The Process Is Fine (Everything Is Late)

Do you know how hard it is to hang wardrobe doors? I do, because I once spent an entire Sunday assembling a flat-pack wardrobe. Every screw in the right hole, every cam lock turned to exactly the little arrow. The doors would not line up. One sat a centimetre proud of the other.

There was no missed step. The manual was fine. The wardrobe was fine. My bedroom floor, it turned out, dips towards the window because Victorian builders were artists and artists don’t own spirit levels. No amount of re-reading the instructions was ever going to fix that.

I think about that wardrobe every time a team tells me their process is fine.

The symptoms

And look, on paper it usually is fine. Standups happen at 9:00 sharp. The backlog is refined. Stories are three amigo’d, retros produce action items, and some of them even get done.

And yet: deadlines slip. Work crawls. Everything is “in progress” and nothing is finished. QA gets flattened every sprint like a seaside town in a disaster film, always on the last two days. And the sprint goal, that sentence someone carefully typed on planning day, gets read aloud once and is never spoken of again, like a wish.

Here’s the uncomfortable bit. If the process were the problem, changing the process would have fixed it by now. And you’ve changed it. You’ve tried shorter standups, longer refinement, different ways of estimating, a new way of working. The doors still don’t line up.

Stop re-reading the manual. Check the floor.

What is the goal, actually?

Read your sprint goal. Now look at your board. Could someone who has never met your team look at the two side by side and tell you what you’re trying to make true?

If the goal says “launch the new checkout” and the board is ten tickets with nothing to do with each other, the goal was never a goal. It was a caption on a photo of some work. And that’s worth sitting with, because a goal is really a bet. You’re wagering that this thing, finished, changes something you care about. So if the board can’t tell you whether you’re winning that bet, what is it actually for?

I won’t tell you how to write a better one, you know your product and I don’t. But at your next planning, try reading the goal out loud and then asking the room what would have to be on the board for us to know we hit it. Notice how long the silence is.

What would you measure?

This is the one I actually want to leave you with.

Most teams measure bugs. Bugs are easy. You can count them, graph them, feel productive about the graph. But ask yourself, honestly, what the bug count has ever told you about why the work is late. It was never down in the dark where the problem lives. It was over where the counting is easy.

And here’s the trap: the moment you make a number a target, it stops telling you the truth. Count closed bugs and you’ll get bugs closed and quietly reopened. Count velocity and you’ll get estimates that puff up to hit it. So I’m not going to hand you a metric, because a metric I hand you is just a target you’ll learn to game.

I’ll ask instead. What are you afraid to measure? What’s the number you suspect you wouldn’t like, the one nobody quite volunteers in the retro? Start there. That is almost always the floor your wardrobe has been standing on the whole time.

So, this week

Don’t change your process. Don’t book a workshop. Just go and answer two questions honestly.

What would have to be true for your goal to count. And what are you not measuring, because you’re a little afraid of the answer.

The doors will show you where they don’t line up. You just have to stop assuming it’s the instructions.