Iterative Development Before Agile Even Had a Name
Iterative Development Before Agile Even Had a Name
The Agile Manifesto was signed in February 2001. But if you were on a good software team in 1997, you were probably already doing most of what it described — without the vocabulary, the certifications, or the consultants.
At Motorola we built the NMS using what we called "spiral development" — a term borrowed from Barry Boehm's 1988 paper. Looking back from 2026, it was iterative development with two-week cycles, working software at each milestone, and regular adjustment based on what we learnt.
What We Were Reacting Against
The dominant methodology at large companies in the mid-90s was waterfall: requirements, design, implementation, testing, deployment — each phase completing before the next began. On a six-month project, this meant writing requirements documents in January, not running the software until October, and discovering that the requirements were wrong in November.
We had watched this play out on two projects before the NMS. Both delivered late, both required significant rework because the users' needs had become clearer during the wait, and both left the engineering team exhausted.
What We Did Instead
Two-week cycles. We planned two weeks of work at a time. At the end of each cycle we had working software — not a design document, not 90% of a feature, but something running that could be shown to a stakeholder.
The planning meeting. Monday morning, one hour, the whole team. We reviewed what was done, what was not done, and why. We agreed on the next two weeks' worth of work. We kept a handwritten card for each task — title, owner, estimated days.
Daily coordination. Not a formal standup (we did not call it that), but a five-minute conversation at 9am: what did you do yesterday, what are you doing today, is anything blocked? Three people was three sentences. The purpose was to surface blockers before they cost a day.
Working software at each milestone. Every two weeks, a new build was installed on the test system. Stakeholders could use it. Feedback was immediate and concrete — not "this requirement is ambiguous" but "when I click this button nothing happens."
What We Learnt
Estimates are wrong; cycles are useful. Individual task estimates were frequently wrong. But having a fixed two-week boundary forced regular prioritisation. When new requirements arrived mid-cycle, we made a deliberate choice: defer them, or defer something else. Nothing was silently absorbed.
Working software beats written requirements. The moment stakeholders could interact with a running system, requirements that had seemed clear became obviously wrong or incomplete. Better to discover this at week two than at week twenty.
Small teams outperform large ones. Six people in daily coordination built faster and with fewer integration problems than the twelve-person waterfall project. Communication overhead grows quadratically with team size. A team of six has fifteen communication pairs; a team of twelve has sixty-six.
Responding to change is a skill. When a network architecture change invalidated two weeks of completed work, the question was not who to blame but how to adapt. Teams that treated change as failure got demoralised. Teams that treated it as information updated their plan and moved on.
The Agile Manifesto Put Words to It
When I read the Agile Manifesto in 2001 I recognised every principle from years of practice. "Working software over comprehensive documentation" — yes. "Responding to change over following a plan" — yes. "Customer collaboration over contract negotiation" — yes.
What the manifesto did was give a name and a shared vocabulary to practices that had been discovered independently by many teams. The naming made it teachable and spread it to organisations that had not found it organically.
The risk of naming it — which became visible as Agile industrialised — was that the vocabulary could be adopted without the practices. You can have daily standups, sprint planning, and a backlog, and still deliver slowly because the underlying commitments — short cycles, working software, honest estimation — are not there.
The practice matters. The ceremonies are only useful if they enforce the practice.