Roll out in waves, from a pilot

One rule of the engineering standard I set for teams is that no change should happen by chance: each one is tied to a feature, goes through a merge request and can be found in the history. I hold an organisation to the same rule when I roll out a practice across several teams.

The 4S method, which I designed to anchor Craftsmanship in teams, rests on four recurring meetings, each with its own scope and rhythm:

• Smart Refresh, for sharing. Technology watch, new technologies and lessons learned, shared every month through a newsletter, a blog or a webinar.
• Skill Refresh, for tutoring. Code katas to sharpen a skill through practice and repetition, in a Randori-style Coding Dojo or in mob programming, twice a month.
• Session Refresh, for mutual help. Every week, a working session on the topics and difficulties the team meets day to day, with labs shared across teams.
• Squad Refresh, for ownership. One referent per technology on the project (pipeline, unit tests, Kafka), a role that rotates every program increment or every quarter.

Then the method has to be rolled out. The scale-out protocol works in five phases built around a Plan-Do-Check-Act loop:

1. Prioritise. Rank the projects and choose a pilot, in iterations: the first candidate is not always the right one.
2. Set the standard. Write the cross-cutting rules, with the indicators that will track and verify them. A Lean A3 puts the ambition and its KPIs on a single page.
3. Train the referents. Identify the people who will carry the standard and train them in it. They make sure it is applied, spread it within their team and keep the documentation up to date.
4. Roll out in waves. Each wave is wider than the one before, Fibonacci style, and each phase states who takes part, what it delivers and which indicators it tracks.
5. Decide. Run the roll-out over a program increment or its equivalent, track the indicators every day, involve the whole team. Then settle it: extend, adjust or stop.

Imposing a practice on every team at once is a bet. Proving it on a pilot first is a decision

The pilot is the step people want to skip, because it looks slow. It is what makes the rest fast: the standard that reaches the second wave has already been through a real project, and the referents who carry it have already applied it. The loop then takes over. Each wave is a Do, the indicators are the Check, and what the teams learn becomes the Act that shapes the next wave.

A roll-out that does not end in a decision is not a roll-out. It is drift