W-Agile: The Ceremony Without the Authority

Royce published the diagram and the warning in the same paper

In August 1970, Winston W. Royce presented a paper at IEEE WESCON titled “Managing the Development of Large Software Systems.” Early in it he draws the picture everyone now knows: requirements, then analysis, then program design, then coding, then testing, then operations, each phase completing before the next begins. It is the second figure in the paper. Immediately after presenting it, Royce writes that he believes in the concept, and that the implementation described is risky and invites failure.

His objection is specific rather than general. The single-pass model assumes the testing phase, which occurs at the end and consumes the schedule reserve, will confirm what the earlier phases assumed. Royce points out that testing is precisely where the assumptions get tested, so the model concentrates all discovery at the moment when there is no schedule left to respond to it. The remainder of the paper is his correction: design the program before the requirements are frozen, document the design, build the thing twice, plan and monitor the testing rather than treating it as a phase, and involve the customer in a formal and continuing way. His final diagram carries feedback between phases, not one pass through them.

Royce never used the word waterfall. The term appears in the literature later, and Bell and Thayer used it in 1976 in a paper that cites him. What propagated from his work was Figure 2 without the nine pages that follow it. Larman and Basili, tracing the history of iterative development, document how thoroughly the corrections were lost in transmission, and the sequential reading was then written into procurement standards where it acquired the force of policy.

It is worth being accurate about what he did and did not argue, because the popular retelling overcorrects. Royce was not an agilist writing thirty years early. He did not propose abandoning sequence, phases or documents; he proposed a refined sequential process with iteration inside it and a customer who stays involved. The myth that he denounced the waterfall is about as wrong as the practice he was denouncing. What he identified, and what did not survive the journey into standards, is that a process which defers all learning to the end has no mechanism for acting on what it learns.

Agile was a set of principles, not a framework

In February 2001, seventeen practitioners met at Snowbird and published the Manifesto for Agile Software Development: four value statements and twelve principles. Read it as a governance document rather than a methodology and what it actually specifies becomes obvious. It names no meeting, no role, no artifact, no estimation unit and no cadence. It says business people and developers must work together daily. It says the best architectures, requirements and designs emerge from self-organizing teams. It says the team reflects at regular intervals and then tunes and adjusts its own behavior.

Every one of those is a statement about who decides. The manifesto is not primarily a claim about how software should be built. It is a claim about where the authority to change the plan should sit, and its answer is: with the people holding the information, continuously, rather than with a body that convenes on a schedule.

Scrum arrived before the manifesto and outlived it in adoption. Ken Schwaber described the process publicly in 1995, drawing on Takeuchi and Nonaka's 1986 study of product teams that worked as a unit passing the ball rather than as a relay of specialists. What Scrum supplies is structure: a fixed cadence, a demonstration at the end of each increment, a retrospective, a single ordered backlog and a named owner of it. Set that beside Royce's corrected model and the resemblance is not subtle. Build it twice. Involve the customer formally and continuously. Put feedback between the phases rather than after all of them. Scrum is, in significant part, the operational form of the paper's second half.

Royce supplied the loop. Agile supplied the authority to act on what the loop returns. W-Agile takes the first and leaves the second, which is why it produces the meetings without the outcome.

The anatomy: water, scrum, fall

W-Agile, which Dave West described in 2011 as water-scrum-fall after looking at what most organizations were really running, is not a compromise between two methods. It is three segments bolted together, and the name is unusually honest about the shape. Water at the front, scrum in the middle, fall at the end. Each segment is internally coherent. The damage is done at the joints.

Set the three side by side and the failure is visible as a shape rather than as a list of complaints.

Authority sits at both ends and is absent in the middle. Knowledge is concentrated in the middle and absent at both ends. W-Agile is the arrangement that puts them in inverse distribution, and every one of its failures follows from that single fact.

Described that way it still sounds pragmatic, and that is why it spreads. Every individual decision producing it is defensible. Finance needs an annual number. Procurement needs a scope to contract against. Audit needs a documented approval. Operations needs a controlled release. Meanwhile the delivery organization wants the responsiveness it has read about, and adopting the middle segment is the only part it can adopt unilaterally. Nobody chooses W-Agile. It is the residue left after each function protects its own legitimate requirement, which is exactly why it appears in organizations that never decided to adopt it and cannot name who did.

Why it fails, in ten specific ways

The failures are not adoption problems and cannot be fixed by running the ceremonies better. Each one follows directly from separating the loop from the authority.

