6.2.5: Case Study- The Culture Nobody Named

HealthCare Plus

From the outside, Rachel's team looked like the model of an Agile transformation. The Scrum board was color-coded and always current, velocity climbed steadily on the burndown chart, Sprint Planning happened like clockwork every two weeks, and the retrospectives never slipped. Rachel had been the Scrum Master for a year and had done everything by the book, training the team on the ceremonies, pushing back on old waterfall habits, and fighting to protect the team's focus during Sprints. When executives asked about productivity, she showed them the velocity chart, consistent and improving slightly, and the director told her in a one-on-one that her team was a model for how Agile should work. Rachel smiled and thanked him. Something in her chest stayed tight anyway.

Marcus, the team's tester, had learned to keep his concerns to himself. Months earlier he had flagged during Sprint Planning that the acceptance criteria for a new patient notification feature were vague, and the developer assigned to it had shrugged it off, saying they'd figure it out as they went, while the Product Owner looked rushed and the Scrum Master watched the clock. He raised it again at standup, saying the AC still wasn't clear, and someone answered that they'd clarify it in development, but development started and the clarification never came. Sitting with the story, Marcus realized the edge cases had never been documented anywhere: what happened with two same-day appointments, what happened if the notification window was under 24 hours, what happened across time zones. He messaged the Product Owner and waited two days for a reply that never came, raised it again in standup only to hear Rachel say they'd sync offline about it, and they never did. He knew he could push harder, but the team had a pace now, everyone looked busy and stretched thin, and raising another problem felt like adding weight to a boat that was already taking on water. He tested what he could and hoped for the best, and told no one he was worried.

David, one of the senior developers, was carrying a quieter version of the same doubt. During estimation for the notification feature he had suggested 13 points, given the number of systems involved and the edge cases he could already see, but the team pushed back that it should be 8, and David, remembering the director holding up the team's velocity chart at a recent all-hands and praising how productive they'd become, understood the subtext well enough. High estimates made people look slow. So he agreed to 8, and once the Sprint was underway he discovered dependencies he hadn't anticipated and an API integration far messier than expected, confirming that 13 had been closer to right all along. By then the Sprint was half over, and re-estimating felt like admitting he'd gotten it wrong in front of everyone. He told himself he'd mention it at the retrospective, but when the meeting arrived, someone else raised communication issues instead, the team spent half an hour agreeing that communication needed to improve without anyone saying how, and the meeting ended before David said a word about the estimate. He never told anyone he doubted it.

Sarah, the Product Owner, felt trapped between two audiences that both wanted more than the team could give. The clinic director needed a preferences feature, finance wanted better reporting, marketing wanted analytics, and every request arrived urgent. Sarah knew the Sprint was already full, but pushing back created friction that stakeholders escalated straight to the director, who then asked why the team couldn't simply do more. So she stopped pushing back and started accepting requests she hadn't discussed with the team, quietly hoping they would somehow fit, never telling anyone that she was saying yes to things likely to break the Sprint. When the team asked her directly what the priority was, she would say everything was important, knowing even as she said it that this was the opposite of prioritizing, but not knowing how to say no without sounding incompetent. She never told anyone she felt like she was drowning.

Three weeks later the notification feature went live, and it worked, sort of. A patient with two same-day appointments got only one notification instead of two. A patient in California got a notification at 2 AM because time zones had never been handled. Several patients with appointments less than 24 hours out got no notification at all. The incident report landed on a Tuesday morning, the director called an emergency meeting, and Rachel felt her stomach drop with the specific, sinking recognition of a call she had half-expected for weeks.

The meeting opened with blame — how had this gotten through testing, why hadn't development caught it, who approved it for production — until Rachel stopped it and asked, quietly, for a blameless review instead, framing it as a question about what the system had allowed rather than who was at fault. The room went heavier, not lighter, but the honesty finally came. Marcus said the acceptance criteria had been unclear from the start, that he'd raised it twice during the Sprint, and that he hadn't felt comfortable pushing harder because everyone seemed too busy, adding quietly that he should have. David admitted the estimate had felt wrong from partway through the Sprint and that he'd stayed silent rather than look like he'd underestimated after the fact. Sarah said she'd been saying yes to requests that didn't belong in the Sprint and had been afraid that saying no would make her look weak. And Rachel, feeling something give way inside her, said she'd sensed the tension the whole time and had avoided the harder conversations, facilitating the ceremonies while never pushing on what actually mattered, assuming the team would raise concerns on their own when they hadn't. The director listened and said nothing.

What followed was an attempt to build something more durable than good intentions. Any team member could now pause a story the moment acceptance criteria felt unclear, no apology or explanation required. Blockers had to surface within one working day of being noticed, not once they became critical. Quality concerns were to be treated as risk, not complaint. Retrospectives would end with exactly one improvement action the team actually committed to measuring. Sarah built a simpler way to talk to stakeholders — this is now, this is next, this is not in the current Sprint — and practiced saying "not now" without apologizing for it. The director, for his part, stopped citing velocity in all-hands meetings and started asking Rachel about quality, flow, and risk instead.

Over the following Sprints, the surface of the team visibly changed. Daily Scrum got more honest; Marcus flagged an acceptance-criteria concern and David immediately offered to clarify it on the spot; Sarah told a stakeholder simply that a request wasn't in the current Sprint and left it there. Retrospectives produced real improvement actions, blockers cleared faster, and quality incidents dropped. But Rachel noticed something underneath the numbers that she couldn't quite name. People were more direct in meetings and somehow more guarded in the hallways. She learned David had been interviewing at a startup, and when she asked him about it directly, he said only that he wanted to explore his options. The metrics were good. The agreements were being followed. And yet a stakeholder Sarah had turned down had gone over her head to the director, who had backed her, which should have felt like a win, except that Sarah seemed more tired afterward, not less. Rachel found herself wondering whether rules about safety actually created safety, or just its appearance, and whether Marcus was raising concerns because he finally felt safe or because there was now a rule that said he should. In the break room, she overheard two team members talking. "It's different now," one said. "Better or worse?" the other asked. The first one took a long time before answering. "I don't know yet."