← The ADLC library
Delivery & program intelligence
A desk of the Fastpace GroundTruth library
What the numbers do when agents arrive.
Measurement under the ADLC: why the four keys drift out of meaning when code production stops being the constraint, what to read instead, and how a transition actually sequences inside an organisation that already has a backlog and a release calendar.
Metrics & DORATransition playbookFailure modes 48 articles
Articles
- Managers stopped being a bottleneck and became a constraint A bottleneck is a queue you can staff your way out of. A constraint is the thing that sets the safe rate of the whole system. Managers moved from one to the other, and most organisations are still applying the old fix.
- Your org chart assumed a conversion rate that no longer holds Staffing ratios are a model with hidden assumptions: how many juniors become seniors, and how long it takes. Both inputs moved, the shape did not, and the first place you will notice is a mid-level band you cannot hire into.
- The staff engineer who writes rules, not code The shift from writing implementations to writing constraints is real and mostly correct. It is also invisible to every measurement system your organisation runs, which is how good versions of this role quietly starve and bad versions quietly proliferate.
- On-call for code nobody read Your time to restore will look fine while your incidents get structurally worse, because the median hides what is happening in the tail. Putting someone on a rota for a system nobody has read is a staffing decision, not a documentation problem.
- Small teams, big blast radius A six-person team now ships at a volume that used to require sixty people, and it is doing it with none of the coordination machinery sixty people were forced to build. The risk profile changed. The controls did not.
- Against the ten-x claim, in all its forms A tenfold productivity claim never names its denominator, which is what makes it unfalsifiable and useful to the person making it. The measurable truth is stranger: one stage collapsed and another got dramatically slower.
- The interview should measure reading The build exercise tests the one thing candidates no longer do alone. Replace it with a reading exercise: a real change, a real spec, and a decision to merge or not, defended out loud.
- Seniority is now a verification skill Most engineering ladders still promote on evidence of production, which is the one input that stopped being scarce. The senior work now is deciding what is true about a change nobody wrote by hand.
- What to hire for when everyone ships fast Shipping speed has stopped being a differentiator between engineers because it stopped being scarce. The job description that still leads with it is selecting for the one input that got cheap.
- Entry-level postings fell 40%. That is a choice, not a trend. The drop gets reported the way weather gets reported, as something that happened to the industry. It is the sum of decisions taken by named people using a cost model that was wrong before agents arrived.
- Deriving status from source control instead of maintaining it in Asana A practical route to keeping Asana in step with what engineering is actually doing, starting with the identifier problem that makes Asana harder to automate than a developer tracker.
- Deriving status from source control instead of maintaining it in Bitbucket How to turn branch, pull request and deployment events in Bitbucket into a status your board can trust, and how to tell when the derivation has quietly stopped covering most of your work.
- How to present ADLC metrics to a board A board does not want your deployment frequency. It wants to know whether the money is working, what happens if it is not, and how fast you would find out.
- How to measure your Asana linking rate A repeatable way to find out what share of your merged code traces back to an Asana task, why the number is harder to get in Asana than in a ticket-key tracker, and what to do with the answer.
- Finding the work Azure DevOps never recorded Azure DevOps has the strongest native lever of any tracker for preventing untracked work, and most teams have it switched off. Here is how to find what already slipped through, and how to stop the next lot.
- Finding the work GitHub never recorded GitHub is a better witness than most teams give it credit for. The gaps are narrow and specific: work that bypassed the pull request, work in repositories nobody inventoried, and evidence that expired. Here is how to find all three.
- Instrumentation-free measurement: reading the repo instead Most metrics programmes fail because they ask people to produce new data. The repository already contains almost everything, and it has the one property self-reported data never has.
- How to measure your Jira linking rate A repeatable way to work out what share of your merged code actually connects to a Jira issue, including the key-matching traps that make the first number you get wrong.
- Finding the work Jira never recorded Orphan work is invisible to JQL by definition, because there is no issue to query. Here is how to find it from the code side, classify it properly, and fix the causes rather than the symptom.
- Measuring drift, and why it predicts slippage The gap between what your board says and what your repository shows is measurable, cheap to compute, and moves before your delivery dates do.
- The rollback plan you should have before you start Not a disaster recovery document. A written answer to what you switch off, in what order, and what state you are left in, produced before anything is switched on.
- Over-automation: when write-back makes things worse A board that updates itself is better than a board nobody updates. Except when it is not, and the failure mode of an automated record is meaningfully nastier than the one it replaced.
- Convincing a skeptical VP of Engineering Their skepticism is usually well founded, and the way through it is to argue a smaller case than you want to argue, with numbers from their own organisation.
- Definition-of-done adherence as a first-class metric For fifty years the definition of done was a document nobody read. It is now the interface an agent builds against, which makes adherence to it something you can and should measure per change.
- The junior pipeline broke and nobody owns fixing it Entry-level postings are down around 40%. The work juniors learned on is the work that automated first. Every organisation is quietly assuming someone else will train the next generation of seniors.
- Rework rate: the missing fifth key Every one of the four keys treats a change that undoes a previous change as progress. Under the ADLC that is the single most expensive blind spot in the set.
- Cross-team dependencies nobody declared The dependency was real, mutual, and invisible. Both teams found out about it in the same week, from the same incident, four days before a launch.
- Getting developer buy-in without a mandate Engineers have watched a decade of tooling arrive as surveillance wearing a productivity badge. Their suspicion is earned, and the way through it is not a better presentation.
- Why elite DORA scores can hide a rotting board All four keys can be green while your system of record has become fiction. The metrics measure the flow of changes. Nothing in them measures whether anyone still knows what is true.
- Agents optimizing to the letter of the criteria You finally wrote acceptance criteria precise enough to check. Every one of them passed. The feature still did not work, and the criteria are now the reason nobody noticed.
- The orphan pull request problem A third of the changes going into production have no ticket attached. That is not a hygiene issue. It is a hole in every number your organisation reports about itself.
- The metrics DORA does not capture in the ADLC The four keys were designed for a world where writing code was the constraint. Here is what stopped being measured when that stopped being true, and which absences are worth filling.
- What to automate first, and what to leave alone Rank candidate automations by the cost of being wrong, not by the time they save. The ordering that produces is unintuitive and it is the one that survives.
- When your board becomes fiction, in weeks not quarters Boards have always drifted from reality. What changed is the rate. A board that used to take a quarter to become misleading now manages it in about eleven days.
- Brownfield first, and why greenfield advice misleads Almost every account of agentic development you will read describes a new codebase with no history. Your codebase has history, and that changes which advice applies.
- Sequencing, criteria before automation, always Automating a process whose definition of done is vague does not fix the vagueness. It industrialises it, and gives it an audit trail that makes it look deliberate.
- Review fatigue and rubber-stamping at volume Nobody decides to stop reviewing properly. It happens gradually, it is a rational response to an impossible queue, and the metrics get better the whole way down.
- Time to restore in an agent-heavy codebase The most robust of the four keys hides a phase that agentic development makes much harder. Restoring service is unchanged. Working out what to restore is not.
- Change failure rate is the one to watch Three of the four keys get flattered by agentic development. Change failure rate is the one that can still tell you something is wrong, provided you stop reading it as a rate.
- The confidently wrong pull request It had a clear summary, a passing test suite, and a rationale for every decision. It was also wrong in a way that took eight days and a production incident to find.
- Lead time for changes: the metric agents distort most Lead time was always a measurement of queueing. Agents collapse the part of the queue we measure and leave the part we do not, which makes the number improve while nothing gets faster.
- Pick one team, not the whole org The selection criteria that actually predict whether a pilot survives contact, and why the most enthusiastic team is usually the wrong one to start with.
- Silent scope drift in agent-authored work The ticket was a two-line config change. The merged diff touched nineteen files, and every one of those changes was individually justified. That is what makes it hard to catch.
- Start in shadow mode, proving before writing Run the automation for a full cycle with every write turned off. The fortnight it appears to cost is the cheapest insurance available in this entire transition.
- Deployment frequency when merges outpace decisions The oldest of the four keys was a proxy for removed friction. Under the ADLC it becomes a proxy for something else entirely, and the difference matters more than the number.
- What happens to DORA when you move to the ADLC The four keys still measure something real. They just stop measuring the thing you built them to measure, and the change is quiet enough that most teams miss it for a quarter.
- 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.
- Speed without a definition of done gets you to the wrong place faster The ticket said "improve the search experience." Nine days and eleven pull requests later, the team had shipped something nobody wanted. Nothing had gone wrong, exactly.
The other desks
Engineering leadershipWhat happens to the people when the code writes itself. Governance, security & complianceThe questions an auditor will ask, before they ask them. Product & acceptance criteriaDone, defined precisely enough that a machine can check it. Platform economics & toolingWhat this actually costs, and what it is worth.