A reusable bottom-up pattern for rolling out a new engineering practice across a large organization by running short, voluntary, time-boxed trials rather than mandating change from the top. Developed at SpareBank 1 Utvikling (a ~600-person Norwegian banking software company) together with researchers from SINTEF, the model asks teams to "just try it for three weeks" under two simple rules, then uses weekly retrospectives and research-backed observation to turn first-hand experience into lasting adoption. Over three years it spread across five product areas and 21 teams, and SINTEF published the results in the Journal of Systems and Software.
Real change comes from voluntary experiments, not mandates
The core insight is that people adopt a practice when they experience its value first-hand, not when they are told it is good. The rollout came from the bottom up — no management mandate, no formal "rollout" program — and was deliberately framed as a low-threshold, fun experiment that did not interfere with planned work. SINTEF found this hands-on framing was what drove genuine behavior change: teams kept pairing after the trial because they had felt the difference themselves, not because they agreed with it in the abstract.
The recipe is deliberately minimal
Each experiment ran for three weeks with only two requirements: book two pair-programming sessions per week in calendars, and switch driver/navigator at least every 10 minutes. Facilitators (two developers plus a SINTEF researcher) stayed in continuous dialogue, reviewed feedback after each weekly retro, and suggested small adjustments for the next week. The experiment closed with a joint retrospective across all participating teams and something social. The low cost to both organizers and participants, paired with quick visible results, is what made it repeatable.
Frequent rotation is what makes pairing actually work
A recurring failure mode was one (usually senior) developer coding while the other passively watched — which is not pairing and produces little learning. Enforcing a strict ≤10-minute driver/navigator rotation with a timer (switching physically or via git push/pull, including remote) was observed by SINTEF to sharply improve focus, flow, and shared ownership of the code. The rotation rule is the mechanism, not a detail.
Introducing the practice surfaces deeper team dysfunction
Because pairing forces close collaboration, it made pre-existing structural problems visible: reliance on individual "expert" bottlenecks, large teams (15-20 people) with no shared goals, uncertainty about what to do after a booked session, and work deemed "not suitable for pairing." The weekly retros surfaced these early and let facilitators coach on them — assigning tasks to the team rather than individuals, splitting big teams, making small changes that ship quickly, and routing expert questions to the whole team. The experiment doubles as an organizational-learning probe.
The practice is a means, not the end
Pair programming was never the goal — continuous delivery with high quality and low risk was. At this team's cadence (deploying to production multiple times per hour, no pull requests, testing in production, combined with TDD), code review effectively happens live during development, which the team argues is not feasible without pairing. SINTEF explicitly noted the experiment format is transferable to introducing practices other than pair programming, making it a general model for change in large software organizations.