Delivery Diagnosis
For when software is late and nobody can say why. We find the real blocker and give you a plan you can run without us.
The work is being done. It isn't getting out
The pattern is familiar enough to be its own diagnosis. Everybody is busy, features keep being described as nearly finished, and the release that was going to catch things up has moved twice. Nobody is lying and nobody is idle. Something between finishing work and shipping it is not working, and from inside the team it is genuinely hard to see.
We come in from outside and look at the codebase, the pipeline, the last few releases and the calendar, then talk to people one at a time - the honest account of what is blocking a team is rarely the one given in a group. It takes one to three weeks, because the aim is to watch a real cycle rather than to hear about one.
What comes back names the blocker plainly and says what it is costing. It is almost never the people. It is usually a process asking humans to hold something a pipeline should be holding, a test suite nobody trusts, or a decision that has been waiting six weeks for an owner nobody named.
One of our four consultancy limbs. The others are architecture, software delivery and business analysis.
Four ways we get brought in
Most of this work starts as one of these. You don't need to know which before you talk to us.
Delivery review
One to three weeks, one written answer: what is blocking delivery and what it is costing.
Codebase and process assessment
We read it, run it, and separate what is genuinely hard to change from what is merely unfamiliar.
Recovery plan
An ordered plan, with the first change small enough to prove the rest of it.
Interim delivery support
Somebody alongside the team while the changes bed in, working inside it rather than reporting on it.
Where the blocker usually is
- Between finished and shipped
- The most common answer by a distance. Work completes and then queues - for an environment, an approval, a manual test pass, or a release window that keeps moving.
- A suite nobody trusts
- When a red build is normal, the tests have stopped being information. Everything after that gets checked by a person, and the schedule quietly absorbs it.
- A decision with no owner
- Work that has been "nearly done" for a month is often waiting on a choice nobody realised was theirs. Naming the owner sometimes fixes more than any process change.
- Branches that live too long
- Every extra week a branch stays open adds merge work nobody estimated. Teams in this position feel slow while working hard, because most of the effort is going into reconciliation.
What lands on your desk
- The blocker, named
- In one page, in language you can take to a board, with what it is costing you now.
- An ordered plan
- First change first, sized so the first one proves the rest.
- Who could run it
- Including your own team, because a plan that only works if you hire us is not a diagnosis.
What it looks like when it works
In both of these the visible number was not the problem. Diagnosis is the work of finding what was actually stopping the release, which in neither case was the thing being complained about.
| Item | Result | Notes |
|---|---|---|
| Releases in six months | 5 | at a rail technology supplier that had gone months without one - the work was finished, none of it was getting out |
| Releases rolled back | 45% | at a UK high-street retailer, where the number was the symptom and the cause was somewhere else |
| Deployment success | 95% | after feature gating at merge time and one shared release process |
Common questions
How long does a diagnosis take?
Usually one to three weeks, depending on the size of the team and how much of the history is written down anywhere. Long enough to watch a real cycle rather than only hear about one; short enough that it is not itself another project.
Are you going to tell us it's the team?
Almost never, and we are suspicious of anyone who reaches for that first. Capable people produce late software when the process asks them to hold too much in their heads, when the tests do not tell them whether they broke anything, or when nobody can approve a decision. Those are all fixable and none of them are about who you hired.
Do we have to hire you to fix what you find?
No, and the plan is written so you don't have to. It says what to do in what order and who could do it, including your own team. If you would rather we helped, we can, but that is a separate conversation from this one.
What do you actually look at?
The codebase, the pipeline, the last few releases, the board or backlog, and the calendar. Then we talk to people individually, because the honest version of what is blocking a team is rarely said in a group.
We already know what's wrong. We just can't get it fixed.
Then the useful thing may be an outside voice saying it plainly to whoever can act. We write for that audience: what it is costing, what to change, and what happens if nothing does.