Why Scrum Fails (and How to Fix It) - Part 2

This article is the second in a series about agility in business. After exploring the Cargo Cult in a previous article, this article describes the ideal recipe for implementing the Scrum framework and overcoming the main obstacles.

Imagine a team of developers whose management imposes Scrum on them, hoping to solve persistent problems such as tight deadlines, constantly evolving priorities, and poor communication. Often, this transformation emerges from a collective initiative or is applied by default without the full understanding of all stakeholders.

Thus, despite using a Kanban board, organizing daily meetings, and implementing sprints, the expected results do not always materialize, and difficulties persist.

So, what really happened? How can a popular and widely recognized framework like Scrum fail to deliver the hoped-for solutions?

First, it is important to understand what Scrum is and its philosophy to better grasp its usefulness. Next, we will identify the conditions necessary for Scrum to become an effective adaptation framework capable of supporting projects in changing environments while optimizing value creation. Finally, we will address the most frequently encountered problems during implementation and the risks associated with partial or misguided application of the framework.

What is Scrum?

The first misconception to dispel: Scrum is not a rigid method that must be followed exactly like a recipe. Instead, it's a flexible framework of principles and tools that allows a team to organize and adapt according to project needs. Imagine a chef who, rather than following a rigid recipe, has a variety of ingredients and techniques and adjusts their preparations based on the available ingredients and the guests' tastes. Similarly, Scrum offers a flexible structure that encourages adaptation, innovation, and value creation without imposing a single operating mode. You have the ingredients and the main steps; now, cook as you wish!

Easy to understand, difficult to master

Scrum, born in the 1990s, is a framework designed to help teams manage complex projects where needs can change rapidly. The basic principle is to divide the work into small steps, iterations called "sprints". Each sprint results in a functional product version, or "increment," that is ready to be used or evaluated.

The idea behind Scrum is to allow the team to adjust quickly to changes and foster close collaboration. All of this is aimed at generating value with each iteration. To achieve this, it relies on three pillars: Transparency, Inspection, and Adaptation. Every element of Scrum, from roles to meetings, is designed to support these principles. All these practices and principles are described in the Scrum Guide, an official (accessible and free!) 15-page document in its latest version (November 2020).

Scrum: Agile Principles at the Heart of the Framework

To truly understand how Scrum supports the principles of Agility, let's imagine a team that needs to develop a complex mobile application. Here's how Scrum translates these principles into practice:

1. Deliver Continuous Value: The team divides its work into sprints ranging from one to four weeks. At the end of each sprint, they deliver one (or more) new feature(s) of the application. This not only allows them to show concrete results quickly but also to gather user feedback as they go and adjust course if necessary.

2. Collaboration and Communication: Every morning, the team meets for a Daily Scrum. This quick, 15-minute meeting allows everyone to report on their progress, identify obstacles, and ensure that everyone is on the same page to achieve the current Sprint Goal.

The Scrum Master acts as an Agile coach for the project ensuring, fluid communication and quick resolution of problems.

3. Adaptability and Flexibility: At the end of each sprint, the team organizes a Sprint Review to present the completed work to stakeholders. These reviews provide an opportunity to demonstrate progress and receive immediate feedback. The team then uses this feedback to readjust priorities and refine the product backlog, which is a prioritized list of all features, improvements, and fixes envisioned for the product. This process ensures that development remains aligned with the actual needs of users and customers.

After the Sprint Review, the team meets for a retrospective where they evaluate internal practices. This meeting is an opportunity to review what worked well and what could be improved. If a method or tool was ineffective, they adjust their approach for the next sprint.

The Risks of Poorly Adapted Scrum Practices

However, simply "doing Scrum" (or being in "Agile mode," which means everything and nothing at all) is not enough for it to work. Some teams fall into traps that hinder their progress. Let's go back to our team that was struggling to get the most out of Scrum.

