3.2.5: Case Study- One Size Fits Nobody

Meridian Financial Group: One Agile Method for Every Team

Meridian Financial Group was one of the largest financial services companies in the country, with technology teams supporting mobile banking, payments, customer service, fraud detection, regulatory compliance, and internal operations. As digital competitors entered the market, senior executives became concerned that Meridian's technology organization was moving too slowly. Projects took months to approve, requirements changed faster than teams could deliver them, and business leaders frequently complained that technology was not responsive enough. After a three-month consulting engagement, the executive committee approved a company-wide Agile transformation. The announcement was direct: every technology team would adopt Scrum.

The rollout moved quickly. More than 600 employees attended Scrum training within the first two months. Existing project teams were reorganized into Scrum teams, project managers were encouraged to become Scrum Masters or Agile delivery leads, and business analysts were reassigned into product-focused roles. Jira boards were redesigned around product backlogs and two-week sprints. Recurring sprint planning sessions, daily standups, reviews, and retrospectives appeared across hundreds of calendars. Transformation dashboards tracked the percentage of employees trained, the number of teams conducting ceremonies, sprint completion rates, and adoption of standard Scrum terminology. At the next executive meeting, Chief Technology Officer Daniel Mercer pointed to the dashboard. "Three months ago, fewer than ten percent of our teams were working this way. Today we're above eighty percent." From the executive floor, the transformation appeared to be gaining momentum.

One of the strongest examples came from Meridian Mobile, the team responsible for the company's consumer banking application. Product manager Lena Ortiz was trying to improve features such as mobile check deposit, account alerts, and card controls. Customer expectations changed frequently, and competitors released new features every few weeks. Before the transformation, Meridian Mobile often spent months preparing detailed requirements before customers saw anything. Under the new approach, the team began delivering smaller increments, demonstrating them regularly to business stakeholders, and adjusting priorities based on feedback. "Two weeks ago we thought transaction search was our highest priority," Lena told the team during one review. "Now customer research is telling us card-freezing controls matter more." The team adjusted its backlog and continued. For Meridian Mobile, the new rhythm seemed to match the way its work changed.

Across the building, the Production Services team was having a very different experience. The group handled incidents and support requests for dozens of banking systems, and nobody could predict what would arrive on a given day. Some mornings began quietly. Others started with payment failures, password problems, security alerts, or an outage affecting thousands of customers. The team carefully planned each two-week sprint, but urgent incidents regularly displaced the work they had committed to completing. Sprint reports showed unfinished stories being carried into the next iteration, and the team's delivery metrics looked increasingly poor. During one retrospective, support manager Ravi Shah stared at the board covered with interrupted work. "We're being told to protect the sprint," he said. "But if online banking goes down at 10:00 Tuesday morning, I'm not telling customers we'll look at it in the next sprint." His Scrum Master understood the problem but worried that abandoning sprint commitments would be viewed as resistance to the transformation.

The Payments Engineering team faced another kind of pressure. Its developers maintained a high-volume platform that processed millions of transactions every day. The team had adopted sprint planning, standups, reviews, and retrospectives exactly as instructed. Their Scrum compliance scores were among the highest in the organization, yet production defects continued to increase. Emergency patches were common, automated test coverage was limited, and developers were reluctant to change older parts of the system because even small modifications sometimes produced unexpected failures. Engineering manager Maya Desai raised the issue during a transformation review. "We can plan work every two weeks," she said, "but planning isn't what keeps me awake at night. I'm worried about what happens after we release." Several developers wanted more time for automated testing, continuous integration, refactoring, and improving the development pipeline. Product leaders, however, worried that allocating too much capacity to engineering improvements would slow delivery of promised features.

The Horizon Compliance Program faced yet another challenge. Horizon was a major regulatory initiative involving seven technology teams, four business units, legal counsel, risk management, cybersecurity, and an external deadline that Meridian could not move. Each delivery team ran its own Scrum process, but dependencies crossed team boundaries constantly. One team could not complete an interface until another team changed a data service. Security reviews needed to occur before several components could move into testing. Decisions from regulators sometimes affected multiple backlogs at once. Program director Claire Bennett found herself attending seven separate sprint reviews and trying to reconstruct the overall program status from individual Jira boards. "Every team tells me their sprint is green," she told Daniel during a steering committee meeting. "But I still can't tell you whether Horizon will be ready for the regulatory deadline." Daniel responded, "The teams are supposed to be empowered. I don't want us rebuilding the old project bureaucracy on top of Scrum." Claire agreed with the goal, but she still needed a reliable way to coordinate dependencies and make program-level decisions.

Six months into the transformation, the differences among teams were becoming harder to ignore. Meridian Mobile was delivering frequently and receiving positive stakeholder feedback. Production Services was carrying unfinished work from sprint to sprint while responding successfully to hundreds of unpredictable incidents. Payments Engineering completed most of its planned stories but continued to experience quality problems. Horizon's individual teams appeared productive, yet program leaders remained concerned about coordination across the seven groups. Transformation consultants argued that the organization simply needed more time and greater discipline. "Scrum works when teams follow it consistently," one consultant explained. Some managers agreed, believing that allowing teams to select different approaches would create confusion and make organizational performance difficult to compare. Others questioned whether identical processes made sense for work that differed so dramatically.

The disagreement reached a turning point during Meridian's quarterly technology leadership meeting. Daniel displayed four dashboards on the screen, each describing teams that were supposedly following the same operating model but experiencing very different problems. One executive proposed another round of Scrum coaching. Another suggested allowing teams to modify their practices based on the type of work they performed. The head of risk warned that too much flexibility could reduce governance and make audits more difficult. Lena argued that teams should have room to adapt. Ravi wanted to stop measuring his support organization by sprint completion. Maya wanted engineering quality to receive as much attention as ceremony compliance. Claire needed a way to coordinate work across teams without recreating layers of unnecessary approval. Daniel looked around the room. "We started this transformation because we wanted teams to become more adaptable," he said. "Now we have to decide how much adaptation we're willing to allow."