4.2.6: Case Study- It is SCRUM, But!

Pinnacle Insurance: All the Ceremonies, None of the Agility

Pinnacle Insurance had run on waterfall for as long as anyone in the software group could remember, shipping major system updates once or twice a year and treating anything faster as reckless. By 2022, that pace had become a liability. Competitors were pushing out policy management features and claims tools on a rolling basis, and Pinnacle's executive team decided the company needed to modernize how it built software. Leadership brought in an Agile consultant, committed publicly to adopting Scrum, and moved quickly to make it real. The software team went through training, a Scrum Master was hired, and the ceremonies were locked into every calendar in the building: Sprint Planning every two weeks, Daily Scrum each morning at 9 AM, Sprint Review on Friday afternoons, and a Retrospective immediately after. Within a matter of weeks, the team looked unmistakably Agile. The engineering director told the CTO that the team was now operating under Scrum, the CTO told the CEO that Pinnacle was transforming into an Agile organization, and the consultant, having been paid and having watched the ceremonies populate the calendar, declared the adoption a success. On paper, everything was official.

Underneath that surface, the ceremonies had drifted into something else entirely. The Daily Scrum had become a status report delivered standing up, with each developer describing what they had done yesterday and what they intended to do today while the engineering manager took notes like a supervisor conducting rounds. Nobody mentioned the Sprint Goal, because nobody was tracking one in any meaningful sense; when a blocker surfaced, the manager wrote it down and promised to deal with it later, and the meeting stretched to thirty minutes with half the team mentally back at their desks. Sprint Review had become a slide presentation rather than a demonstration, with the team assembling screenshots of completed features for stakeholders who sat in a conference room, watched, and offered polite, vague feedback because there was no working product in front of them to click through or question. The Retrospective followed its own tired loop every two weeks: sticky notes about what went well and what didn't, read aloud, circling back to the same complaints about an unclear backlog, testing that always happened too late, stakeholders interrupting with urgent requests, and approvals from other departments crawling along. The team agreed, every time, that these were real problems. And every time, two weeks later, the same sticky notes reappeared in slightly different handwriting.

Three months in, the frustration had curdled into something closer to resentment. The engineering director caught the Scrum Master in a hallway one afternoon and asked her, half joking and half not, whether "this Agile thing" was actually working, since all he could see from his seat was more meetings stacked on top of the ones they'd already had. A few developers had started grumbling privately that Scrum had added overhead without changing anything that actually mattered to how the work got done, and one of them said flatly in a planning session that Agile just seemed to be giving them more meetings and the same problems as before. The Product Backlog was still a landfill of old requests, duplicate tickets, and descriptions vague enough to argue about, which meant Sprint Planning routinely ran two hours long as the team stopped mid-meeting to ask what half the items even meant. When the CTO asked the engineering director for a status update, the director didn't try to spin it; he said plainly that the team didn't feel like Scrum was helping. Quiet conversations began about whether it was time to admit the experiment had failed and go back to what they knew, and somewhere in those conversations, the Scrum Master's own contract started to feel like it was on the table.

It was around this point that the Scrum Master started to suspect the problem wasn't Scrum itself but what the team had turned it into. They were performing the ceremonies without ever having internalized why any of them existed, which meant the forms survived while the function quietly died. She sat down with the engineering manager and asked him directly what he thought the Daily Scrum was for, and he answered without much hesitation: status reporting. She told him that wasn't quite it, that the meeting existed to coordinate the team's work and surface blockers so they could adjust and stay aimed at the Sprint Goal, and that he'd been running it as something else entirely. Whether that single exchange was the actual turning point, or just the moment it became easier to name what had already been slipping for months, was hard for anyone on the team to say afterward.

What changed in the weeks that followed was less about new tools than about what the existing ones were being asked to do. The Daily Scrum shrank from thirty minutes of status updates to a much shorter conversation built around one question, whether the team was still on track to hit the Sprint Goal and what needed to shift that day, with blockers getting addressed on the spot instead of logged and forgotten. Sprint Review stopped being a slideshow; stakeholders were handed the actual product to click through, and for the first time in months they said things that sounded like real reactions instead of polite nods, complaining that a checkout flow was confusing or asking for a filter that hadn't occurred to anyone on the team. The Retrospective adopted a Start, Stop, Continue format, but the more consequential change was a self-imposed rule limiting the team to a single improvement action per Sprint, which meant backlog readiness got tackled first, testing timing came later, and each fix was small enough to actually verify rather than another item added to the pile of things everyone agreed on and nobody changed. The Product Owner began treating the backlog as something that needed maintenance rather than accumulation, clearing out stale items, breaking large ones into pieces small enough to plan around, and inviting stakeholders to prioritize based on business value instead of whoever had complained most recently.

Six sprints into this adjusted rhythm, some of the old numbers had genuinely moved. Planning sessions ran closer to ninety minutes than two hours, stakeholders were showing up to reviews on their own initiative, and the engineering director could point to steadier velocity when the CTO asked. But the team that had once been praised for its ceremony compliance was now, by some measures, doing less of what the transformation dashboard had originally rewarded, fewer boxes checked, more judgment calls, more Sprints that looked different from the ones before them. The consultant who had declared the first rollout a success was no longer in the room to declare anything about the second one, and nobody at Pinnacle had yet worked out whether what mattered was the dashboard, the ceremonies, or whatever it was that had actually changed in that hallway conversation and the quiet correction that followed it. The engineering director still wasn't entirely sure how he'd explain the difference to the CEO if he were asked.