Agile & Scrum

What Agile Is, and What It Isn't

By the late 1990s many software teams felt buried in paperwork. The formal life-cycle models of Part II asked for complete, signed-off documents before any code was written, and by the time the code arrived the world had often moved on. Agile is the answer a group of practitioners gave to that problem: a way of working that steers by feedback from real, running software instead of by a fixed up-front plan.

The root idea: empirical process control exam

Every process has to be kept on track somehow; that is what process control means. Part II introduced the two basic ways of doing it, and agile only makes sense against them, so here they are again in brief.

• Defined process control fixes a well-defined set of steps in advance and follows them, trusting that the same inputs always give the same output. It fits low-volatility, predictable work. You plan what you expect to happen, enforce the plan, and use formal change control, because change is expensive. The slides' analogy is a burger recipe, and the SDLC examples are the waterfall and the V-model.
• Empirical process control means "expect the unexpected": you control the work by observing what actually happens, inspecting it and adapting. It fits complex, volatile, novel work. You learn as you progress, expect and embrace change, inspect and adapt in short development cycles, and treat estimates as indicative only. The slides' analogy is a flight, where the pilot keeps correcting course for the weather, and the examples are Scrum and the other agile frameworks.

Snowbird, 2001: the Agile Alliance

In February 2001, seventeen practitioners of so-called "lightweight" methods met at the Snowbird ski resort in Utah. Between them they represented XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD and Pragmatic Programming, all methods that played down document-driven development. They found they agreed on a short set of values, wrote them down as the Manifesto for Agile Software Development, and named themselves the Agile Alliance. Some of the methods they represented were already years old, as the timeline shows.

Agile is a set of values, not a process exam

The single most important point about agile is that it is not a single process model. Waterfall tells you which phase comes next; agile does not. Agile is a set of core values (the Manifesto) plus principles that follow from them. Frameworks such as Scrum, XP and Kanban are concrete ways of working that put those values into practice. A framework here means a skeleton of roles, meetings and rules that a team fills in with its own practices.

Two consequences follow, and both are easy marks to lose.

The Manifesto: Four Values and Twelve Principles

A process model tells a team what to do; the Manifesto instead tells a team what to prefer when two good things compete for its time. That is why it is so short, and why it applies to Scrum, XP and Kanban alike. This section gives the four values, then the twelve principles that spell out what they mean in practice.

The four values exam

Each value is written as a preference: one thing over another. Read "over" as "more than", not "instead of".

The twelve principles exam

Behind the four values sit twelve principles. Where a value says what to prefer, a principle says what that looks like day to day. The figure pairs each principle with a practice that realises it, because exam answers earn marks for exactly that link.

In words, with a little more detail where the card is terse:

1. Satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development, because change is a competitive advantage for the customer.
3. Deliver working software frequently, every couple of weeks to every couple of months, preferring the shorter timescale. In Scrum, Sprints are one month or less.
4. Business people and developers work together daily. Scrum does this through the Product Owner, XP through the on-site customer.
5. Build projects around motivated individuals, give them the support they need, and trust them to get the job done.
6. Face-to-face conversation is the most efficient and effective way to communicate.
7. Working software is the primary measure of progress, not documents written or phases completed.
8. Work at a sustainable pace, one that sponsors, developers and users can keep up constantly and indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity, "the art of maximizing the amount of work not done", is essential. XP's slogan for this is YAGNI, "you aren't gonna need it".
11. The best architectures, requirements and designs emerge from self-organising teams. The 2020 Scrum Guide says "self-managing" instead.
12. At regular intervals, the team reflects on how to become more effective and adjusts its behaviour. In Scrum this is the Sprint Retrospective.

The agile mindset

Values and principles are words; the lecture's Atlassian video showed what they look like in a real team. What you saw was understanding, collaboration, flexibility, feedback loops and, above all, adapting to change. What you did not see was big up-front planning, detailed documentation, a step-by-step predefined process, or handoffs, where one specialist finishes a piece of work and throws it "over the wall" to the next.