1. The loop reports to a body that cannot act. A review that discovers the requirement was wrong produces a finding, and the finding enters a change process with its own cadence. The organization's real response time is set by the slowest authority in the chain, never by the fastest feedback. Shortening the sprint from four weeks to two changes nothing when the change board meets monthly. Teams experience this as running faster into the same wall.
2. Integration is deferred to the fall, so the demonstration is not the truth. The increment shown at the end of a sprint runs in isolation. The integration, the hardening, the performance work and the contact with real data all live in the release segment downstream. So the middle segment reports done on something that has not met the system it has to live in, and the discovery that was supposed to be distributed across the sprints arrives in one lump at the end, in the phase with no schedule reserve. That is precisely the failure Royce identified in 1970. W-Agile does not fix it; it holds sprint reviews in front of it.
3. The sprint becomes a mini-waterfall. Analysis on Monday, design Tuesday, build Wednesday and Thursday, test Friday afternoon if there is time. The phase structure has not been removed; it has been compressed into two weeks and repeated. Testing is still last, still the thing squeezed when the estimate was optimistic, and now it is squeezed twenty-six times a year instead of once. This is the clearest tell available that an organization changed its method and not its thinking, and it is diagnosable in one question: inside a sprint, does anyone test on day two?
4. The feedback trap: a loop that reports and cannot act teaches people to stop reporting. The first time a review surfaces a real problem, the team raises it. The second time, having watched the first one enter a queue, they raise it with less energy. By the fourth or fifth, the review has quietly become a status meeting, because the people in it have correctly learned that surfacing a problem costs them effort and changes nothing. The ceremony survives in perfect health. The function it existed to perform is gone, and nothing in any report will show the moment it left.
5. Forecasts are harvested upward as commitments. A sprint forecast is an instrument the team uses to manage itself. Reported into a governance structure that treats it as a date promise, it stops being an instrument: the team learns that an honest low number is punished and a padded number is safe. The measurement is destroyed by the act of measuring, and the organization loses the only signal it had about its own capacity.
6. Fixing scope, date and budget leaves only one variable. If all three are set at the gate, the sole remaining degree of freedom is how well the work is done. That is the variable nobody votes to cut in a meeting and everybody cuts quietly under a deadline, which is why W-Agile programs accumulate defects and rework in a pattern their status reports never show.
7. Two definitions of done, both enforced. The team's definition is working software. The gate's definition is a documentation package produced for approval. Both are audited, so the work is finished twice, and the second finishing produces artifacts that describe a system as it was specified rather than as it exists.
8. Accountability separates from authority. The team is held accountable for a date it did not set, against a scope it cannot change, using information only it possesses. That is not a morale problem with an engagement-survey solution. It is a structural misconfiguration, and it is the condition under which capable people reliably produce mediocre results.
9. It manufactures the resistance it will later blame. Two cultures are asked to occupy one delivery. The gate culture is rewarded for predictability, documentation and approval; the team culture is rewarded for adaptation and working software. Individuals are required to hold both, and the contradiction is not theirs to resolve, so it resolves as cynicism. The lasting damage is to the next change rather than this one: a team that has watched its own findings die in a queue has learned, accurately, that participation is not worth the effort, and it brings that lesson to whatever the organization tries next. Leaders then read the resulting flatness as resistance to change and buy training for it.
10. Two process systems are funded and one is deducted from the other. The gate apparatus is not removed when the cadence arrives; the cadence is added to it. So the organization now pays for stage reviews, change boards, phase documentation and release governance, and also for planning sessions, daily standups, refinement, reviews and retrospectives. Add a scaling framework and it pays for a third layer to coordinate the first two. All of that is real cost in the most expensive hours it has, and the agility it was bought to produce was structurally foreclosed at the first gate. This is the specific sense in which W-Agile is worse than either parent: honest waterfall at least does not pay for the ceremony.
11. The diagnosis is systematically blocked. This is the one that makes the others durable. When a W-Agile program disappoints, the visible layer is the ceremony and the causal layer is the decision structure, so the retrospective examines the visible one. The findings are always the same: estimates need to improve, the team needs more discipline, the backlog needs grooming. Every one of those is actionable, which is exactly what makes them attractive, and none of them touches where the authority sits. The organization then runs an improvement program against the wrong variable and concludes from its failure that agile does not work here.

The heavier the framework, the less agility

There is a general form of this, and it is worth stating on its own because it outlives the particular case. Agile was not written as a framework. It is four value statements and twelve principles, and it stayed that short deliberately: principles govern behavior without needing to be administered. A framework has to be administered. Every layer of it is a decision procedure, and a decision procedure is latency by construction.

