Most agile transformations stop at the stand-up

Read the twelve principles behind the agile manifesto and notice what is missing. There is no stand-up. No sprint, no story point, no backlog refinement, no scrum master, no board with three columns, no estimate in any unit. The word ceremony does not appear. The closest thing to a prescribed practice is the twelfth principle, which asks a team at regular intervals to reflect on how to become more effective and then tune its behaviour accordingly, and it names no format for doing so.

What the principles do ask for is a set of conditions that have almost nothing to do with how a development team organises its calendar and almost everything to do with how the surrounding organisation behaves.

Welcome changing requirements, even late in development. Business people and developers must work together daily throughout the project. Sponsors, developers and users should be able to maintain a constant pace indefinitely. Deliver working software frequently, from a couple of weeks to a couple of months. The best architectures, requirements and designs emerge from self-organising teams.

Every one of those is a claim on somebody outside the development team. The first requires a governance regime that will accept a change of direction in month nine without a change control board treating it as a failure. The second requires an operational manager to release a knowledgeable person from their day job, permanently. The third requires a portfolio director to stop treating a release date as a fixed commitment made a year earlier. The fifth requires a head of architecture to allow decisions to be taken by people who do not report to them.

None of those things can be arranged by a team. All of them can be blocked by a single senior person who was not consulted. Which is exactly why agile adoptions stop where they stop.

The stand-up is the only part that requires nobody’s permission

A team can start holding a daily meeting on Monday. It can put cards on a wall the same afternoon. It can adopt two-week iterations without asking anyone, rename its documents, and appoint one of its own as scrum master, all without a single conversation outside the room.

It cannot change the contract under which half its members are employed. It cannot alter the assurance regime that gates its funding, or the approvals process that requires a signed design before build. So the parts of agile that are free get adopted immediately and universally, and the parts that cost an organisation something get adopted slowly, partially or never.

The result is the most common configuration in British enterprises and public bodies alike. Iterative practice on the inside of the team, sequential control on the outside of it, and a quarterly steering group asking why velocity has not improved. The team is doing agile. The organisation is not, and the organisation is where the delivery time actually goes.

Britain has a documented example of this exact failure

The Department for Work and Pensions attempted precisely this on Universal Credit, and the National Audit Office wrote down what happened in a report published on 5 September 2013.

The department, the report records, tried to use an agile approach to develop processes and systems at the same time as defining policy requirements. This was the first time it had tried the approach on a programme of that scale. And then the sentence that anybody running a transformation should have tattooed somewhere visible: the department experienced problems incorporating the agile approach into existing contracts, governance and assurance structures.

Contracts, governance and assurance. Not tooling, not capability, not developer skill. In January 2012 the response was Agile 2.0, described as a hybrid approach which tried to combine elements of agile and traditional approaches to IT programme management.

That is what stopping at the stand-up looks like at national scale. The delivery method was changed and the three structures that decide what a delivery method is permitted to do were left alone, so a reconciliation layer had to be invented to sit between them. Every large organisation that has run a transformation for more than two years has its own Agile 2.0, usually with a friendlier name.

The report is equally clear that the underlying problem was not the method. Throughout the programme the department lacked a detailed view of how Universal Credit was meant to work, and had been warned repeatedly about the absence of a blueprint, architecture or target operating model. Iterating quickly is of no help when nobody has agreed what the thing is. Agile assumes a product decision exists and that it can be revised. It does not substitute for one having been made.

Four questions that are answerable

Maturity models invite an organisation to score itself against practices, which is why they always return a flattering answer. These four require evidence and produce an uncomfortable one.

What happened the last time a requirement changed after the design was signed off? If the honest answer involves a change control board, a re-baselined plan and a paper explaining the variance, the second principle is not in force whatever the wall charts say.

Who is the business person the team speaks to daily, and what else is that person accountable for? If nobody can be named, or the named person attends a fortnightly review instead, the fourth principle is aspirational.

When did the team last release something to real users, and what did it have to obtain permission for? The gap between a team’s iteration length and its actual release interval is the single most diagnostic number available, and it is usually explained entirely by approvals rather than by engineering.

What has the pace been over the last four releases? Sustainable indefinitely is a testable claim. A team that crunched before three of the last four dates is not working in an agile way, it is working in a sequential way with shorter phases.

Method is the wrong argument to be having

Government’s own guidance is unbothered about which framework a team uses. It observes that there are many agile methods, that each has its own tools and techniques, and that you do not have to work with just one method. The Service Standard asks teams to use agile ways of working and to iterate and improve frequently, and it puts those alongside requirements to understand users, to solve a whole problem, and to publish performance data. Those are outcomes, and outcomes are assessable by somebody outside the team.

Which points at the useful reframing. The question is not whether an organisation is agile, because that word now describes so many arrangements that the answer carries no information. The question is whether it can change its mind about a product in month nine without anyone being punished for it, and then ship the changed thing to users inside a fortnight.

Most cannot. That is a fact about their contracts, their funding cycles and their assurance regimes, and it will still be true after the next round of certifications. What a delivery function can realistically do about it is set out in the delivery manager’s real week, and the programme-level version of the same failure is covered under digital transformation. This desk’s coverage of how software gets specified and bought sits at SaaS and enterprise software.