In 1995 Ken Schwaber published the paper that put the first formal definition of Scrum into public view. He and Jeff Sutherland co-presented the work at a conference that year. On its second page he lists the places the approach had already been observed: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox and Hewlett-Packard (Schwaber, 1995). Copiers, cameras, cars, computers, printers, industrial products. There is not a software house among them. Schwaber named the method after the scrum in rugby, “a tight formation of forwards who bind together in specific positions”. He credited the observation to Takeuchi and Nonaka, who had studied how those firms ran new product development for the Harvard Business Review nine years earlier (Takeuchi & Nonaka, 1986).

Those are the firms the method was abstracted from. The practices now being imported into physical capability delivery to make it faster were first written down by people watching manufacturers. Those companies worked under a condition no software team has ever had to meet. When a decision turned out to be wrong, the correction was a re-cut die, a retooled line, sometimes a recall. Whatever those firms did to go faster, they did it inside that condition, because a tooled production line will not let you decide later.

In 2001, seventeen people put their names to the Manifesto for Agile Software Development (Beck et al., 2001). The title says what it was written for. The fourth of its four value statements is “Responding to change over following a plan”.

On its own ground that is good sense, and it was a correction the industry needed. Software has a property that almost nothing else has: the cost of being wrong is a build and a redeploy. Where correction is nearly free, late decisions genuinely cost less than early ones, because what you learn by building beats what you knew before you started. The frameworks that grew out of that insight are well made, and in their own medium they work.

Then the method travelled back. In February 2020 the United States Department of Defense issued an Agile Software Acquisition Guidebook that emphasised iterative development and frequent delivery. The GAO, which audits federal spending for the United States Congress, pulled together what its earlier assessments had found. As of June 2021, only six of 36 weapon programs that reported using Agile also reported delivering software to users in less than three months, against an industry recommendation of delivery as frequently as every two weeks (GAO, 2021). Those are United States programs, the figures are self-reported, and the snapshot is now five years old. Say all three of those things when you quote it.

Even with those limits, the shape of the finding is hard to argue with. Thirty of the thirty-six carried the label without reporting delivery inside three months, a threshold already far looser than the fortnightly delivery the method recommends. Reported adoption and realised cadence are different objects, and an assurance process that counts the first is measuring the label.

The reason goes back to that 1995 list. In a program that builds something physical, the loop cannot close in a fortnight, because the thing you need feedback on takes longer than that to exist. Design decisions in munitions or vehicles close against a certification basis, a supply agreement and a tooling investment. Reopening any one of them costs a year and a number with a dollar sign in front of it. The pace there comes from steel and certification, not from any shortage of discipline in the team.

What survives the journey, then, is the ceremony. A program gets sprints and burn-down charts, and with them the permission the method grants to settle design later. It does not get the condition that made the permission safe, which was cheap reversal. You end up with the appearance of tempo over the reality of deferred rework, and the reporting looks healthy the whole way, because velocity is the measure the framework taught everybody to collect.

Two recent papers help explain why. Schoemaker and Truumees (2026) argue that “strategic agility can differ greatly from operational agility and that each type can vary markedly across situations and organizational levels”. They also observe that “the lack of clear definitions of agility in the academic literature complicates attempts at general taxonomies or prescriptive guidance”. An organisation that adopts agility is therefore taking on a word with no settled meaning, and usually applying it at every level of itself at once.

The craft underneath is not being built either. A preprint studying how Scrum Masters develop in multicultural organisations reports “no overall standardized process for soft skills learning or metrics to measure progress”, with much of that development left to individual initiative (Petrescu & Petrescu, 2026). It is a preprint, built on two rounds of interviews, so take it as a pointer. It matches what I see on engagements, though. The ceremonies arrive fully specified and the capability to run them arrives as whoever was interested.

In Australia the pressure to move faster is official. Writing in The Strategist in January, Dougal Pidgeon traced minimum viable capability to the 2023 Defence Strategic Review and described it as senior officials and officers specifying “the lowest acceptable performance from the desired system”. He argued that the machinery underneath has not kept pace: “The Commonwealth Procurement Rules have not materially shifted, and Defence contracting templates remain lengthy and complex” (Pidgeon, 2026). Tempo has been set as policy, while the instruments that would make it safe are the ones we already had. At the same time the independent reporting that would show how these programs are really tracking has thinned, which I wrote about in April, after the Joint Committee of Public Accounts and Audit discontinued the Major Projects Report.

So here is the question I would put in week one of any delivery uplift, before a framework is selected. What does being wrong cost here? Not in general: on this decision, in this subsystem, this quarter. If the answer is a day and a rebuild, build the shortest loop you can afford. If the answer is eighteen months and a production run, then the discipline required is design resolution before commitment, and no quantity of sprint cadence will substitute for it. Most large programs hold both answers at once, which is the genuine design problem: the software and the operator interface can run on short loops while the structure and the supply agreements cannot. Running one method across both is how a program acquires the costs of each and the benefits of neither.

Those nine firms could not patch a camera after it shipped. A program that knows what its own mistakes cost will choose a method it can actually afford.

References