From predictive to agile: why complex work needs 'many small corrections'
Lesson 1 covered the predictive (waterfall) lifecycle: fix the full scope and plan upfront — a good fit when both requirements and technology are certain. But software and product work is complex, and requirements keep changing; getting everything right upfront just isn't realistic.
Scrum's answer is empirical process control: use short iterations (Sprints) to deliver a small usable increment each time, inspect the feedback, then adapt the next step — turning 'one all-in bet' into 'many small corrections,' which lowers risk and the cost of rework.
That is exactly the consensus 17 software pioneers reached in the 2001 Manifesto for Agile Software Development. It establishes four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Behind the manifesto are 12 principles, for example: working software is the primary measure of progress, welcome changing requirements, deliver frequently, business people and developers work together daily, and maintain a sustainable pace.
The Scrum skeleton, part 1: three empirical pillars, three accountabilities, five timeboxed events
The official definition in the Scrum Guide (2020): 'Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.' It is founded on empiricism and lean thinking — empiricism means making decisions based on observed facts. The three pillars:
- Transparency: the process and work must be visible;
- Inspection: frequently inspect the artifacts and the progress toward the goals;
- Adaptation: as soon as a deviation is spotted, adjust the process or the product.
Scrum does not prescribe how to do the work — it only provides the framework and leaves engineering practices to the team.
A Scrum team is typically 10 or fewer people, with no sub-teams or hierarchies, jointly accountable for one product goal. The three accountabilities:
- Product Owner (PO) — accountable for maximizing the value of the product; manages and orders the Product Backlog;
- Scrum Master — accountable for establishing Scrum as defined in the Guide; a servant-style true leader who helps the team remove impediments and upholds the rules — not a taskmaster barking orders;
- Developers — accountable for delivering a usable increment every Sprint; they plan their own Sprint work and guard quality against the Definition of Done.
The five events create a regular cadence and reduce the need for extra meetings (the timeboxes below are upper limits for a one-month Sprint; shorter Sprints shorten the events accordingly):
1. The Sprint — the container for all work, fixed at one month or less; a new Sprint starts immediately after the previous one ends;
2. Sprint Planning — at most 8 hours; decides what to do this Sprint and how;
3. Daily Scrum — 15 minutes, for the developers, to align progress and adjust the day's plan;
4. Sprint Review — at most 4 hours; demonstrate the increment to stakeholders and gather feedback;
5. Sprint Retrospective — at most 3 hours; the team reflects on how to improve collaboration.
The Scrum skeleton, part 2: three artifacts with commitments, five values, three popular myths
Each artifact carries a 'commitment' to bring focus and measure progress (introduced in the 2020 edition):
- Product Backlog — the ordered list of what needs to be done; its commitment is the Product Goal: the big objective the team pursues long-term;
- Sprint Backlog — the work selected for this Sprint plus the plan; its commitment is the Sprint Goal: the single focus of this iteration;
- Increment — the usable outcome produced this Sprint; its commitment is the Definition of Done (DoD): the shared quality standard for 'done' — work below the DoD does not count as complete and cannot be released.
Events, accountabilities, and artifacts are only the skeleton. The Scrum Guide is explicit: successful use of Scrum depends on people becoming more proficient in five values — Commitment, Focus, Openness, Respect, and Courage: the team commits to its goals, focuses on the Sprint work, stays open about the work and its challenges, respects each other, and has the courage to face hard problems. When the values are absent, Scrum easily degrades into going through the motions.
1. 'Scrum = waterfall sliced into mini-waterfalls' — wrong. Every Sprint must produce a usable increment and adapt to feedback; it is not analysis/development/testing run as sequential phases inside an iteration;
2. 'The Scrum Master is the project manager / team lead' — wrong. The SM is a servant-style leader who neither assigns tasks nor decides technical solutions for the team;
3. 'The Daily Scrum is a progress report to managers' — wrong. It is 15 minutes for the developers themselves to align on the Sprint Goal and the day's plan — not a status meeting.
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
In a review meeting a colleague says: 'The Agile Manifesto says "working software over comprehensive documentation," so starting today our project writes no documentation at all.' What is the correct reading of the manifesto?
答案：He misread it — the manifesto itself states 'while there is value in the items on the right, we value the items on the left more': it is a priority ordering; documentation and the other right-hand items still have value, the left simply wins when the two conflict
'Working software over comprehensive documentation' is one of the four values of the 2001 Agile Manifesto, but the manifesto immediately adds: 'while there is value in the items on the right, we value the items on the left more' — a priority ordering, not a rejection of the right-hand side. Agile teams still write documentation, honor contracts, and make plans; the left side simply takes priority when the two conflict. Nothing in the 12 principles forbids documentation — they instead stress that working software is the primary measure of progress. (Source: Manifesto for Agile Software Development, 2001, agilemanifesto.org)
Lesson 1 covered how the predictive (waterfall) lifecycle fixes the full scope and plan upfront. Why does Scrum advocate short empirical iterations instead for complex software/product work?
答案：Because requirements for such work keep changing and getting everything right upfront is unrealistic; short iterations deliver a small usable increment each time, inspect the feedback, then adapt — turning 'one all-in bet' into 'many small corrections,' lowering risk and rework
The predictive approach suits work where both requirements and technology are certain; software/product work is complex and requirements keep changing, so calculating everything upfront is unrealistic. Scrum uses Sprints for empirical process control: each iteration delivers a small usable increment, inspects feedback, and adapts the next step — echoing the manifesto's 'responding to change over following a plan.' Note it is not 'no planning' (every Sprint has Sprint Planning), and the predictive approach remains valid in the right context. (Sources: The Scrum Guide 2020; Manifesto for Agile Software Development 2001)
Scrum is founded on empiricism — 'making decisions based on observed facts.' Which set is the three pillars of empirical process control?
答案：Transparency, Inspection, Adaptation
Per the Scrum Guide (2020), Scrum is a lightweight framework founded on empiricism and lean thinking; its three pillars are Transparency (the process and work must be visible), Inspection (frequently inspect the artifacts and progress toward the goals), and Adaptation (adjust the process or product as soon as a deviation is spotted). 'Initiating, Planning, Closing' are project lifecycle phases (see Lesson 1), 'Commitment, Focus, Courage' are three of Scrum's five values, and 'Scope, Schedule, Cost' is the triple constraint — none of them are the pillars. (Source: The Scrum Guide 2020)
During Sprint Planning, the newly appointed Scrum Master assigns every Sprint Backlog task to a specific developer and settles the technical approach for the team. According to the Scrum Guide, what is wrong here?
答案：The SM overstepped — the SM is accountable for establishing Scrum as defined in the Guide and is a servant-style leader who removes impediments and upholds the rules; the developers plan their own Sprint work, and the SM neither assigns tasks nor makes technical decisions for the team
The Scrum Master is accountable for establishing Scrum as defined in the Guide — a servant-style true leader, not a taskmaster barking orders: no assigning tasks, no making technical decisions for the team. Delivering a usable increment every Sprint is the developers' accountability — they plan their own Sprint work and guard quality against the Definition of Done. The Product Owner owns value and priorities but likewise does not tell the developers how to implement. (Source: The Scrum Guide 2020, the Scrum Team's three accountabilities)
True or False: The Scrum Master is essentially a traditional project manager with a new title — the team's task assignments and technical decisions are ultimately theirs to make.
答案：False
False. The Scrum Master is not a traditional project manager: they are accountable for establishing Scrum as defined in the Guide — a servant-style true leader whose job is helping the team remove impediments and upholding the rules — and they neither assign tasks nor make technical decisions for the team. 'The SM is the project manager / team lead' is one of the common Scrum misconceptions; the work inside a Sprint is planned and arranged by the developers themselves. (Source: The Scrum Guide 2020)
A team runs one-month Sprints. Which set of timeboxes complies with the upper limits given in the Scrum Guide?
答案：Sprint Planning at most 8 hours; Daily Scrum 15 minutes; Sprint Review at most 4 hours; Sprint Retrospective at most 3 hours
For a one-month Sprint the upper limits are: Sprint Planning at most 8 hours, Daily Scrum 15 minutes, Sprint Review at most 4 hours, Sprint Retrospective at most 3 hours; the Sprint itself is the container for all work, fixed at one month or less, and a new one starts immediately after the previous one ends. Shorter Sprints shorten these events accordingly. Fixed timeboxes exist precisely to create regularity and reduce extra meetings. (Source: The Scrum Guide 2020, Scrum Events)
The 2020 Scrum Guide pairs each of the three artifacts with a 'commitment.' Which pairing is correct?
答案：Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done
The correct pairing: the Product Backlog (the ordered list of what needs to be done) commits to the Product Goal — the big objective the team pursues long-term; the Sprint Backlog (this Sprint's selected work plus the plan) commits to the Sprint Goal — the single focus of the iteration; the Increment (this Sprint's usable outcome) commits to the Definition of Done — the shared quality standard for 'done'; work below the DoD does not count as complete and cannot be released. Commitments were introduced in the 2020 edition to bring focus and measure progress. (Sources: The Scrum Guide 2020; Scrum Guide Revisions)
True or False: The Scrum Guide states that successful use of Scrum depends on people becoming more proficient in five values — Commitment, Focus, Openness, Respect, and Courage; when these values are absent, Scrum easily degrades into going through the motions.
答案：True
True. The Scrum Guide is explicit: successful use of Scrum depends on people becoming more proficient in the five values — Commitment, Focus, Openness, Respect, and Courage. Events, accountabilities, and artifacts are only the skeleton; these five values are the soft core that makes the framework actually work — the team commits to its goals, focuses on the Sprint work, stays open about the work and its challenges, respects each other, and has the courage to face hard problems. Without them, Scrum tends to become ritual without substance. (Source: The Scrum Guide 2020, Scrum Values)
True or False: The right way to use Scrum is to 'slice the waterfall into mini-waterfalls' — run analysis → development → testing sequentially inside each Sprint and save the usable outcome for delivery in the final Sprint.
答案：False
False. 'Scrum = mini-waterfalls' is a common misconception: Scrum requires every Sprint to produce a usable increment and adapt based on feedback — not analysis/development/testing run as sequential phases inside the iteration with the results hoarded until the end. If nothing usable appears until the final Sprint, empirical process control (transparency — inspection — adaptation) loses its meaning: there is nothing real to inspect mid-course, so no 'small corrections' are possible. (Source: The Scrum Guide 2020)
True or False: The main purpose of the Daily Scrum is for the developers to report yesterday's progress, one by one, to managers and stakeholders.
答案：False
False. 'The Daily Scrum is a status meeting' is a common misconception: it is a 15-minute event for the developers themselves — to align progress toward the Sprint Goal and adjust the day's work plan — not a status report to managers or stakeholders. Demonstrating the increment to stakeholders and gathering feedback has its own dedicated event: the Sprint Review (at most 4 hours). (Source: The Scrum Guide 2020, Daily Scrum / Sprint Review)