Turn the Shit Around!

When a project goes off the rails, most teams patch whatever is on fire and hope the next sprint goes better. It usually doesn’t. The turnaround starts when you stop covering up the mess, own it, and fix the problems underneath it with small, clear changes. (Yes, the title is my attempt at a parody of L. David Marquet’s Turn the Ship Around!)

Patches keep projects broken

Broken projects share symptoms. Dates slip, then slip again. The bug backlog grows faster than anyone can close it. Everyone is nervous about deploys. The status report says green while the people doing the work would tell you, in private, that it’s red. There’s a name for that: a watermelon project, green on the outside and red inside.

The instinct is to patch. Add a daily status meeting. Add an approval step before every deploy. Hotfix whichever bug the loudest customer reported. Put a retry around the flaky test. Add more people, which Fred Brooks warned against in The Mythical Man-Month: adding people to a late software project makes it later.

Each patch makes the project look a little better for a week. The thing that broke it is still there, and now there’s one more process to maintain.

Many of these symptoms are on the list I wrote in Ship as Fast as Possible, but Not Faster: reviews skipped to hit a deadline, tests stubbed out, on-call pages after every deploy. Plenty of broken projects got that way by trading quality for a date and then patching the consequences.

Stop covering up the mess

The first fix costs nothing and is the hardest to make: say out loud that the project is in trouble. Say it to the team, to your manager, and to whoever is waiting on the date.

Hiding it feels safer, since nobody wants to be the one who turned the status red. But a hidden problem still has to be fixed eventually, and every week it stays hidden the fix gets bigger and the conversation gets worse. People can work with a project that’s in trouble. They have a much harder time with one that was in trouble for two months while the report said green.

Owning the chaos also means owning it when you didn’t cause it. If you just inherited the project, the mess is yours now. Blaming the previous team is satisfying for about a day, and the project still doesn’t ship.

Then write down everything that’s wrong. All of it, in one place, without softening it for the audience. That list will be uncomfortable to read. It’s also the first honest plan the project has had in a while.

Find the root problems

Symptoms are what you see. Root causes are why you keep seeing them. Toyota’s five whys is a blunt tool and a good one: keep asking why until the answer is something you can change.

Take a release that keeps slipping as an example.

1. Why did the release slip? QA found serious bugs in the final week.
2. Why so late? QA only gets a build a few days before release.
3. Why? The staging environment is shared by four teams and broken half the time.
4. Why? Nobody owns it, and it’s configured by hand.

“Start QA earlier” is the patch at the top of that chain, and it won’t work, because QA still can’t get a working environment. The fix at the bottom is to give staging an owner and put its configuration in code. It’s less exciting than a war room, and it’s the only option on the table that makes the next release better.

Most broken projects trace back to a handful of root problems like that one. Find the two or three that generate most of the symptoms and start there.

Small, clear changes

Marquet’s book tells how he took command of the USS Santa Fe, a nuclear submarine, and changed how its crew made decisions. One of the changes was in how people spoke. Instead of asking permission, officers said “I intend to…” and the captain confirmed. A small change in wording moved ownership to the people closest to the work.

Fixing a project works the same way. Resist the big-bang fix, whether it’s a rewrite or a reorg. Those are patches at a larger scale, with a longer wait before anyone learns whether they worked. Make one clear change, show the result, then make the next one.

Small changes are easy to reverse when they turn out wrong. They also show progress in days. A broken project has usually spent most of its stakeholders’ trust, and a visible fix every week earns it back faster than a promise about next quarter.

Borrow the language, too. Let the engineer who found the staging problem say “I intend to put the staging config in code this week,” and then get out of the way.

Nobody turns a broken project around in one heroic week. You do it by being honest about the mess and fixing one real thing at a time, until the status report is green because the project is.