July 14, 2020


News for Agilists

Why companies achieve mediocre results by modifying Scrum

Assuming Scrum doesn’t work without even trying is the same as expecting to win on the lottery without buying a ticket.

Let’s take a look at the Scrum Guide. I put the essential parts in bold:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:


Simple to understand

Difficult to master

The Scrum Guide

The Scrum Guide says Scrum can address complex and adaptive problems while delivering high value. Despite being simple to understand, it is complex to master. However, to achieve the maximum from Scrum, companies need to implement the framework correctly. Otherwise, the results will be poor.

Many companies give up on implementing Scrum “by the book” before even trying, so they take the dangerous shortcut and modify it to their world. Scrum mutations lead to multiple misunderstandings. Once companies don’t live the Scrum pillars, inspection, adaption, and transparency, it is not possible to thrive anymore. Therefore, don’t expect a great outcome.

What should you expect to experience once Scrum is transformed into a diluted version?

  • Constant conflicts
  • Frequent misalignments
  • Poor performance
  • Low business value return
  • Poor results

Some “changes” in Scrum are frequent, yet, they ensure the results are far from desired. Let’s talk about them.

Scrum is simple, so we don’t need a babysitter, we can do it ourselves.”

I’ve heard this sentence more often than I’d like to. I worked in many teams without a Scrum Master. Therefore, I played two roles; Scrum Master and Product Owner. For sure, the results were sub-optimal.

The Scrum Master is not a babysitter. Also, the Scrum Master is not only helpful inside the Team. This role is responsible for promoting the Scrum outside the Team. The Scrum Master helps every one to get the best of Scrum. Let’s look at what the Scrum Guide says. In bold, the most critical aspects.

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Scrum Guide

Photo by Shane Rounce on Unsplash

Every great Team I know had an amazing coach, who helped them to overcome any challenges the Team faced. In sports, for example, the best teams had great coaches. Chicago Bulls had Phil Jackson during the golden era. Barcelona won 14 trophies in four seasons. Pep Guardiola was the coach. Without a great coach, the Team will be no more than ordinary.

Why do companies decide to work without a Scrum Master? The reasons vary a lot, some companies want to save little money, other companies have no management support to implement Scrum properly, and many companies do not understand what the benefits the Scrum Master bring.

The comfort zone is too comfortable to leave and try something new. However, such a fear, holds the Team from reaching a high-performance level.

In a scenario without the Scrum Master, we may see:

  • Stakeholders don’t understand Scrum: stakeholders complain everything takes too long, they don’t understand why the Team cannot deliver their feature.
  • Constant interruptions: stakeholders interrupt the Development Team; they put pressure to get their feature done.
  • Teams don’t get better Sprint by Sprint: the Scrum Team lives in a vicious circle, where they deliver features, fix bugs, increase technical debt. However, they don’t inspect and adapt to become better.

In a scenario such this one, I would ask sincerely:

If we do believe we are good enough as a team, why do we have some many complaints?

We can’t define a goal. We have many priorities.”

During my first experience with Scrum, I couldn’t understand where we were heading to, I felt we were doing everything, but reaching nothing. I needed to understand better, so I had a conversation with the Business Director.

David: “What do we want to achieve as a company?”

Director: “That’s a good question. We have many goals to achieve. Once we reach them, we will have a terrific competitive advantage.”

David: “Great! I’m curious to understand which goal will bring us the biggest business value. Then we could focus on it.”

Director: “Well. We have around 50 projects prioritized. All of them are important for us. We cannot focus on a single project. We need to deliver all of them.”

At this point, I understood why our Sprints never had a goal. The hard truth, we thought it was Scrum, but in reality, it was anything but Scrum. Unfortunately, we were only a group of people working in different directions. We barely collaborated. Therefore, our results were mediocre, maximizing the business value was just a dream.

“When you have too many top priorities, you effectively have no top priorities.” Stephen Covey

Photo by Ameer Basheer on Unsplash

In a scenario without the Sprint Goals, we may see:

  • Groups of people instead of teams: different directions give no opportunities to collaborate
  • Feature factory: the Team delivers to please stakeholders instead of maximizing the value
  • Scope change is the reality: once the Sprint Goal is nonexistent, everything can be part o the Sprint, so Scope changes and abrupt directions change more often than ever

