A
AiTechWorlds
AiTechWorlds
In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published a paper in the Harvard Business Review titled "The New New Product Development Game." They had studied how companies like Toyota, Honda, Canon, and 3M built breakthrough products — and the pattern was clear.
Traditional product development worked like a relay race: one team hands a baton to the next team, which hands it to the next. Marketing finishes, then hands off to engineering, which finishes, then hands off to manufacturing. Sequential, clean, predictable — and fatally slow in fast-moving markets.
The Japanese companies were running rugby: a small, cross-functional team carries the ball together from one end of the field to the other, adapting in real time, overlapping phases, relying on collective intelligence. Takeuchi and Nonaka called it "holistic" or "sashimi" development.
Ken Schwaber and Jeff Sutherland read that paper. In 1995, they formally defined Scrum — and stole the rugby metaphor for its name.
Scrum is the most widely adopted Agile framework. The 2023 State of Agile Report found that 87% of Agile teams use Scrum or a Scrum hybrid.
| Role | Responsibility |
|---|---|
| Product Owner | Owns the product vision; manages and prioritises the Product Backlog; represents stakeholder interests; accepts or rejects completed work |
| Scrum Master | Servant-leader; removes impediments; protects the team from distractions; coaches Scrum practices; does not manage the team |
| Development Team | Self-organising, cross-functional team of 3–9 people; owns the how of building; collectively responsible for the Sprint Goal |
The Product Owner decides what to build. The Development Team decides how to build it. The Scrum Master ensures the process works. These boundaries matter — a Scrum Master who tells developers how to code is doing it wrong.
Sprint Planning (max 4 hours for a 2-week sprint): Team selects items from the Product Backlog, defines a Sprint Goal, and commits to a Sprint Backlog.
Daily Scrum (15 minutes, same time and place): Three questions: What did I do yesterday? What will I do today? Is anything blocking me? This is not a status report to a manager — it is a team synchronisation.
Sprint Review: The team demos working software to stakeholders. Feedback goes into the Product Backlog. Not a formal presentation — a conversation.
Retrospective: The team reflects on how they work, not what they built. Common format: What went well? What could be improved? What will we do differently next sprint?
The Definition of Done (DoD) is a shared agreement on what "complete" means. An example DoD:
Without a DoD, "done" means "the developer thinks it probably works."
Velocity is the number of story points completed per sprint, averaged over recent sprints. It is a planning tool, not a performance metric. Using velocity to compare teams or evaluate individuals corrupts it — teams inflate estimates to look productive.
Kanban originated in Toyota's manufacturing plants in the 1950s — physical cards signalled when a workstation needed more parts. David Anderson adapted it for software in 2007.
The four core principles:
The six core practices:
Counterintuitive but proven: doing fewer things simultaneously gets more things done faster.
When a developer has 7 tasks "in progress," they context-switch constantly. Each switch costs 20–30 minutes of ramp-up time. Work items sit in queues waiting. Bugs discovered late cost more to fix.
When WIP is limited to 2 items, the developer finishes one before starting another. Cycle time drops. Quality improves. Throughput rises.
| Framework | Best For | Iteration | Roles | Ceremony Overhead | Change Handling |
|---|---|---|---|---|---|
| Scrum | Product development, new features, known batches of work | Fixed sprints (1–4 weeks) | PO, SM, Dev Team | High (planning, review, retro) | Next sprint — not mid-sprint |
| Kanban | Operational work, support queues, maintenance, continuous delivery | Continuous flow | No prescribed roles | Low (optional meetings) | Anytime — add card to board |
A common pattern: Scrumban — Scrum's structure for planning, Kanban's visualisation and WIP limits for day-to-day flow.
In Agile, requirements are expressed as User Stories — short, user-centred descriptions of a desired capability.
Format:
As a [type of user], I want to [perform some action] so that [I achieve some goal].
Example (Spotify):
As a premium subscriber, I want to download playlists for offline listening so that I can hear music when I have no internet connection.
Good user stories satisfy INVEST:
| Letter | Criterion | Meaning |
|---|---|---|
| I | Independent | Can be developed and delivered separately |
| N | Negotiable | Not a contract — details can be discussed |
| V | Valuable | Delivers value to an end user or customer |
| E | Estimable | Team can estimate effort reasonably |
| S | Small | Fits in one sprint |
| T | Testable | Clear acceptance criteria exist |
Teams estimate story size in story points — abstract units representing effort, complexity, and uncertainty together. The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34...) is standard because it forces teams to acknowledge that large items are uncertain. You cannot meaningfully distinguish a 14-point story from a 15-point story; the Fibonacci gap forces you to choose 13 or 21, prompting a conversation about why.
Planning Poker: Each team member secretly selects a card representing their estimate. All cards revealed simultaneously. Large discrepancies trigger discussion — usually the outliers have spotted something others missed.
When a single Scrum team delivers software for a team of 9, Scrum is straightforward. When 1,000 engineers across 80 teams need to coordinate on a single platform — as at companies like Amazon, Apple, or government agencies — Scrum alone is insufficient.
The Scaled Agile Framework (SAFe) organises large organisations into:
SAFe introduces the Program Increment (PI) — a planning event every 10 weeks where all teams align on what they will deliver together.
Spotify famously published its engineering model in 2012, influencing thousands of companies. Key structures:
Spotify's insight: autonomy scales better than process. Squads own their domain end-to-end. Coordination happens through culture and shared practices, not hierarchy.
Get this course's notes on Telegram!
Free cheat sheets, summaries & practice exercises