A ninety-day plan for moving to the ADLC
Not a maturity model and not a transformation programme. A week-by-week sequence that starts with measuring the gap and ends with a decision you can defend.
The question always arrives in the same shape. Someone has read enough to be convinced the problem is real, they have watched their own board drift for a quarter, and then they ask: fine, how long does this take?
The honest answer is that the technical work takes about two weeks and the rest is people. Which means the plan you need is not an implementation plan. It is a sequence for changing how one team works, proving it did not break anything, and then having a real argument about whether to do it again elsewhere.
Ninety days is the right box for that, and it is worth saying why. Thirty days is enough to install something but not enough to observe a full cycle of consequences, which means you will make the go or no-go call on vibes. A year is long enough that the sponsor changes jobs, the pilot team reorganises, and the whole thing dies of ambiguity. Ninety days is roughly six sprints. It is long enough to see a bad quarter and short enough that somebody is still accountable at the end of it.
What follows is the sequence I would actually run. It is deliberately slow at the front and boring in the middle, which is the opposite of how most tooling rollouts go, and that is the entire point.
Days 1 to 14: measure the gap before you fix anything
You cannot demonstrate improvement against a baseline you never took. This is the step teams skip, and skipping it is why so many of these efforts end with an argument nobody can win.
Take two weeks and gather four numbers. Not a dashboard, not a data warehouse project. Four numbers you can write on a sticky note.
Ticket lag. For every ticket closed in the last thirty days, the gap between the merge timestamp of the last pull request that referenced it and the timestamp of the status transition to done. Take the median and the ninetieth percentile. The median tells you the normal case. The ninetieth tells you how bad the tail is, and the tail is what makes status reports lie.
Orphan rate. The percentage of merged pull requests in the last thirty days that reference no ticket at all. This is work your system of record does not know happened. In most teams that have started using agents seriously, this number is a shock the first time it is measured.
Criteria quality. Pull fifty tickets at random from your backlog. For each one, ask a single question: could a competent stranger tell from the acceptance criteria alone whether this is finished, without asking anyone? Score it yes or no. Do not agonise. The percentage of yes answers is your starting criteria quality, and it is usually somewhere between fifteen and forty percent. Tooling can score this for you across an entire backlog, which is faster and less biased than a human sample, but the manual version is fine and the act of reading fifty tickets by hand is educational in a way a report is not.
Time spent reconciling. Ask the team, in a retro, roughly how much time per week goes into updating tickets, writing standup notes, chasing status and answering “is this done yet.” You will get an underestimate. Use it anyway. It is the number your finance-minded stakeholders will care about most.
Write those four numbers down somewhere permanent, with the date. In eleven weeks they are the only thing standing between you and a subjective argument.
Days 15 to 30: fix the definition of done on one team
Now the unglamorous part, and the part where most of the actual value lives.
Pick the team (the next article in this series is entirely about how to pick, so I will not relitigate it here) and spend two weeks improving acceptance criteria on their active and near-term work. Not the whole backlog. The stuff they will touch in the next six weeks.
The bar is not “well written.” The bar is machine-checkable: could an automated evaluation, or a reviewer who was not in the planning conversation, decide from the criteria alone whether the change satisfies them? That usually means rewriting things like “the export should work properly” into something with a subject, an action, an observable outcome and a boundary condition.
Two rules that make this go faster:
- Do not rewrite the whole backlog. Anything more than six weeks out will change before you get to it. Rewriting it is theatre.
- Do it during refinement, not as a separate project. The moment this becomes a work stream with its own tickets, it acquires a deadline, and criteria written to hit a deadline are worse than the ones you started with.
You should come out of this fortnight with the pilot team’s near-term work at a criteria quality noticeably above your baseline, and, more usefully, with the team having had a dozen arguments about what done actually means. Those arguments are the deliverable. The improved tickets are a side effect.
Days 31 to 45: shadow mode, no writes
Now you connect the ground-truth layer, and it writes nothing.
Shadow mode is the single most important de-risking move available in this transition, and it is worth being precise about what it does. The system reads your repositories and your tracker, detects everything it would normally act on, and logs each decision it would have made along with the confidence it had. It makes zero writes. No tickets move. No comments post. Nothing changes for anyone on the team.
What you get after a fortnight is a log you can audit. For every proposed action you can ask: would that have been right? And crucially you can find the errors before they cost you anything, because they never happened.
Run it for a minimum of one full sprint, ideally two. During that time, do three things:
- Review the log weekly with the pilot team’s tech lead. Not a formal review. Fifteen minutes scrolling the proposed actions asking “would we have wanted that?”
- Count the disagreements. Every case where the proposed action was wrong, write down why. You will find that most errors cluster into two or three patterns, usually around branch naming conventions, tickets that represent several changes, or work that legitimately spans repositories.
- Fix the patterns, not the instances. If half your errors come from an inconsistent branch naming convention, fixing the convention is one change that removes half your errors. Tuning around it one ticket at a time is how you end up with an unmaintainable rules file.
By the end of day 45 you should be able to state a real accuracy number for your own codebase, from your own data. Not a vendor’s number. Yours. That number is the thing that makes the rest of the ninety days a conversation about calibration rather than about faith.
Days 46 to 60: turn on the safest writes only
Now you go live, but narrowly.
The order in which you enable automation matters enormously, and the principle is simple: start with the actions where being wrong is cheap and obvious, not the ones where the time saving is biggest. There is a whole article in this series on what to automate first, but the short version of the sequence is this.
Enable, in order:
- Linking. Associating pull requests with tickets. If it is wrong, someone notices immediately and the fix is one click. Nothing downstream depends on it in a way that hurts.
- Comments and evidence. Posting the commit, branch and review evidence onto the ticket. Purely additive. The worst case is noise.
- Forward status transitions. Moving a ticket from in progress to in review, or in review to done, when ground truth says so. Reversible, visible, and the one that actually removes labour.
Do not enable anything that gates a merge in this window. Do not enable anything that closes an epic. Do not enable anything that notifies people outside the pilot team. Those come later or not at all.
Not in this window
- Anything that gates a merge
- Anything that closes an epic
- Anything notifying people outside the pilot
- A low confidence threshold
Enable in this order
- Linking: wrong is noticed instantly, fixed in one click
- Comments: additive, nothing downstream depends on them
- Threshold set higher than you think you need
- Below it, route to a human rather than act
Set the auto-apply confidence threshold high to begin with. Higher than you think you need. Anything the system is not confident about routes to a human instead of acting, and in the first fortnight of live writes you want that queue to be visibly busy, because a busy queue is evidence the threshold is doing its job. You will lower it later, on data, once you have watched what falls into the queue and confirmed most of it was genuinely ambiguous.
Days 61 to 75: widen carefully and watch the second-order effects
Two weeks of live writes without incident is not proof, but it is enough to justify widening. In this window you do one of two things, not both.
Either add repositories for the same team, or lower the threshold on the actions already enabled. Changing two variables at once means that when something goes wrong you will not know which change caused it, and you will end up reverting both, which costs you a month.
This is also the window where the interesting failures show up, and they are almost never technical. Watch for these:
The team stops reading the board. If automation makes the board correct but nobody has adjusted their habits, you have built an accurate artefact that no one consults. Fix this by killing a ritual: if the board is now trustworthy, the daily verbal status round is redundant, and removing it is how the team feels the benefit.
Someone games it. If ticket transitions are automated on merge, and somebody is measured on tickets closed, you have created an incentive to slice tickets thinner. This is not a tooling failure, it is a measurement failure that the tooling made visible faster. Deal with it as a management conversation.
Criteria quality decays. Two weeks after the criteria push ends, refinement drifts back to prose. This is the most common regression in the entire transition. The counter is to make criteria quality visible in refinement itself rather than a thing that was done once in month one.
Days 76 to 90: decide, in writing
The last two weeks are not implementation. They are the decision.
Re-measure the four numbers from days 1 to 14. Same method, same queries, same definitions. Put them beside the baseline. Then write one page, no more, that answers four questions honestly:
- What moved, and by how much?
- What did not move, and why not?
- What broke, what was the blast radius, and how long did it take to recover?
- What would we do differently on the next team?
Then make one of three calls, explicitly:
Expand. The numbers moved, the team wants to keep it, you know what you would do differently. Roll to two or three more teams, with the same sequence, not a compressed one.
Hold. Something is not right but you do not yet know what. Keep the pilot team live, do not expand, and set a date to revisit. This is a legitimate outcome and it is chronically underused, because “hold” feels like failure and organisations prefer a confident wrong answer.
Stop. The gap this addresses is not your bottleneck, or the work does not fit the model, or the cost is not justified at your agent usage. Turn it off, write down why in enough detail that whoever asks again in a year can read it, and move on. There is an entire article in this series arguing that for some teams this is the correct answer.
The reason to write it down is not process hygiene. It is that in month four somebody senior will ask “did that thing work?” and the difference between an anecdote and a page with two columns of numbers is the difference between a programme and a rumour.
Where this breaks down
I have laid this out as though ninety days is a clean box, and it is worth naming the places where that is a convenient fiction.
Two weeks of shadow mode is not enough for seasonal teams. If your team’s work has strong periodicity, a release train, a quarterly compliance cycle, a retail freeze, then a fortnight of observation samples one mode of a multi-modal system. You will calibrate against your calm weeks and then be surprised in your busy ones. If that describes you, shadow mode should span at least one full cycle of your real rhythm, even if that pushes the whole plan to five months. The sequence still holds. The calendar does not.
The baseline measurement assumes your history is readable. If the team recently migrated trackers, renamed projects, or went through a reorg, your thirty-day history may not be representative or may not exist in usable form. Taking a baseline from a corrupted period is worse than taking no baseline, because it gives you false confidence in a comparison. In that case, measure forward: spend the first two weeks collecting a clean baseline rather than mining a dirty one, and accept that the plan is now a hundred days.
The plan assumes one sponsor who lasts ninety days. In a lot of organisations, that is optimistic. If your sponsor is likely to be reorganised out of the picture, compress hard: run a four-week version with a single team, a single repository, forward status transitions only, and a much cruder baseline. It is a worse experiment and it will tell you less. It will also still exist in week five, which the better experiment might not.
And it assumes the gap is worth closing at all. Everything above is machinery for closing the distance between what a team has done and what its record believes. If agents are writing a small fraction of your changes and your board is broadly accurate, the ninety days will produce a small, real, unexciting improvement, and you will have spent a quarter of organisational attention on it. Attention is the scarce resource. Spend it where the gap is widest.
The takeaway
The technical work in this transition is small. The sequencing is what matters, and the sequence is: measure the gap, fix the definition of done, observe without writing, enable the cheapest writes first, change one variable at a time, then decide in writing against the baseline you took in week one.
Everything that goes wrong in these rollouts goes wrong because someone inverted that order. They automated before the criteria were checkable, or they went live before they had shadow data, or they expanded before they had a number. Order is the whole discipline.
The next piece in this series is about the first real decision inside this plan: why running a pilot in shadow mode, writing nothing at all for a full cycle, is worth the fortnight it appears to cost.