The Sprint Goal is our lighthouse; it leads us in a single direction; it fosters collaboration. By not having a Sprint Goal, we become a group of people working together in different directions, which is not a team, if everyone is following a different path, there won’t be many chances to collaborate.

A Sprint Goal serves to promote self-organisation and creativity. It establishes the ‘why’ so the Development Team can work out the ‘how’. Therefore, a great goal could be like an open question that the Development Team aims to answer with the next increment.

Sjoerd Nijland, The Sprint Goal

We don’t have time for a Sprint Review, let’s cancel it and focus on finishing the Sprint.” or “We don’t have anything to show today, let’s cancel the Sprint Review, we can present something next time.”

I’ve experienced such scenarios a couple of times. Why does it happen? Unfortunately, many times the Sprint Review is far beyond useful.

What does the Scrum Guide say about the Sprint Review?

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

The Scrum Guide

The five common reasons to fail to achieve the Sprint Review’s goal:

  1. Product Owner presents: sometimes, the Product Owner takes the spotlight and runs the show. This behavior removes the chance from Team to present their achievements. Stakeholders may see the Product Owner as the Dev Team’s manager.
  2. Stakeholders do not engage: many times, stakeholders neither collaborate nor give feedback during the Sprint Review. This situation is a typical case, once the increment does not bring value to them.
  3. Sprint without a Sprint Goal: without a goal, feature-factory may be the output. Pointless features or small improvements come out of the factory, which pleases no one. Therefore, nobody engages.
  4. Status Report: suddenly, someone opens Jira and asks questions about the progress, or someone opens some magic Excel file to start the interrogation. Status Report is not Sprint Review, and this approach is not Scrum.
  5. Formal presentation: the Team prepares a presentation and runs the slides. Forget about it. The audience wants to see real working software.
Photo by Jud Mackrill on Unsplash

We want to finish the Sprint. We have no time for the Retrospective today.”

Many teams search for excuses to avoid the Sprint Retrospective. But why? Because many retrospectives are boring, the Scrum Team leaves the room not better than they entered. Therefore, the Team prefers to skip this event.

Should the Sprint Retrospective be boring? Shouldn’t we use this moment to be transparent, inspect and adapt? Shouldn’t we define actions to help us to become a better team?

The Retrospective is a great event, which allows us indeed to identify points to improve. Let’s have a look at the Scrum Guide once again. In bold, we can get the most relevant part.

The purpose of the Sprint Retrospective is to:

Inspect how the last Sprint went with regards to people, relationships, process, and tools;

Identify and order the major items that went well and potential improvements; and,

Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards

The Scrum Guide

The Sprint Retrospective can be meaningful. Once the members feel they have the space to speak up, flaws in the process become visible, improvements opportunities become actions for the next Sprint. The Scrum Team evolves into a better version of themselves.

What happens once the Scrum Teams decide to skip the Sprint Retrospective:

  • Problems grow: if the team members don’t put the problems on the table, no discussion will happen. Therefore, small problems may become significant drawbacks for the Team.
  • The Team doesn’t evolve: without having a moment to stop and reflect on the last Sprint, the Scrum Team misses a vital chance to inspect and adapt.
  • Lack of transparency: once the Scrum Team doesn’t have a space to be open and share the different perspectives from the last Sprint. Once the Sprint Retrospective doesn’t happen because the Team needs to finish something, the message is clear. We cannot fail. Therefore, the Team becomes more conservative, and trust may diminish as well.

Be careful with changing the Scrum framework. At best, it will become a sub-optimal version. By modifying the core of Scrum, you cannot expect more than ordinary results.

  • The Scrum Master role is not optional, before calling it a babysitter, understand what the Scrum Master can do for the Team and the company.
  • Without a Sprint Goal, at best, you have a group of motivated people working together. But, the group of people will not become a team since they have no shared goal and no chance to collaborate.
  • Sprint Review is not a status report moment. Instead, it is a moment to inspect the outcome and get valuable feedback from the stakeholders. Without collaboration, expect for vast misunderstandings.
  • The Sprint Retrospective is mandatory, don’t consider removing it. Otherwise, the Team misses the chance of becoming a better version of themselves.

Do you want to write for Serious Scrum or seriously discuss Scrum?

Source link