In one line: A lightweight agile framework in which a small, self-managing team delivers a usable increment of the product every short “sprint,” then inspects the result and adapts.
Core idea
Scrum, defined by Ken Schwaber and Jeff Sutherland in The Scrum Guide [1], is built on empiricism: knowledge comes from experience, and decisions are made on what is observed. Its three pillars are transparency, inspection and adaptation. Instead of planning everything up front, the team works in short cycles of one month or less, each of which produces something real enough to learn from. It is the PDCA Cycle turned into a team rhythm.
How it works
| Element | What it is |
|---|---|
| Roles (accountabilities) | Product Owner: maximizes value and orders the backlog. Scrum Master: coaches the team and removes impediments. Developers: build the increment. |
| Events | Sprint: a fixed time box. Sprint Planning: what and how. Daily Scrum: a 15-minute coordination meeting. Sprint Review: inspect the increment with stakeholders. Sprint Retrospective: improve how the team works. |
| Artifacts | Product Backlog: an ordered list of what’s needed. Sprint Backlog: the sprint’s goal and plan. Increment: a usable step toward the product goal. Each has a commitment: the product goal, the sprint goal and the definition of done. |
The Scrum Guide also stresses five values: commitment, focus, openness, respect and courage.
In practice
Scrum came from software, but its ideas travel well. Hardware and systems teams adopt pieces of it (backlogs, short planning cycles, daily stand-ups, retrospectives), even where full sprints don’t fit long-lead hardware. The common failure is adopting the ceremonies without empiricism: daily stand-ups that recite status, and retrospectives that never change anything. The test is whether each sprint produces something inspectable and whether the team actually adapts.
Questions to ask yourself
- What did my team learn in our last cycle that changed our plan?
- Is our “definition of done” written down and shared?
- Which agile practice would help our hardware or systems work without forcing a software process onto it?
Connections
- The underlying loop: PDCA Cycle. Native domain: Software in Engineered Products.
- Team side: High-Performing Teams. Contrast with stage-gate: Product Development Process. Visibility: Obeya.
- Capabilities exercised: Realizing the Vision, Trust and Loyalty, Communicating and Advocacy.