Say no more “Buts” and stop asking yourself why Scrum is not working

Say no more “Buts” and stop asking yourself why Scrum is not working

There are many reasons why Scrum is not working within your projects. Learn how to optimize it in this article and how to avoid doing this methodology only halfway.

why Scrum is not working

Just declaring that you are following Agile is not enough to be an actual Agile company. And if you are asking yourself why Scrum may not be working for your team, you must have in mind that there are different attitudes that can prevent your company from being Agile.

In Scrum, these are called “ScrumButs” and they are the reasons why teams can’t have the real results Scrum helps achieve within any project development. “Buts” are excuses that team members make to avoid following some rules and taking certain roles. They are excuses not to do Scrum properly, hence you’re not really doing Scrum at all.

Read as well: 5 keys you can’t skip on your Agile process

But which are the most common “Buts” we can commit on? Here are some symptoms or excuses that show us we can be using ScrumButs but not be complying with the methodology in the right way:

1. Not to do a Daily meeting

Symptom: “We use Scrum, but having a Daily Scrum every day is too much overhead, so we only have one per week.”

Many don’t know the benefits the Daily meeting brings to their teams, and in order to avoid this ScrumBut, it is important to understand some of them:

  • It helps teams to be in Sync with how things are going.
  • Allows making corrections during the Sprint, in the right moment.
  • Builds trust between team members and encourages personal planning.
  • It provides high visibility of progress and self-organization in your team.
  • Because it is mandatory that all team members attend the Daily meeting they can share their own points of view and solve concerns and impediments.

2. The ineffective Retrospective


Symptom: “We use Scrum, but Retrospectives are a waste of time, so we don’t do them.”

This is an important step that should not be ignored because it allows the team to evolve continuously and improve throughout the project.

Retrospective meetings include three main points for discussion:

  1. What went well during the Sprint cycle
  2. What went wrong
  3. What changes can be made to improve

It is a collaborative process because it involves all team members, and at the end of each meeting, decisions are made, thus ensuring continuous improvement. Retrospective meetings create bonding between members in an open and honest atmosphere and promote better communication among all.

3. Sprints that look like a marathon

Symptom: “We use Scrum, but we can’t build a piece of functionality in a month, so our Sprints are 6 weeks long.”

This is a typical excuse and a big reason why Scrum is not working in your projects. Most of the time, teams don’t know how to organize their work, and that is what Sprints are for. The length of a Sprint determines how quickly a Scrum Team can “inspect and adapt” to changing circumstances and learning.

With lengthy Sprints (five weeks or longer) the benefits of Scrum rapidly drop off. Particularly, risks associated with short term planning, responding to change, team development, windows of business opportunity, and error detection are increased.

4. Scrum, interrupted


Symptom: “We use Scrum, but sometimes our managers give us special tasks, so we don’t always have time to meet our definition of done.”

In this scenario, prioritizing other tasks over the forecasted ones, and managers giving extra tasks, are the culprit. A Scrum team forecasts their work in the Sprint Planning meeting, and what is forecasted is meant to be respected (it is a commitment taken by the team).  In exchange for that commitment, the rest of the organization commits to leave the team alone to focus on their work. Any interruption to any individual team member (except by the Scrum Master or Product Owner) is considered a cause for relieving the team of its commitment.

This rule of Scrum is designed to put pressure on the organization to leave the team to focus on the most valuable work. If the organization allows interruptions to the team’s work during the Sprint, then the team will not meet its forecast, and this will diminish trust between the team and its stakeholders.

To Sum Up


Scrum rules are few and simple, and they exist for a reason. If you don’t follow them thoroughly then at least you need to understand the impact they might have on achieving the results you expect.

So, if you are wondering why Scrum is not working, these are some of the most common “ScrumButs” you should avoid if you are looking to succeed. With a good understanding of the Scrum Rituals and their nature and reason they exist, ScrumButs can be easily prevented, and better results can be achieved.

Questions? Comments? Concerns? Contact us for more information. We’ll quickly get back to you with the information you need.