Why does it matter so much? Studies attribute 60–80% of project failures to poor requirements gathering, analysis and change management, which are exactly the things an agile mindset keeps revisiting. The mindset rests on four pillars.

The second pillar has a memorable picture behind it. If you paint a house and only check the colour at the end, a wrong colour means repainting the whole house. If you paint one wall and check it first, a mistake costs one wall. Small batches catch defects while they are still cheap.

Agile is also both iterative and incremental (Mountain Goat Software). Incremental means adding new pieces of value one at a time; iterative means improving what already exists through feedback. An agile team does both in every cycle.

When Agile Fits, and When It Doesn't

Agile is not automatically better than a plan-driven process. It rests on some strong assumptions about the project, and when those fail, pure agile can do real harm, for example in safety-critical software. This section gives you the tools to decide: van Lamsweerde's assumptions, a side-by-side comparison of the two philosophies, and the subject's guidance on when to choose each.

Agile's hidden assumptions (van Lamsweerde 2009) exam

Agile arose as a reaction to heavyweight, ceremony-laden processes. The T02 reading, from van Lamsweerde's requirements-engineering textbook, points out that it only works if some strong assumptions hold. Each row below gives an assumption and what you need instead when it fails. A stakeholder is anyone with an interest in or influence over the project (customer, user, sponsor, maintainer, regulator); an NFR (non-functional requirement) is a quality the system must have, such as reliability or speed, as opposed to a feature.

The lecture slides list only assumptions 2, 3, 4, 7 and 8 (tagged above), and ask whether the critical parts of safety- or mission-critical systems should be built with agile. T02 gives air traffic control, power plants and banking as examples of systems that break the assumptions, and adds that "Most projects obviously do not meet them all, if any."

Agile versus plan-driven, side by side exam

The process models themselves are in Part II; here the two philosophies are compared row by row. The first row is the root difference: plan-driven processes assume the work can be defined as predictable, repeatable steps, while agile controls it empirically. Every other row follows from that. (A baseline is an approved, frozen version of a plan that progress is measured against; a backlog is an ordered to-do list of work.)

Choosing: formal, agile or hybrid exam

The W02 summary and T02 give guidance on when to choose each approach. Match the project's facts to a column, and quote those facts in your answer.

The lecture poll scenarios apply this guidance, and they are worth memorising as patterns.

Three misconceptions (T02)

T02 warns about three ways teams fool themselves into thinking they are agile:

• Slipping back into waterfall when the team comes under pressure: dropping reviews and feedback and reverting to "big plan, code, test at the end".
• Doing many short waterfalls and calling it agile.
• Waterfall masquerading as agile: using the label without the frequent iteration, collaboration or flexibility.

eXtreme Programming (XP)

The Manifesto says what to value, but a team still has to write the code somehow. XP is the agile framework that answers the engineering question: which programming practices let a team release often without the code falling apart?

Origins, purpose and name

XP was developed by Kent Beck in the late 1990s on Chrysler's C3 payroll project, with Ron Jeffries as coach, and Beck published Extreme Programming Explained in 1999. Its purpose is frequent releases in short development cycles, which improve productivity and create checkpoints where new customer requirements can be adopted. Of all the agile frameworks, XP is the most engineering-specific.

The name comes from taking good practices to extremes. If code review is good, review all the time: that is pair programming, two programmers at one keyboard, one typing and one reviewing. If testing is good, test first: that is test-driven development (TDD), where you write a failing automated test before the code that makes it pass.

Five values and twelve practices

XP has five values: communication, simplicity, feedback, courage and respect. Respect was added in 2004. The 12 original practices fall into four groups, shown below. A few need defining: the planning game is XP's planning meeting, where the customer picks the stories (small features) for the next cycle and the developers estimate them; continuous integration (CI) means merging and testing everyone's code many times a day; refactoring is improving the code's structure without changing its behaviour; collective code ownership means anyone may change any code; and the system metaphor is a shared story of how the system works.

