What is scrum, and when is it worth adopting in a small company?

Scrum is a framework for organizing the work of a small team building a product, built on fixed-length cycles called sprints, three accountabilities and five recurring events. The source is the Scrum Guide by Ken Schwaber and Jeff Sutherland, whose current edition is the 2020 one, available in Italian on the same site. That remains the official reference: in June 2025 Sutherland published, with Ralph Jocham and John Coleman, an Expansion Pack, updated in January 2026, that widens it without replacing it. The text is short and prescribes no tools, no board and no estimation technique: it describes who decides what, when the group stops to look at the work done, and what shape whatever gets delivered at the end of each cycle must have. Scrum is a framework, so it is either adopted or not, whereas agile is a set of values nobody installs: confusing the two levels is why adopting scrum has changed nothing in so many companies.

Accountabilities on paper only

There are three accountabilities. The product owner decides the order of the product backlog, and since 2020 also owns the product goal, the objective each sprint has to bring the product closer to: anyone wanting to change the backlog order can only do so by convincing them, and the Guide provides no other route. The scrum master answers for the effectiveness of the method and for removing impediments, not for delivery. The developers, who in the 2020 revision are no longer called the development team, to avoid a team inside the team, decide how the work gets done. The drift I see most often is only about names: the product owner relays priorities decided elsewhere, the scrum master is the old project manager with a new title. The names survive; the redistribution of authority that made them useful does not.

What each event is for

The sprint, fixed in length and no longer than a month, sets a horizon inside which the deadline does not move. Inside it the Scrum Guide binds one thing only, the goal: content can be clarified and renegotiated with the product owner as more is learned. Sprint planning decides why that cycle is valuable and what goes into it. The daily realigns the day among the people building the same increment, and is not a report to the boss. The review shows working software and exists to hear from the people who will use it; the retrospective is the only moment where the way of working changes, and the first to be dropped. Two artifacts follow the same logic: the product backlog is the declared order of the work, the increment the usable part. If velocity becomes the target rather than the indicator, Goodhart's law applies.

The sprint reopened halfway

A twenty-person software house runs two-week sprints for an industrial client. The product owner sits with the supplier, not with the client, so on the Tuesday of the second week a request comes in from the client contact that nobody is in a position to postpone: the sprint reopens, the review shows two half-finished features, and the retrospective becomes the meeting where the delay gets explained. After four sprints the team stops declaring a goal at all, because a goal that collapses every time stops meaning anything. The defect is not the team's discipline: it is that the authority to order the work sits on the wrong side of the contract.

When scrum is not worth it

The events carry a fixed cost, to be weighed against the coordination they produce. In a group of three people talking all day, the daily realigns nothing not already aligned, the review overlaps with the everyday conversation, and a formal backlog duplicates a list that already exists; around that number, in my experience, the ratio inverts. Nor is it worth it where work arrives as a continuous flow rather than in batches, corrective maintenance for instance: there a board with a limit on work in progress, which is Kanban, describes reality better than a planned sprint. I recommend it on one condition, that whoever sets the order of the work sits on the side that pays and not on the side that delivers.