1. The Obsession with Velocity: Some teams, clients, or managers tend to become fixated on measuring their velocity, i.e., the amount of work they accomplish during a sprint. They then focus solely on increasing this number, to the detriment of quality or the product's true added value. This excessive focus can lead to rushing tasks, neglecting testing, or minimizing user feedback. What's important is achieving the defined objectives to deliver an increment that brings real value to end users, not the number of Story Points completed.

2. A Focus on Rituals, Not Results: The team can fall into the trap of following Scrum like a cookbook, focusing solely on the rituals (meetings, sprints, boards) without understanding their purpose. These practices must always be aligned with the ultimate goal: delivering value to users. It's not uncommon to hear developers complain about Scrum having too many meetings, which can seem dispensable or redundant if they are followed without their objective being understood by everyone. If ceremonies are ineffective or irrelevant for the entire team, it might be interesting to discuss it with the Scrum Master, but especially to bring it up during the retrospective to address this point collectively!

3. An Absent Product Owner: The Product Owner plays a key role in defining priorities and ensuring that the team understands and works on the right tasks. If they are not involved enough, the team risks getting lost, working on low-priority or poorly defined features.

4. An Overly Authoritarian Scrum Master: The Scrum Master should be a facilitator, not an authoritarian manager, nor a project manager! If the team perceives them as a boss who dictates the rules, it can stifle their creativity and autonomy, two essential aspects of Agility.

5. Scrum is not always the right choice! Scrum is a relevant framework for developing complex solutions, but it's not necessarily suitable for all types of projects or contexts. For example, Scrum can be too complex and structuring for minor corrective or evolutionary maintenance projects, where needs are occasional, plannable in advance, and where the daily coordination effort imposed by Scrum does not bring significant value. Similarly, for very small teams or extremely simple projects, implementing Scrum can add a burden that does not bring real value. Before adopting Scrum, it is essential to ensure that the project truly benefits from an iterative and incremental approach and that all team members and the organization are ready to fully commit to their roles and responsibilities.

The Key: Collective Participation in Agile Adoption

For Scrum to be effective, every team member must understand and embrace the Agile philosophy. The framework's success does not depend solely on implementing tools and rituals, but rather on the commitment of each team member to collaboration, transparency, and continuous improvement.

If team members do not share this vision or are not prepared to adopt it, a project using Scrum may encounter difficulties. This does not necessarily indicate an individual problem, but rather an increased need for training and support. Solid pedagogy is essential for everyone to become an active participant in the product and the Scrum process.

Even if some people are initially reluctant to adopt the Agile and Scrum cultures, this should not call the approach into question. With sustained effort, continuous training, and leading by example, it is often possible to gradually change mindsets, even among the most reserved individuals. However, the time and resources invested in this process must be carefully considered. If the necessary commitment does not materialize within the team despite appropriate support, then alternatives better suited to the project's specificities and context will need to be considered to continue moving forward effectively.

In Conclusion: Use Scrum with Awareness

Scrum is a tool designed to navigate the complexity of modern projects, but it is not a one-size-fits-all solution. Before adopting it, it is crucial to assess whether your project and context truly would benefit from an iterative and incremental approach. Scrum is particularly effective in environments where requirements can evolve rapidly and where collaboration and adaptability are essential. However, for simpler projects or stable contexts, other approaches might be more appropriate.

Even when Scrum is appropriate for your project, blindly following the instructions to the letter is not enough. You must understand the principles underlying each practice and be ready to adapt the framework to the specific needs of the team. Furthermore, the team itself should not be the only one to accept Scrum. Stakeholders and decision-makers must also understand how it works and what its objectives are. They don't have to adopt it in their daily processes, but they must grasp the logic and support the team in its implementation.

By anticipating and preventing the risks of superficial implementation, ensuring active involvement of all key roles, and maintaining a focus on delivered value, Scrum can transform the way your team works and foster the creation of a truly relevant product to your users.