Roles, fit and criticisms

XP defines four roles. The Customer decides the features, the acceptance criteria (the tests a feature must pass to be accepted), the budget and the order of work. Everyone else on the team is a Developer. An optional Tracker tracks metrics, and a Coach mentors the team on the practices.

Kanban: Visualise Work, Limit WIP

Some teams don't work on a planned product at all: a support desk, for example, gets an unpredictable stream of tickets. Planning two weeks ahead makes little sense there. Kanban solves the problem of keeping such a stream flowing smoothly, by making the work visible and refusing to start more than the team can finish.

Origins and core ideas

Kanban is Japanese for "billboard", and it began as a Toyota lean manufacturing method. Its core ideas are to visualise work, limit work in progress (WIP) and maximise efficiency. Work in progress means items that have been started but not finished. The aim is to reduce the time from start to finish, the lead time.

The five fundamentals (Kanban Tool guide)

1. Visualise the workflow with cards on a board that has a column per stage.
2. Limit WIP by giving each column a maximum number of cards. This exposes bottlenecks.
3. Manage flow by measuring and improving lead time, cycle time and throughput.
4. Make policies explicit, for example what "done" means for each column.
5. Improve continuously.

Pull, not push

Kanban is a pull system: a stage takes new work only when it has capacity, and work is never pushed onto a stage that is full. It has no prescribed roles and no iterations, so delivery is continuous and priorities can change at any time; the next card pulled is simply whatever is at the top of "To Do" at that moment.

A WIP limit doing its job

The guide's example board has four columns: To Do, Develop (WIP limit 3), Test (WIP limit 2) and Done. Step through it to see how the limit turns an invisible problem into a visible one. Steps 3 and 4 continue the guide's example to show the pull in action.

Scrum: Definition, Pillars and Values

Scrum is the framework the rest of this Part, and much of the subject, is built on. Before its parts (people, events, artefacts) make sense, you need to know what Scrum is for, the theory it rests on, and the values it asks a team to live by.

Origins

Scrum's roots go back to 1986, when Takeuchi and Nonaka's Harvard Business Review paper "The New New Product Development Game" used a rugby analogy: in a rugby scrum the whole team moves down the field together as a unit, instead of passing a baton from runner to runner as in a relay. The first implementation followed in 1993 at Easel Corporation. In 1995, Jeff Sutherland and Ken Schwaber presented "The SCRUM Development Process" at the OOPSLA conference. The first Scrum Guide appeared in 2010, and the current version is from 2020 (the timeline in §3.1).

Mike Cohn added user stories and story points to Scrum practice. These are complementary practices, not part of the Scrum Guide; Part VI covers them.

What Scrum is exam

It follows that Scrum is not a programming method (it says nothing about how to write code) and not IT-specific: it could organise a marketing campaign. As the slides put it, Scrum is a way to organise groups of people to deliver something. It is also purposefully incomplete, so other practices, such as XP's engineering practices, fit inside it. Even so, the Guide warns: "implementing only parts of Scrum is possible, but the result is not Scrum."

Scrum in one picture

The slides summarise the whole framework in one diagram, redrawn below. Everything in it is explained in the next three sections; for now, follow the arrows and notice that the cycle never stops: the next Sprint starts the moment the last one ends. A Sprint is a fixed-length cycle of one month or less in which the team turns backlog items into a usable piece of product.

Foundations and the three pillars exam

Scrum is founded on empiricism and lean thinking. Empiricism means knowledge comes from experience, and decisions are based on what is observed (the empirical control of §3.1). Lean thinking means reducing waste and focusing on the essentials. On that foundation Scrum uses an iterative, incremental approach to optimise predictability and control risk, and the team collectively has all the skills needed to do the work. Empiricism is held up by three pillars.

