How to implement agile practices for true high performance

By Daniel Rohrhirsch, Peter Wienand, Patrick Ruthardt and Christian Wehrberger

Agile practices have been widely adopted since the early 2000s. Yet despite frameworks such as Scrum, SAFe, or LeSS being firmly established, many large transformation programs still struggle to translate agile ways of working into measurable delivery performance. This case study illustrates how, with the right execution-focused approach, agile measures can unlock substantial productivity gains.

As a strategy consultancy, we typically support complex digital transformations in a value assurance role, with a clear objective: safeguarding program success by ensuring transparency, delivery discipline, and effective execution. This includes identifying structural delivery bottlenecks early and implementing targeted measures to stabilize and accelerate execution.

In the context of a large-scale S/4HANA transformation, this approach enabled a 250% increase in developer output - demonstrating how pragmatic, well-designed agile interventions can materially improve delivery performance when applied with a strong focus on execution.

Reasons for poor performance

Output was measured in story points, with one story point representing one developer hour. Over the past three sprints, the team delivered an average of approximately 580 story points with 18 full-time employees. This equated to roughly two story points per developer per day – well below expectations. As a reference, a high-performing team would typically deliver more than 1,000 story points, or at least four story points per developer per day.

There were numerous reasons for this low performance:

Inefficient team setup: The development team consisted of 18 members but was organized as a single Scrum team. Scrum best practices recommend 5-9 members per team as larger teams make management inefficient and difficult to handle.

Lack of team orchestration: A critical role was missing – the Scrum Master, who is responsible for removing impediments, ensuring the team has the necessary inputs such as test data, and maintaining an organized backlog. Without this role, the team was essentially unmanaged, lacked support when needed, and worked with an unprioritized and poorly maintained backlog.

Code-review bottlenecks: Only one person, not allocated to the project full-time, was responsible for reviewing code quality. This created a significant bottleneck, as many completed user stories and features couldn’t be finalized due to delays in the review process.

Low maturity of agile processes: Scrum ceremonies and practices were applied inconsistently. User story refinements, for instance, were not institutionalized. Refinement is essential to ensure features are well understood and properly defined so developers fully understand what needs to be done. Skipping this step often results in poor-quality outcomes and dissatisfied stakeholders.

While reviews were held, they were used as status updates instead of demonstrating the product increment to stakeholders for feedback and acceptance.

Meanwhile, because the backlog was not properly prioritized or refined, client teams lacked clarity on when specific user stories and features would be implemented.

And instead of the Daily Scrum (a 15-minute check-in of the development team) to track progress and removing impediments, the developer team held just two meetings per week, with inconsistent attendance from developers. This led to weak accountability and poor transparency.

Our implemented measures

Roland Berger’s solutions to these issues focused on six core steps:

1. Team reorganization: We started by dividing the team into multiple Scrum teams with 5-9 members each.

2. Scrum Master for each team: Each team was appointed a Scrum Master to ensure the backlog and user stories are refined and ready for development, and that agile meetings are organized and well-prepared. Additionally, the Scrum Master was made responsible for managing any challenges and removing impediments facing their team, ensuring every developer has all the input required for progress.

3. Code review: To reduce the code review bottleneck, each Scrum team was assigned a dedicated technical lead responsible for conducting code reviews. These technical leads were coached by the expert who had performed the code reviews in the previous months.

4. Communities of practice: We set up communities of practice for the Scrum Masters and technical leads, who received coaching by one lead Scrum Master or technical lead. Dedicated guidelines and best practices were created and continuously improved for both groups.

5. Agile events: The Scrum Master was made responsible for organizing and executing all Scrum meetings, with several key elements.

• a. Refinements, also called ‘backlog refinement’ or ‘grooming,’ is an ongoing process of jointly reviewing, clarifying, and breaking down product backlog items to ensure they are well understood, appropriately detailed, and prioritized for upcoming sprints.
• b. In sprint plannings, the team defines a sprint goal and selects backlog items to deliver, creating a plan for how the work will be accomplished during the sprint.
• c. During sprint reviews, the team presents the completed work to stakeholders, gathers feedback, and collaborates on potential adjustments to the product backlog.
• d. In daily stand-ups, the development team inspects progress toward the sprint goal and plans the next 24 hours of work.

6. Dashboard: Setting up a dashboard enables the company to review performance per sprint per team, improve the planning and speed of the team, and report accurate numbers in project status meetings.

Results:

Sign up now to receive regular insights on digital transformation and value creation via e-mail.