01The big picture
Five names appear repeatedly when we talk about iterative software processes: Agile, Scrum, XP, Kanban, and Spiral. Students often hear them as if they were five alternatives on a menu. They are not. They sit at different levels and were created to solve different problems.
Agile is a philosophy, not a process. Scrum, XP, and Kanban are frameworks or practices that follow that philosophy. Spiral is an older risk-driven process model that pre-dates Agile by more than a decade and prioritises something different – managing risk through repeated planning cycles. Knowing which level you are talking about prevents most of the confusion in this topic.
What each one prioritises, in one line
02Iteration is fundamental
Before we look at the named methods, we need a vocabulary for what they all share. Modern software processes take iteration as fundamental, and try to provide ways of managing, rather than ignoring, the risk that comes with iteration. System requirements always evolve in the course of a project, so process iteration where earlier stages are reworked is part of the process for any non-trivial system.
Two related ideas describe how iteration works: iterative development and incremental development. They are often used interchangeably, but they mean different things. The distinction is one of the most useful clarifications in this chapter.
Iterative versus incremental – the Mona Lisa
Imagine painting the Mona Lisa. Iterative means you sketch the whole picture roughly first, then go over the whole picture again refining it, then refine it once more. After each pass, you have a finished version of the whole – just at a lower resolution. Incremental means you paint the face fully first, then add the hands, then the background, then the landscape. After each pass you have only part of the painting, but the parts you have are complete.
To make the difference clear in words: the iterative top row shows the same whole portrait every time – outline first, then shapes, then shading, then face, then full detail. After every pass you have a finished version of everything, just at a lower level of polish. The incremental bottom row shows different regions of the portrait being added one at a time – head first (panel 1), then torso (panel 2), then arms (panel 3), then hands (panel 4), then the landscape background (panel 5). After every pass you have a finished version of some parts, but the parts you have are complete and would not be changed by the next pass. Real software work almost always combines the two: an incremental release adds a new feature region, and within that release iteration refines the feature until it is good enough.
How iterations are organised
An iteration is a fixed-period cycle, usually two weeks long, in which the team carries out the same set of activities – analysis, design, implementation, testing, review – and produces a result that can be inspected. Feedback from one iteration feeds into the next, leading to refinement of requirements, design, or both.
Two related approaches to iteration
Sommerville distinguishes two related approaches to layering iteration onto a process:
Why incremental development is the dominant approach
This is the foundation on which the named methods we cover next – Agile, Scrum, XP, Kanban, and Spiral – are built. Each is an answer to a different version of "how do we structure iteration?".
03How they came about
The order in which these methods were created tells you something important: each one was a reaction to a problem the previous generation could not solve well.
04Agile – the philosophy
The idea
Agile is a way of thinking about software development. It does not tell you to hold a daily meeting or to use a board with sticky notes. Those are implementations of Agile, not Agile itself. The defining document is the Manifesto for Agile Software Development (2001), which states four values and twelve principles.
We have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Manifesto is careful: the items on the right have value, but the items on the left have more value. This is not a rejection of plans or documents.
What it really prioritises
Agile bets that on most modern software projects, you cannot fully know the requirements at the start, technology will change while you build, and the customer will see things differently once they have something to use. Given those bets, the rational strategy is to deliver something working as soon as possible, learn from feedback, and adjust. Everything else flows from that.
How it works in practice
Strengths
- Handles changing or unclear requirements well
- Produces value early; reduces the "big-bang failure" risk
- Engages users and builds trust through visible progress
- Surfaces problems quickly rather than at the end
Limitations
- Hard to use where requirements truly cannot change (regulated, safety-critical)
- Requires customer availability and a willing organisation
- Can drift without discipline; "no documentation" is a misreading
- Less suited to fixed-price, fixed-scope, fixed-date contracts
Agile does not mean "no planning" or "no documentation". It means just enough planning and just enough documentation to do the next useful piece of work. A team that produces nothing usable for three months is not Agile, regardless of how many sticky notes are on its wall.
The wider family of named Agile methods
Scrum, XP, and Kanban are the three named methods we will study in detail – they cover most of what teams actually do. But the Agile umbrella is larger. Sommerville and Adel's deck list a wider set you may encounter in industry:
You do not need to remember the details of these methods – we focus on Scrum, XP, and Kanban for good reasons. But knowing the family exists matters: Agile is wider than the three best-known methods, and different organisations choose different members of the family for different reasons.
The course project follows a phased structure that looks plan-driven on its surface – Initiation, Business Definition, Requirements Engineering, Requirements Analysis and Modelling, System Modelling and Design. But notice the customer-developer arrangement: each group plays both roles, and the milestone interview workshops between phases are exactly the "individuals and interactions" and "customer collaboration" the Manifesto talks about. The phases are heavyweight; the conversations between phases are agile in spirit. Pay attention to that conversation – it is where most of the learning happens.
05Scrum – the most-used framework
The idea
Scrum is a lightweight framework for managing complex product development. It does not prescribe how to engineer software – it does not tell you to write tests or pair-program. It tells you how to organise the team, the work, and the rhythm of decision-making, so the team can adapt as it learns. The current definition lives in the Scrum Guide, last revised in November 2020.
The structure: 3 + 5 + 3
- Product Backlog. An ordered list of everything that might be needed in the product. The Product Owner is responsible for the order, which expresses what is most valuable to do next.
- Product Goal. A single sentence describing what the product is trying to be in the longer term. Anchors the Product Backlog.
- Sprint Backlog. The subset of the Product Backlog the team commits to in this Sprint, plus the plan for delivering it.
- Sprint Goal. A short statement of why this Sprint is worth running. Gives the team room to negotiate scope while protecting the intent.
- Increment. A working slice of the product that meets the Definition of Done at the end of the Sprint. Multiple increments can be produced in one Sprint.
- Definition of Done. The shared agreement on what "finished" means – tested, integrated, documented, deployable. An increment that does not meet it is not done.
How it works in practice
A typical Scrum team has around five to nine people working in two-week sprints. The Product Owner orders the Product Backlog by value. At Sprint Planning the team picks items it forecasts can be Done by sprint-end and crafts a Sprint Goal. During the sprint, developers re-plan daily in a 15-minute Daily Scrum. At the end, the Sprint Review shows the Increment to stakeholders and gathers feedback; the Retrospective looks at how the team worked and identifies improvements. A new sprint starts the next day.
Strengths
- Simple, well-known structure; easy to start
- Fixed cadence creates predictability and rhythm
- Clear accountabilities reduce confusion
- Forces frequent inspection of both product and process
Limitations
- Says nothing about engineering practices – easy to get poor code
- Sprint boundaries can feel artificial for support or operations work
- Requires a real Product Owner, often missing in practice
- Often adopted as ceremony only ("zombie Scrum")
06XP – engineering excellence
The idea
Extreme Programming asks: which engineering practices, if you push them hard, make iterative development actually deliver good software? Kent Beck's answer was to take a small set of practices known to work, and apply each one to its extreme. If code reviews are good, do them constantly – pair programming. If testing is good, write the test before the code – test-driven development. If integration is good, do it many times a day – continuous integration.
Beck describes XP as built on five values that the practices express in concrete behaviour:
- Communication. Talk to each other. Pair programming and on-site customer presence are how XP enforces this.
- Simplicity. Do the simplest thing that could possibly work. Refactor when more is needed, not before.
- Feedback. Get information about what works as fast as possible – tests, integration, releases, customer reaction.
- Courage. Tell hard truths. Throw away code that does not work. Refactor confidently because the tests have your back.
- Respect. Care about the work and about each other. Without respect, the other four values do not survive contact with stress.
The core practices
XP defines around a dozen primary practices and a similar number of corollary practices that build on them. The cards below cover the ones you are most likely to encounter in modern software development.
How it relates to Scrum
Scrum and XP are not competitors. Scrum tells you how to organise sprints and decide what to build; XP tells you how to build it well. Many teams adopt Scrum at the management level and XP practices at the engineering level. The two were created in roughly the same period by people in conversation with each other, and the Agile Manifesto signatories include both Scrum and XP figures.
Strengths
- Produces high-quality, maintainable code
- Tests act as living documentation
- Team capacity grows as the code stays clean over time
- Practices reinforce each other – pair programming makes refactoring safer, tests make pair programming sharper
Limitations
- Demands significant developer skill and discipline
- Pair programming is hard to justify to managers without trying it
- Practices interact – partial adoption ("we do TDD but not refactoring") often fails
- Less popular as a brand today; the practices live on inside other frameworks
07Kanban – managing flow
The idea
Kanban (a Japanese word meaning "signboard" or "visual signal") came from Toyota's manufacturing system. The software adaptation, described by David Anderson in 2010, treats software work as a flow through stages and asks one core question: how do we make work flow smoothly, without piling up at any stage? Unlike Scrum, Kanban does not introduce sprints, fixed roles, or planning ceremonies. It can be applied on top of an existing process.
The core practices
- Work item. A single piece of work that flows across the board – usually represented by one card. Could be a feature, a bug, a request, a bit of investigation.
- Work in progress (WIP). The number of items currently being worked on. The whole point of Kanban is that limiting WIP improves flow, because the team finishes things instead of starting them.
- Lead time. The clock time from when an item enters the board (first column) to when it leaves the board (Done). What the customer experiences.
- Cycle time. The clock time from when work actively starts on an item (it leaves the Backlog) to when it is Done. What the team experiences.
- Throughput. The number of items completed per unit of time (per week, per month). The team's rate of finishing things.
- Value stream. The whole sequence of activities that turn an idea into delivered value. Each Kanban column is one stage of the team's value stream.
The big difference from Scrum
Scrum
- Time-boxed (sprints of 1–4 weeks)
- Fixed accountabilities (PO, SM, Devs)
- Plan and commit per sprint
- Inspect at sprint boundaries
- Best for product development
Kanban
- Continuous flow, no sprints
- No prescribed roles
- Pull new work when capacity frees up
- Inspect continuously through metrics
- Best for ongoing or operational work
Strengths
- Easy to adopt – overlay on existing process
- Excellent for support, operations, and varied-priority work
- WIP limits expose bottlenecks honestly
- Predictable lead times once flow is stable
Limitations
- No built-in product planning – needs to be added
- Less rhythm; harder to align stakeholders to a cadence
- Can disguise lack of discipline as "flexibility"
- Not ideal for teams that need a fixed scope and date
08Spiral – the older, risk-driven model
Spiral was published by Barry Boehm in 1988, more than ten years before the Agile Manifesto. It is iterative, but it is not Agile. It belongs to the family of plan-driven process models. It is included here because it is the historical bridge between waterfall and the Agile family – it was the first widely-used model to take iteration and risk seriously.
The idea
Boehm observed that the most expensive failures in large software projects came from risks that were ignored or underestimated until late. His solution was to make risk analysis the primary driver of the process. Each loop of the spiral is one iteration; in each loop, you identify the biggest current risks and do whatever is needed (prototyping, modelling, simulation) to resolve them before continuing.
The four quadrants of each loop
How the prototypes grow across the loops
One thing the main figure shows but does not explain: the four prototypes are not four versions of the same thing. They get progressively more concrete, more operational, and more expensive, in step with the loops growing outward.
What each loop produces, and why each one is useful
The Spiral diagram is dense, but its loops have a clear purpose. Here is what a project would actually produce on each one.
The genius of Spiral is that it does not commit to building anything expensive until the cheap-to-resolve risks have been resolved. Each loop's deliverable is as concrete as it needs to be for the risks of that loop, and no more. A project that spends a whole year on detailed design before writing any code is doing waterfall, not Spiral; a project that starts coding before there is a Concept of Operation is doing something else again. The four prototypes pictured in Figure 8 are the markers of the four loops doing their job.
What it shares with Agile, and what it does not
Spiral and Agile agree on
- Iteration is essential
- You cannot plan everything upfront
- Each iteration should reduce uncertainty
- Stakeholder involvement matters at every loop
Spiral and Agile differ on
- Spiral is heavyweight; Agile is lightweight
- Spiral iterations can be months; Agile iterations are weeks
- Spiral focuses on managing risk; Agile focuses on delivering value
- Spiral produces extensive documentation per loop; Agile keeps documentation lean
Strengths
- Excellent for very large, ambitious, risky projects
- Forces explicit attention to what could go wrong
- Each loop can use whichever development style suits its risks
- Suitable for safety-critical and high-investment systems
Limitations
- Heavyweight and document-intensive
- Requires real expertise in risk assessment
- Long loop times unsuited to small, fast-changing projects
- Hard to estimate cost and duration upfront
The course project is a teaching exercise, not a high-stakes industrial system. The risks are bounded (the worst that can happen is a poor grade), the requirements come from a peer customer group rather than a regulator, and the timeline is fixed by the academic calendar. Spiral's strengths – ranking and resolving real project risks before committing further investment – are wasted in this setting. The project's plan-driven phase structure is the right shape for a learning context. But when you graduate and move to projects where money, safety, or reputation are on the line, knowing that Spiral exists, and how it works, is part of being able to choose well.
09Used together – what really happens in practice
In real teams, you almost never find a textbook implementation of any one of these methods. The interesting question is which combinations are common and why.
Common combinations
10Choosing one – short, situated examples
The honest answer to "which one should I use?" is "it depends". The factors that matter are the size and stability of requirements, the criticality of the system, the team's experience, and the regulatory and contractual context. Below are concrete situations and a defensible answer for each. None of these are the only valid answer; they show the kind of reasoning to apply.
The market is uncertain, the team is small, and features need to evolve weekly based on user feedback. Scrum + XP is the standard fit. Two-week sprints give a rhythm for stakeholder demos; XP practices keep the code base clean enough to keep changing. Pure Kanban would also work if priorities shift faster than a sprint can absorb.
Tickets arrive constantly, urgencies vary, and there are no "features" to plan. Sprints feel artificial because next week's work is unknown today. Kanban fits. WIP limits prevent overload; lead-time metrics give predictable response expectations.
Reliability target of 99 %, hard security requirements, must be deployed across 1000 ATMs. Mistakes are very expensive and requirements are stable. A pure Agile approach is risky here. Spiral, or at minimum a plan-driven model with explicit risk reviews, is more defensible. Engineering practices from XP (especially testing and CI) remain valuable inside whichever model is chosen.
Long timeline, moderately stable requirements, large user base, multiple stakeholder groups. Incremental delivery within an Agile framework (Scrum) is a strong fit: deliver core registration first, then add modules. Spiral could justify itself if the integration risks (with finance, with the ministry) are deemed dominant.
The device interface and the external system are the major unknowns. Spiral with Agile inner loops: the early loops focus on resolving integration and clinical-safety risks via prototypes; later loops use Scrum-style sprints for the user-facing app once the unknowns are bounded.
Most components exist; the novelty is in the user interface and accessibility. Component-based development with Agile (Scrum + XP) fits well. Frequent user testing with the target audience is more valuable than upfront planning.
The pattern across the six examples
Notice that the answer is rarely a single named method. Most real situations call for a blend:
The first companion in this pair, on generic process models, looks at this same choice from the other direction – starting from the kind of software being built and working out which model fits. Reading the two together gives you both perspectives: what the methods are, and which methods suit which kind of work.
A decision sketch
11References
For each method, the most authoritative source is given first.
Primary sources
- Beck, K. et al. (2001). Manifesto for Agile Software Development. agilemanifesto.org
- Schwaber, K. and Sutherland, J. (2020). The Scrum Guide. scrumguides.org
- Beck, K. and Andres, C. (2004). Extreme Programming Explained: Embrace Change, 2nd edition. Addison-Wesley.
- Anderson, D. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
- Boehm, B. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer, 21 (5), 61–72.
Course textbooks (where these methods are also covered)
- Sommerville, I. (2016). Software Engineering, 10th edition, Chapters 2 and 3. Pearson. (R2)
- Pressman, R. and Maxim, B. (2020). Software Engineering: A Practitioner's Approach, 9th edition, Chapters 3–5. McGraw-Hill. (R5)
- Bruegge, B. and Dutoit, A. (2013). Object-Oriented Software Engineering Using UML, Patterns, and Java, 3rd edition. Prentice Hall. (R1)
Recommended further reading
- Takeuchi, H. and Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review, 64 (1), 137–146. The article that inspired Scrum.
- Cockburn, A. (2006). Agile Software Development: The Cooperative Game, 2nd edition. Addison-Wesley.
- Larman, C. and Vodde, B. (2016). Large-Scale Scrum: More with LeSS. Addison-Wesley. For scaling Scrum to large programmes.