8.2.6: Case Study- The Transformation That Started with Tools Instead of Mindset

Commonwealth Insurance: The Mandate From Above

It started with an email from the CFO, subject line "Agile Transformation Initiative," announcing that the company was becoming an Agile organization: a consultant firm had been hired, a management tool had been purchased, and every team, without exception, would adopt Scrum, run two-week Sprints, and track velocity. The email was copied from the C-suite down to individual contributors. Michael, a middle manager in claims processing, read it with genuine confusion since he'd never heard of Scrum or velocity before, but the plan sounded simple enough on paper: new tool, new structure, new process, complete by the end of Q2. The consultant firm arrived with glossy decks, trained everyone on Product Owners, Scrum Masters, Sprints, and Daily Scrums, and stood up dashboards and boards for every team. Within two weeks every team had a Scrum board, within three every team had run a Sprint Planning session, and within a month the company had officially declared its Agile transformation launched. Michael felt genuinely proud. It looked like modernization.

Something was off from the very first Daily Scrum. The team gathered on a Monday morning, and Claire, the Scrum Master, asked the developers to talk about progress toward the Sprint Goal. One developer mentioned he was working on the claims batch process, and Michael, standing at the back of the room, asked when it would be done. Claire tried to redirect, saying the point was to discuss blockers and adapt the plan, but Michael was the manager, and when the manager asked a direct question, people answered it: end of week, probably. The meeting turned into a status report, person by person, with Michael nodding and taking notes for twenty-five minutes while no one mentioned the Sprint Goal or asked for help. Afterward Claire pulled him aside and told him plainly that the Daily Scrum wasn't supposed to be a status report to the manager. Michael, confused, said he needed to know what the team was doing. Claire told him that was what one-on-ones were for, that the Daily Scrum existed for the team to coordinate with each other. He nodded. The next day, nothing changed.

Stakeholders, meanwhile, were using the new system in ways nobody had planned for. The claims director would call Michael directly to demand something urgent, and Michael would go looking for it in the backlog only to find it had never been through refinement, never estimated, never touched by the Product Owner. He'd ask Tom, the Product Owner, about it, and Tom would say he didn't know anything about it, that it hadn't come through him, to which Michael would reply that the director wanted it done this Sprint regardless. Tom, frustrated, pointed out that if everything was urgent, nothing was, but the work went into the Sprint anyway, without clear acceptance criteria, mentioned in Daily Scrum but never properly logged. It happened three times the first month and every week by the second. Tom started to feel like a figurehead, the backlog he'd built quietly bypassed while work flowed around the system instead of through it. He said so at a retrospective, that he had the title of Product Owner but no actual authority, and a developer agreed that they were getting work pulled from five different directions. Michael said that was just how it had always been, stakeholders had needs, and Claire said quietly that wasn't how Scrum was supposed to work. Michael looked at the dashboard on the screen, velocity tracked, Sprints running, and told the room the system was working, the tool was working, they were following the framework. The team didn't feel like they were following anything new. It felt like the old system wearing new words.

Three months in, a developer named Jordan finally said what everyone had been thinking. Asked in a retrospective what was going well, she paused and said nothing was working, that they had a new tool, new ceremonies, new titles, and an identical system underneath all of it. They had Daily Scrums, but Michael still controlled the work. They had a Product Owner, but stakeholders bypassed him routinely. They had a backlog, but urgent work still arrived from five directions at once. They tracked velocity, but no one cared about quality, and they were still locking in fixed scope three months out because Finance required it. Tom nodded along, repeating that he had no real authority, that work bypassed him, that he was just managing a backlog that didn't matter. Michael, defensive, said they were following the framework exactly as the consultant had instructed. Jordan told him they were doing the rituals, not being Agile, that they'd bought a tool and swapped some words but changed nothing underneath. The retrospective ended awkwardly, and Michael left feeling like he'd failed at something he didn't fully understand.

The transformation office brought in an outside coach named Elena to assess what was actually happening. She spent two weeks observing teams and interviewing people, and the report she produced was unflattering: teams carried too much work in progress, Product Owners had no real authority, middle managers like Michael were unsure what their new role even was, governance still required late approvals from compliance and security, output was still what got measured instead of outcomes, technical debt was slowing everyone down, compliance partners were pulled in far too late, and leadership wanted adaptability while still demanding fixed-scope commitments a year out. Most damning of all, teams didn't feel safe raising risk. When she presented it, the CFO asked whether the transformation simply hadn't worked. Elena told him it hadn't started: they'd installed a tool and changed some words, but the system underneath, still command and control, still demanding fixed commitments, still measuring output, hadn't moved at all, and Agile couldn't be bolted onto that. When the VP of Operations asked what to do instead, Elena said the company had to decide what it actually wanted, real Agility or the appearance of it. The room went quiet.

Leadership chose, at least provisionally, to actually change something. They started by clarifying the purpose itself, not "install Scrum" but reduce the time it took to deliver value, improve quality, and surface risk earlier. They built a guiding coalition of executives, middle managers, Product Owners, Scrum Masters, engineers, compliance partners, finance people, and team representatives, not just the transformation office. They picked two pilot value streams instead of trying to convert the whole company at once, one in claims processing and one on the customer portal, real teams doing real work. Michael was pulled into the claims coalition and coached into a different role entirely, no longer assigning work but removing barriers and supporting the team, which felt genuinely strange after a career spent telling people what to do. Tom was given clear decision rights: stakeholders could offer input, but priorities had to move through the backlog, and Tom could say no. When the claims director tried calling Michael directly again, Michael told him it had to go through Tom and the backlog, and though the director was frustrated, the system held. Compliance and security partners started joining refinement on high-risk items instead of waiting for code review, which meant work that would once have bounced back for rework now had buy-in before development even began. The Definition of Done was tightened to build in audit evidence and automated security checks, closing off the late surprises that used to derail Sprints. Michael stopped asking about velocity in status meetings and started asking about lead time instead, how long work actually took from request to deployment, where the bottlenecks sat, what the team's quality metrics looked like.

The pace of change was slower than the original rollout, and the consultant firm, having promised rapid transformation, wasn't happy about it; Elena was pushing for something deliberate enough to actually stick. But the claims pilot cut lead time from eight weeks to three by limiting work in progress and pulling compliance in earlier, and bugs dropped as Tom's prioritization gave the work a clear line to follow. The customer portal team improved quality by folding automated checks into the Definition of Done, and the team started to feel like the tool served them instead of the other way around. Michael found himself asking different questions of his team, not who was behind on tasks but what was slowing them down and how he could help. Daily Scrums got shorter and more useful, built around blockers Michael could actually clear, and the meeting stopped feeling like a report card. It was messier than the old rollout and required constant thinking rather than simply following a script, but it felt like something real.

Six months into the pilot, Elena presented results to the board: lead time down, quality up, velocity stable but lower than before, mostly because the team was finally being honest about what it could actually get done in a Sprint. The CFO asked if the transformation was working. Elena said the pilots were working, but the real question now was whether the rest of the organization could change at all, since the pilot teams succeeded because they had a Product Owner with real authority, clear governance, and leadership backing, while the rest of the company still ran on the old system: fixed-scope commitments, compliance reviews tacked on at the end, managers still measured by output. Scale the pilot without changing that, she said, and those systems would fight it. The CFO, uncomfortable, asked if she was saying they had to change everything. Elena told him he had to choose, pilots that worked beautifully in isolation, or a real transformation of the whole organization, but not both. The room went silent. Michael, sitting at the back, waited to hear which one the company would pick, and found he already suspected the answer.