So the relationship runs the wrong way round from how it is usually sold. Agility is inversely proportional to the weight of the apparatus claiming to deliver it. A team with a shared understanding and the authority to act on it needs almost no process. Add a framework and you have added coordination. Add a scaling framework on top and you have added coordination of the coordination, along with a body whose job is to hold the release train, which is a gate with a friendlier name. At each step the ceremony budget rises and the decision latency rises with it, and the thing both were bought to produce falls.

Agile was a set of principles about who decides. Every pound of framework added to it is a pound of decision procedure, and decision procedure is the opposite of the thing being bought.

This is also the honest answer to how often W-Agile works. In thirty years across federal, defense and commercial delivery, this arrangement has failed to produce what was promised far more often than it has succeeded, and the successes had a common feature: somebody quietly moved a decision right down to the team and did not put it in the process document. That is field observation, offered as such. It is not a statistic and it should not be dressed as one, which is the same reason this paper declines to lean on the industry failure percentages everybody quotes here.

The Four A's reading

This is an Authority condition, and reading it as anything else produces the wrong intervention. Authority asks whether decisions sit where the knowledge is and whether the people holding them can actually exercise them. Hayek argued in 1945 that the knowledge a system needs is dispersed among the people at the point of action and cannot be aggregated upward without being destroyed in transit. Jensen and Meckling made the organizational form of the same argument: knowledge that is expensive to transfer means the decision right should move to the knowledge, and moving it creates a control problem the organization then has to solve deliberately. Galbraith framed the whole design question as information processing capacity, where the choice is between reducing how much information must travel and increasing the organization's ability to move it.

W-Agile answers all three wrongly at once. It leaves the decision right at the gate, requires the knowledge to travel upward to reach it, and adds a cadence that increases how often the journey has to be made. The Attention cost is real and secondary: teams spend their protected time preparing to ask rather than doing the work. Adaptability appears blocked, and is not; the capability to adapt is present in the team and has nowhere to discharge. Diagnose it as Adaptability and you will buy training for people who already know what to do.

A federal data program we worked on had run in exactly this configuration for years. The engineers knew what was wrong with the warehouse and had known for some time. Nothing in the delivery cadence was broken. What changed the outcome was not a better process: it was moving the decision authority to where the knowledge already was, at which point a backlog that had absorbed six years of effort cleared and the rebuilt platform reached production inside eight months.

Evidence matrix

One caution about the numbers usually quoted in this argument. The widely circulated industry figures on project failure rates come from a survey whose methodology Eveleens and Verhoef examined in detail and found unreliable enough that the rates cannot support the conclusions drawn from them. The case here does not rest on them and should not.

What executives should do

Stop asking whether the organization is agile. It is the wrong question and it has no answerable form. Ask instead: name the last time a demonstration changed something that had already been committed, and count the days between the finding and the change taking effect. That number is your real cadence, and it is the only one that matters. If nobody can produce an instance, the loop has never decided anything and you are running W-Agile whatever the wall boards say. Two supporting questions get you the rest of the picture: inside a sprint, does anyone test on day two, and when was the last time the team changed its own way of working without asking permission.

The fix is not more ceremony and not less governance. It is naming, for each class of decision, who may make it and how long it takes, and then moving the ones that depend on knowledge the team alone holds down to the team, with the constraints stated in advance rather than adjudicated case by case. Gates that exist for a real obligation, a regulator, a safety case, a contract, stay. Gates that exist because nobody revisited them go. The test is whether a person outside the team can produce the reason.

The instinct after reading this is to go and select a better framework. Resist it, because that instinct is the disease presenting as the cure. Playbooks are best written at the team level, and the reason is authority rather than quality. A playbook produced elsewhere and handed down is a transfer of decision rights wearing the costume of a document: every procedure in it is a decision somebody outside the work has already made on the team's behalf, and following it is the act of not deciding. A playbook the team writes is the opposite artifact. It is a record of decisions the team already holds, made explicit so they survive a handover and can be argued with. The two look identical on a page and point in opposite directions.

That gives leadership a smaller job and a harder one. State the outcomes, the constraints that are genuinely non-negotiable, and the interfaces where this team's work meets another's. Then stop specifying. Ask to see the team's playbook rather than issuing one, and read it as evidence: a team that cannot write down how it works has not agreed on how it works, which is a real finding and a more useful one than a compliance score. Where governance needs assurance, satisfy it with visibility into what the team decided and why, which costs the team almost nothing, rather than with approval of each decision, which costs it everything this paper has been describing.