5 False Hopes of Scrum and How to Fix Them

Like many classic, never-ending conflicts, the debate over how development teams should organize and self-govern rages on. Currently, it almost seems as if there are more critics than fans of Scrum. The three most common complaints are:

1. The process can take center stage over the work.
2. It can be easily confused for micromanagement by another name.
3. The daily stand-up can feel like a meeting where one has to justify its existence.

In other cases, the roles of Scrum are not represented appropriately. Sometimes, the product owner wants too many things inside of a sprint or wants to change priorities mid-sprint—a Scrum master who is obsessively focused on maintaining velocity and adopting every new Scrum ceremony that they learn. After some time with the framework, a common question seems to come up: “Is it us or the methodology?”

The False Hopes of Scrum

While there are numerous dysfunctions like the ones outlined above, a simple root cause for most of them is that Scrum was not designed to resolve underlying issues within an organization by merely following the process. Failing to recognize this can place new teams in jeopardy almost as soon as they start.

False Hope #1: Scrum Makes Teams Work Faster

Scrum uses terminology that sounds to an outsider like it’s going to accelerate the process without adding additional resources. It’s easy to get bogged down in the terminology as a new team to Scrum (e.g., what’s a Scrum master? What is the difference between a product owner and a product manager? What are story points and how are they assigned?)

More troubling is that many see terms like velocity and sprints and think “speed.” However, the purpose of any Agile methodology, Scrum included, is to deliver a finished product. Eventually, as your team becomes more competent with Scrum, you will be able to deliver new functionality faster. However, speed is not necessarily the primary goal. This distinction should be articulated within your Scrum team and also when you’re building awareness within your company to support the Scrum methodology.

You are not selling speed; you’re selling completion.

False Hope #2: Strict Adherence to Scrum Will Fix Company Culture Problems

Everyone has different working styles. Some people like meetings. Others use phrases like “work hard, play hard.” It is essential to recognize that whatever working style your company values, you are accepting both its advantages and disadvantages. A company that values meetings is likely to struggle with the daily stand-up. Aggressive and speed-oriented teams are going to have issues with scope creep inside of a sprint.

It’s sometimes easy to lose sight of the big picture, particularly for recently formed teams. What matters is delivering a finished product instead of following every last bit of the process. Rather than blaming the methodology, always look for ways to refine your working style to meet your goals.

False Hope #3: Critical Contributors Can Send Their Delegates to Meetings

Once you start the methodology, it is crucial that the original team participates rather than delegates. If there’s one nearly universal complaint I see from developers, it’s that the Scrum masters and product owners were not available when needed and their delegates were not empowered. No one likes coming to a meeting expecting a decision only to be told the person who can make the decision is not available.

Delegation may be a common practice, but in Scrum, you also have to empower the participants.

False Hope #4: Daily Stand-ups Will Force Everyone to Be More Focused

The daily stand-up meeting should not be solely focused on what everyone did in the last 24 hours. It is far more important to give priority to surfacing roadblocks or new approaches to solve a problem.

Scrum requires certain roles, particularly the Scrum master, to be assertive yet not overpowering. It is important for the Scrum master to create a positive environment that leads to completed products.

False Hope #5: We Will Be Successful on the First Try

Scrum involves guesswork, deductive thinking, and making mistakes. People rarely get it right on the first try. Scrum is iterative in all respects: not just in how you reach a finished product, but also in how you govern and operate the process. Scrum is designed to have a low barrier to entry for teams to adopt, but it also requires a commitment to iterate and continually improve participation in the framework.

How to Fix a Broken Scrum Process

Scrum is resistant to the sunk cost fallacy. The iterative nature of Scrum creates opportunities to adapt or discard ineffective processes. Consider some of the following suggestions if your Scrum process is not as effective as you expected it would be.

Refine Your Expectations

Whether it’s reducing time to market, creating compelling products, or helping teams collaborate, success takes commitment and time. For new teams, a reasonable milestone to achieve is whether after each sprint you could introduce working, testable code into your production environment.

Advanced teams can measure success by their ability to build, test, and deploy on-demand. Are you able to instrument and quantify user reactions to new features? Is the broader organization ready to support the changes the team is making to the product?

Empower Your Participants

It is important to mentor team members offline in terms of how they can increase their value to the team. If they are being asked to make decisions, boost their confidence by coaching them on when and how to include other team members. Managers need to be ready to clear roadblocks and support the team when needed.

Proactively Address Issues

Scrum is not designed to give your company a makeover. If you have let issues go unaddressed, you are more than likely going to find these issues surfacing in your product development process. Scrum masters can introduce frameworks designed to create a positive way for team members to structure their feedback to reduce the feeling of conflict.

One such example is the “I wish, I wonder, What if” framework. During team discussions or retrospectives, a team member can give feedback by opening their statement with one of these three phrases. For example, they could say, “I wish stand-up meetings could put more focus on roadblocks I might need to be aware of that day.” You can also use your own opener such as “I like…”.

Another structured feedback solution that can be helpful during meetings is the Triage method from Holocracy, created by Brian Robertson and used by companies like Zappos. For example, participants build an agenda of “tensions” to discuss. Each participant describes their issue by saying “I have a tension” and then lists the people and resources they need to resolve it. By encouraging participants to directly address issues as “tensions,” Holocracy enables participants to communicate freely without creating an atmosphere of conflict.

Use Retrospectives to Solve Problems and Iterate on the Process

In many companies, the retrospective is not given proper attention. This is primarily because of the fear many have that the retrospective is a venue for old arguments, conflict, and grievance. It is vital for the team to develop ground rules that reflect the team’s values and company culture.

Just as important is the need to avoid investing in static processes. What worked once may not work forever. Many teams struggle with participant turnover. This is common in many companies as participants are reassigned to other teams, get promoted, or leave the company altogether. As the composition of the team evolves, it’s important not to remain committed that everything is iterative in Scrum. Mistakes will occur, but hopefully, they’ll be short-lived as you iterate.

Scrum Works Best When the Principals Are Present

Being on the team, you have to commit to being present and available. Product development is probably the most crucial process your company could undertake to improve its long-term growth. Therefore, it is important that the Scrum process, as the primary path to new product development, receives the attention it deserves. In many environments, the developer team often works detached from the decisions and discussions that drive the goals of the company. Scrum is different. Scrum is where decisions, direction, and development come together as a single process. It is too important of a process to send delegates or to leave out team members from the meetings that take place within the Scrum methodology.

Summary: You Can Fix a Broken Scrum Process

Because of its iterative nature, Scrum helps to safeguard the business from getting too far down the road and committed to what may end up being a bad idea or poorly implemented process. Adhering to this principle can help unwind from past mistakes and iteratively improve the Scrum process.

It is important to focus on the individuals and the team you have. Team members change. All projects are different. Strict adherence to a process doesn’t always produce the best results. What you invest in your team members outside of the process is just as important as how you conduct yourself within the process.

Scrum can be flexible. If something isn’t working, consider incorporating elements from other frameworks both within Agile and outside. Identify and adopt structured styles of communication that confrontational discussions.

Scrum is beneficial to long-term ROI by enabling teams to build complete products in response to changing client needs. Scrum is probably the best methodology to keep you from over-committing to bad ideas while giving great ideas some space to develop further.