The five Scrum values

Scrum asks the team to live five values: commitment to the team's goals and to each other; focus on the Sprint's work; openness about the work and its challenges; respect for each other as capable, independent people; and courage to do the right thing and tackle tough problems. When the team lives these values, the pillars "come to life" and build trust. XP's values overlap with these, which is a frequent source of MCQ distractors.

The Scrum Team and Its Accountabilities

In a plan-driven project one person, the project manager, plans the work, assigns it and answers for the result. Scrum deliberately splits that job three ways, so that nobody is both deciding what to build and dictating how. This section covers who is in a Scrum Team, what each of the three accountabilities answers for, and how they differ from a traditional PM.

The team as a whole exam

The Scrum Team is made up of one Product Owner, the Developers and one Scrum Master. It is typically 10 or fewer people, with no sub-teams or hierarchies, and it pursues one Product Goal at a time. It is cross-functional, meaning that between them the members have all the skills needed to deliver, and self-managing, meaning the team itself decides who does what, when and how. Outside the team are the stakeholders: users, customers, managers and anyone else with an interest in the product.

If a team grows too large, it should split into several cohesive Scrum Teams that share one Product Goal, one Product Backlog and one Product Owner (and, as §3.9 shows, one Definition of Done).

The Developers

The Developers are the people who create the usable Increment each Sprint (an Increment is a working, tested addition to the product; §3.9). They are accountable for creating the Sprint Backlog (the Sprint's plan), following the Definition of Done (the quality bar), adapting the plan each day toward the Sprint Goal, and holding each other accountable as professionals. The slide shows them covering self-organisation, design, development, UX, testing and delivery: everything needed to get from an idea to a usable product.

The Product Owner

The Product Owner (PO) is accountable for maximising the value of the product and for managing the Product Backlog. In practice that means:

• developing and explicitly communicating the Product Goal, the long-term objective;
• creating and clearly communicating Product Backlog items;
• ordering the items, i.e. deciding what is done first;
• keeping the Product Backlog transparent, visible and understood.

A few rules govern the PO. The PO may delegate this work to others, but stays accountable for it. The PO is one person, not a committee, so anyone who wants to change the backlog must convince the PO, and for the PO to succeed the whole organisation must respect the PO's decisions. Finally, only the PO can cancel a Sprint (§3.8).

The Scrum Master

The Scrum Master (SM) is accountable for establishing Scrum as the Guide defines it and for the Scrum Team's effectiveness. The Guide calls Scrum Masters "true leaders who serve", the idea of servant leadership: leading by removing obstacles and growing people's ability, not by giving orders. The SM serves three groups.

The slide adds a practical view (Atlassian) of what an SM actually spends time on: fostering communication, protecting the team from disruptive managers, Jira administration, burndown and velocity reporting, meeting facilitation, agile coaching, team support and removing blockers. (A blocker or impediment is anything stopping the team from progressing, such as a missing test server or a slow approval.)

Scrum Master vs traditional PM vs Product Owner exam

The sharpest difference between these three is leadership style. The traditional PM commands and controls, the Scrum Master serves, and the Product Owner decides what is built and in what order.

(A WBS, work breakdown structure, is the PM's tree of all the work, from Part VIII.) Pure Scrum has no PM role at all. Instead, the PM's activities are shared among the PO, the SM and the Developers (W01).

The Five Scrum Events

Empirical control only works if inspection and adaptation actually happen, regularly and on time, rather than "when we get round to it". Scrum guarantees this with five fixed events. Each one is a formal opportunity to inspect and adapt, and because they cover everything the team needs to discuss, they also reduce the need for other meetings.

The events, one by one exam

1. The Sprint. The Sprint is the container for all the other events. It has a fixed length of one month or less, and the next Sprint starts immediately after the previous one ends. During the Sprint, no changes are made that would endanger the Sprint Goal, and quality does not decrease; meanwhile the Product Backlog is refined as needed, and scope may be clarified and renegotiated with the Product Owner as more is learned. Only the PO can cancel a Sprint, and only if the Sprint Goal becomes obsolete.
2. Sprint Planning. The whole Scrum Team answers three questions. Why is this Sprint valuable? The answer becomes the Sprint Goal. What can be Done this Sprint? The Developers answer by selecting items, using their past performance, their capacity and the Definition of Done. How will the chosen work get done? The Developers decompose items, often into tasks of a day or less, and this is their sole call. The output is the Sprint Backlog.
3. Daily Scrum. A 15-minute event for the Developers, held at the same time and place every working day. Its purpose is to inspect progress toward the Sprint Goal and adapt the plan for the next day. The format is up to the Developers, so the classic "three questions" (what did I do yesterday, what will I do today, what is blocking me?) are optional.
4. Sprint Review. The Scrum Team and key stakeholders inspect the outcome of the Sprint and progress toward the Product Goal, and adapt the Product Backlog. The Guide calls it "a working session", not a presentation.
5. Sprint Retrospective. The team plans ways to increase quality and effectiveness, inspecting individuals, interactions, processes, tools and the Definition of Done. Improvements can go into the next Sprint Backlog. The Retrospective concludes the Sprint.

A full Sprint, step by step

Here is one complete Sprint from start to finish, with the artefacts flowing between the events. Gold marks what is happening at each step.

Sprint Planning in detail

Sprint Planning is where the Sprint's commitment is made, so it is worth looking at its three topics more closely. Note who answers each one: the whole team agrees why, but only the Developers decide what they can do and how. (Part VI shows the estimation and capacity numbers behind the "what".)

Timeboxes exam

A timebox is a fixed maximum length for an event: when time is up, the event ends. The Scrum Guide gives maximums only for a one-month Sprint. For shorter Sprints it says just that events are "usually shorter", so the pro-rata figures for two-week and one-week Sprints below are a convention, not Guide rules.

Cancelling a Sprint

A Sprint can be cut short in only one situation, by only one person. This is Self-test Q15 drawn out.

Artefacts, Commitments and the Definition of Done

Transparency needs something to be transparent about. Scrum's three artefacts are the things anyone can look at to see what is planned, what is in progress and what is finished. Each comes with a commitment, a goal or standard against which progress on that artefact is measured, so that "progress" always means progress toward something.

Three artefacts, three commitments exam

The pairing to remember: Product Backlog ↔ Product Goal, Sprint Backlog ↔ Sprint Goal, Increment ↔ Definition of Done.

The Definition of Done in practice

The DoD is what stops "done" from meaning "done, except for testing". It comes with a few rules, shown in the figure below.

The W05 slides call the Increment the "potentially shippable increment", meaning the sum of all Done items so far: it could be released if the PO chose to. User stories, acceptance criteria, estimation, velocity and burndown charts are all covered in Part VI.

Scrum documentation: just enough

Agile documents just enough, and the slides list what that includes in Scrum. Most of it lives with the team and changes every Sprint; the last two items exist for people outside the team.

Scrum vs XP vs Kanban

All three frameworks are agile, so the exam rarely asks "which is agile?". It asks which one fits a given situation, and that depends on what kind of thing each one is. This section lines them up so you can choose and justify.

The comparison table exam

The first row is the one to hold on to: Scrum is a management framework, XP is an engineering methodology and Kanban is a flow method. The other rows show how that difference plays out. (Velocity is the amount of work a team completes per Sprint; a burndown chart plots the work remaining; a cumulative flow diagram plots how many items are in each Kanban column over time. Part VI covers the Scrum metrics.)

The frameworks also combine well. Scrum prescribes no engineering practices, so Scrum teams often adopt XP's (pairing, TDD, CI, refactoring) inside their Sprints. And "Scrumban" puts a Kanban board, with WIP limits, inside Scrum.

Scrum Anti-Patterns and Misconceptions

Many teams say they "do Scrum" while quietly breaking its rules, and exam questions love to describe such a team and ask you to spot the problems. An anti-pattern is a common practice that looks reasonable but undermines the thing it is meant to support. Each one below is followed by its correction.

Ten ways to get Scrum wrong exam

The classic exam version describes a team with several of these at once. The figure draws the one from Self-test Q6 (§3.14); try to name all six problems before reading the list under it.

1. The Daily Scrum is the Developers' own planning event, not a status report to a PM.
2. Sprints must be fixed and one month or less; Sprints varying up to five weeks break both rules.
3. The PO must be one person, not three department heads.
4. Testing belongs in the DoD every Sprint. A testing sprint is mini-waterfall and leaves the Increments unusable.
5. Mid-Sprint additions endanger the Sprint Goal; they should go to the Product Backlog via the PO.
6. Skipping Retrospectives loses adaptation. This is "Scrum-but", and it is not Scrum.

Case Study: PayPal's Agile Transformation

Everything so far describes one Scrum Team. The lecture's PayPal case shows what happens when a whole enterprise, with thousands of people, switches to Scrum at once: why it had to, how it did it, and what it gained. It is examinable, and its best use in an answer is to map each fix back to the agile theory in this Part.

The story, step by step exam

The six drivers of slowdown

1. Detailed requirements documents were needed for annual planning. They took months to write and were often outdated before coding began.
2. Complex quarterly planning. Technology Quarterly Planning (TQP) added flexibility, but it also added complexity.
3. Domain bottlenecks. Organising into 85 domains deepened expertise, but risk, compliance and core payments were needed by nearly every project, so those domains became bottlenecks.
4. Developer context switching. Developers were split across several projects, which reduced their productivity.
5. Waterfall development. Grass-roots agile teams were forced into waterfall cycles.
6. Integration testing. Because code branches were long-lived, even tiny changes needed 6-week integration and regression tests.

Why a Big Bang, and how it was held together

Most organisations roll agile out gradually, team by team. PayPal deliberately did the opposite because its teams were highly interdependent: a gradual rollout would leave new agile teams blocked waiting on old waterfall ones. It also needed an enterprise framework for staffing, delivery and governance quickly.

Enterprise sprint cadence. Before, sprint practices and lengths varied from team to team, which made cross-team ceremonies hard. Afterwards every team ran the same two-week sprint. Short cycles avoid mini-waterfalls and keep the focus on user stories. Sprints ran Wednesday to Tuesday, so that teams in different countries could all take part in ceremonies, and sprint numbers became the shorthand for dependencies and deliveries.

Lifecycle management tool. Tracking approaches had also varied. PayPal evaluated agile tools and picked one tool for all teams, with an enterprise vendor partnership. The tool was aligned to the cadence and the product structure, so each team had its own backlog but could also see other teams' plans and track dependencies. Training and coaching were provided. Progress was monitored with a transformation dashboard tracking co-location, team size, SM/PO support and each sprint's Say/Do ratio (how much of what a team said it would deliver it actually did).

The shifts, the challenges and the results

The rollout faced real challenges. Employees had to adapt to large-scale change, and the new structures had to be communicated. Some teams had no agile experience, while others had their "own brand" of agile (for example 3-week sprints) and resisted the standard. Support came through videos, training and feedback channels. The results are in the last step of the stepper above.

Exam angle: map each fix to agile theory

Applying It to the Medic Case

The tutorials' running case asks the question every case-study exam question asks: given these facts, would Scrum work here, and how would you set it up? This section weighs the facts and builds the Scrum Team.

Would Scrum suit Medic?

The Medic Scrum Team

Self-Test: Likely Exam Questions

These fifteen questions are the guide's self-test for this topic, with its model answers (the guide's own, not official staff answers). Try each one on paper before opening it; for the longer ones, aim for the structure of the model answer rather than its exact words.