Scrum

Scrum is agile's most widely installed operating system: fixed-length work cycles, a prioritised backlog, defined roles, and a set of ceremonies that turn software delivery into a rhythmic, inspectable process. If your engineers 'do agile', this is almost certainly the shape of it — and its artefacts are your best window into actual progress.

What It Is

Scrum organises work into sprints — fixed cycles, typically two weeks — in which a cross-functional team builds a selected set of items to a state of 'done'. Its structure: the Product Owner (owns priorities, maintains the backlog), the Scrum Master (owns the process, removes impediments), and the development team. Its ceremonies: sprint planning (select the work), daily standup (synchronise, surface blockers), sprint review (demonstrate working software to stakeholders), and retrospective (improve the process itself). The artefacts — product backlog, sprint backlog, increment — are meant to be transparent and inspectable at any time.

Why It Matters to You

Scrum gives executives a real-time instrument panel, which is why it spread beyond software. Velocity (work completed per sprint) makes delivery rate visible; the sprint review replaces the quarterly death-by-PowerPoint with a demonstration of actual working software; the retrospective institutionalises course correction. Two cautions. Velocity is a planning tool internal to the team, not a productivity KPI — measuring teams by it corrupts the estimates (the observer effect, industrialised). And Scrum's cadence can create an illusion of progress: features demonstrated but never shipped, sprints completed on a product nobody uses. The executive question that cuts through: when did users last touch this?

When You'll Meet It

In any organisation running agile delivery. Attend sprint reviews rather than requesting status decks — and if reviews demonstrate slides instead of software, you have learned something important.