Moving from waterfall to Scrum: what changes for whom

An organisation that has delivered projects through phases for twenty years does not become a Scrum organisation by sending people on a course. Every habit built around the old model, from how projects are funded to how careers are described, has a counterpart that must change. The transition is easier when it is planned as a set of specific changes for specific groups.

What differs

The SBOK® Guide contrasts the two models in a table. Traditional project management emphasises detailed upfront planning, fixed scope, cost and schedule, and process-centric management with formal change control. Scrum emphasises people, iterative planning, customer-centric management, self-organisation and decentralised measurement. In traditional management, it says, the plan may succeed while the customer is not satisfied. In Scrum the focus is on delivering what satisfies requirements in small, shippable increments, with prioritisation and time-boxing in place of a fixed scope.

The GOV.UK Service Manual describes the sequence difference in plain terms. In waterfall, activities run in strict sequence and users give feedback at the end, so you have one chance to get each part right. In agile, activities run at the same time, teams start small, and the service launches when there is evidence it works. It adds that a long waterfall project can end up out of date on completion.

The Scrum Guide is the target. It asks for a small, cross-functional, self-managing team, empowered by the organisation, with a Product Owner whose decisions are respected, working in Sprints of a month or less toward a Product Goal.

What changes for whom

Project managers. Much of the work they did, planning every task, allocating people and tracking against a plan, passes to the team and the Product Owner. There is no project manager role in the Guide. Individuals find places in several ways: as Scrum Masters, if they take on facilitation and coaching, as Product Owners, if they have the business authority, as portfolio or programme coordinators, or as the person who handles governance and risk with the wider organisation. Each is a real change and not a rename. See Scrum Master vs project manager.

Business analysts. Their skill remains valuable, with the emphasis shifting from specifications written in advance to continuing conversation. See Product Owner vs business analyst.

Testers. From a phase at the end to part of the team throughout. The Definition of Done includes testing. Some will need to learn automation.

Developers. From implementing a specification to taking part in deciding how best to meet a need, and from handing over to owning quality.

Line managers. From assigning work to enabling teams: removing obstacles, building skills, supporting autonomy. This is the hardest shift. See the manager's role around a Scrum team.

Sponsors and executives. From approving a fixed plan to funding a team and steering by results. They need to attend Reviews, accept ranges in forecasts and let go of detailed control.

Finance and procurement. From project budgets and fixed-price contracts to funding teams or products over time. See fixed-price contracts and Scrum.

PMO and governance. From checking compliance with a plan to using the evidence that Scrum produces: working increments, burn charts, the Review. Governance principles for agile work stress decisions made at the right level, with teams knowing the boundaries of their authority.

A transition sequence

A big-bang change across the organisation rarely works. A phased approach reduces risk.

1. Choose a pilot. One or two teams on a product with real uncertainty, a willing sponsor and a Product Owner with authority. Avoid the most critical project and the most hopeless.
2. Train the people who will decide. The sponsor, the Product Owner and the managers around the pilot need to understand what they will be asked to do differently.
3. Set expectations. Tell everyone what will change and what will not. Be clear about the dip. See the first six Sprints.
4. Run for six to ten Sprints. Measure working software delivered, cycle time and satisfaction, not only story points.
5. Remove the obstacles the pilot finds. Release processes, approvals, environments, reporting demands.
6. Show results to the rest of the organisation. At Reviews, in numbers and in stories.
7. Expand with care. One team at a time, learning from the previous. Avoid a mandate that skips understanding. See cargo cult Scrum.
8. Adjust governance and funding. The pilots will expose where the old rules block. Change them.
9. Keep coaching. The Guide gives the Scrum Master the job of leading, training and coaching the organisation in its adoption.

A worked example

This is an illustrative insurer with a 20-year history of waterfall projects. Its typical project takes fourteen months, with six months of requirements.

It selects a pilot: a claims-tracking portal, with a Product Owner from the claims department and a team of seven. The project manager becomes the Scrum Master for the pilot, which she finds uncomfortable at first: she no longer assigns tasks. The test lead joins the team and begins to automate. The sponsor commits to attend every Review.

The first four Sprints are slow, and the sponsor's boss asks for the Gantt chart. The sponsor offers instead a forecast range and a working demo. By Sprint six, the portal is live for one claims team, four months after the start. The second release goes out in Sprint nine. Claims handlers give feedback that changes the design of the search page.

The insurer finds three obstacles: a monthly release board that gives only one slot a month, a security review that takes three weeks, and a funding rule that requires a fixed scope. It negotiates a fortnightly release slot for the pilot, a lighter security review for low-risk changes and a team-based budget for the next phase. Two more teams then start, with the pilot's team members as coaches.

What to watch for

• Renaming without changing. Project managers called Scrum Masters who still assign tasks.
• Keeping the old plan. A Gantt chart beside the Sprints.
• Reporting duplicated. Teams producing both Scrum artifacts and old reports.
• Fixed scope with Sprints. The worst of both. See mini-waterfall.
• Moving too fast. A hundred teams on day one.
• Neglecting managers. They decide whether teams can work this way.
• Losing good people who feel their role has disappeared. Talk with them early.

How to practise it

Write the three changes you expect to be hardest for people in your organisation and name who must make each one. In the simulator you take roles that exist in a Scrum project, and moving between them shows what each accountability asks.