Balancing Agility and Discipline
Neither agile nor plan-driven methods are better. Each has a home ground — the conditions it was built for — and the risk in a project comes from how far it sits from that home ground. Boehm and Turner’s contribution is a way of measuring that distance on five axes [1].
1. The five discriminators
| Axis | Agile home ground | Plan-driven home ground |
|---|---|---|
| Size | Smaller teams and projects | Larger teams and projects |
| Criticality | Untested on safety-critical work; light documentation becomes a liability | Evolved for highly critical products; hard to tailor down |
| Dynamism | Simple design plus continuous refactoring excel under high change | Detailed plans amortise when requirements are stable |
| Personnel | Needs ≥30% full-time skilled staff; no unskilled-only teams | Tolerates a higher proportion of less-experienced staff, given a framework |
| Culture | Empowerment through many degrees of freedom — “thrives on chaos” | Empowerment through a framework of policies — “thriving on order” |
Dynamism is the rate at which requirements change. High change favours agile because refactoring is cheap relative to re-planning; low change favours plan-driven work because a detailed plan gets amortised instead of discarded. It is the axis that most often decides the answer, because it is the one teams misjudge — most projects believe their requirements are more stable than they turn out to be.
Criticality is the loss caused by failure, and the point students routinely miss is that it cuts both ways. Agile methods are untested when tailored up to safety-critical work. Plan-driven methods are “hard to tailor down efficiently to low-criticality products” — the ceremony that protects a flight-control system is pure cost on an internal reporting tool. Neither direction is free.
After Boehm and Turner [1]. A, a six-person reporting tool, is pulled out only by dynamism; B, a 200-person avionics programme, is at the rim on everything else.
The polar chart is a communication device, not a measurement. The five axes have no units and are not commensurable, so the area enclosed by a plotted shape means nothing. It shows which axes pull which way; it does not compute an answer.
2. Where the project sits: size and criticality
Boehm and Turner’s personnel levels come from Alistair Cockburn, whose earlier grid plots a project on size against criticality [2]. Criticality runs through four loss zones — comfort, discretionary money, essential money, life — and size through bands from a handful of people to a thousand, giving cells such as C6 or L100.
After Cockburn’s Figure 5 [2]. Darker cell, heavier method.
His second principle states the rule directly: “A more critical system — one whose undetected defects will produce more damage — needs more publicly visible correctness in its construction.” Weight is a cost, bought for criticality and size, not a virtue.
The part worth teaching is that a project’s coordinates move while you are running it, and the methodology does not follow by itself. Cockburn’s own example is the Chrysler C3 project, which “stretched a D6 methodology to fit a D14 project” — a method sized for six people and discretionary money, still in use at fourteen.
3. Running the assessment for real
Example — Servasport. A small Irish company — four developers and a graphic designer, delivering 10–12-week fixed-price projects — ran Boehm and Turner’s five-step assessment and published the result [3]. Their risk totals came out at environmental 3, agile 8, plan-driven 15, which put them squarely in the risk-based agile branch.
The decision is not the valuable part. The mitigations are: personnel turnover scored 4 against the agile side, so they introduced a wiki and mentored role-swapping; rapid requirements change and short cycles scored against the plan-driven side, so they wrote weekly incremental delivery for the final three weeks into the contract itself.
They also added a sixth axis — client involvement — which is the lesson in miniature. Boehm and Turner bound their own instrument: the risk lists are “candidates for consideration… neither complete nor always applicable”.
So a good assessment outputs “be agile, and here are the two risks that creates, and what we did about one” — not a verdict.
How solid is this?
- No selection instrument here has been validated. No study shows that projects choosing by Boehm and Turner, or by Cockburn, outperform those that do not. They structure an argument; they do not settle it.
- Cockburn’s personnel levels rest on an unvalidated skill taxonomy, and the percentage thresholds Boehm and Turner attach to them are given without derivation [2].
- Servasport is one company, one assessment, and no outcome was measured [3]. It shows the method being applied, not that applying it helped. It is peer-reviewed, which makes it the best worked example available.
- This material is 2000–2006. Kanban, SAFe and LeSS postdate it. Read it with choosing a framework, which carries the evidence that teams do not select methods cleanly in the first place.
Acknowledgments
This page adapts material from lectures by Eduardo Miranda and David Root [4] on software project management.
References
- B. Boehm and R. N. Turner,Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional, 2003.
- A. Cockburn,“Selecting a Project’s Methodology,” IEEE Software, vol. 17, no. 4, pp. 64–71, July 2000, doi: 10.1109/52.854070.
- P. S. Taylor et al.,“Applying an Agility/Discipline Assessment for a Small Software Organisation,” in Product-Focused Software Process Improvement, J. Münch and M. Vierimaa, Eds., Springer, 2006, pp. 290–304. doi: 10.1007/11767718_25.
- D. Root,Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.