There is another reason, which I personally find the most significant, prior to all the other examples. It's whether the team is ready for the change in project management. I faced myself and am still facing this challenge at CodePoets, and I will be happy to share my conclusions.

Master your enthusiasm, Scrum Master!

5 years ago, when I just became a Scrum Master, I knew it mainly from training and theoretical examples. I considered Agile principles beautiful, noble, and, most importantly, absolute. I thought then: "Scrum is so great that everyone loves it already or will fall in love with it at first sight!"

I firmly believed that implementing Scrum would only be a formality, and the developers would agree to all changes with a smile on their faces. Did they, though?

5 years later, I know that humans are naturally afraid of changes. Changes are inconvenient and unintuitive. They tell you to get out of your comfort zone. So when someone asks you to change your practices, you might critically look at your work or even doubt it. "It worked for 3 years, and now we have to change? Does that mean we didn’t do our job well? "

Even if you propose beneficial changes, you cannot count on the team to agree to them just like that. Implementing Scrum by force will sooner or later fail. Used to doing things the old way, the team will rebel.

It would be best if you implemented Scrum consciously, in a planned manner, preparing the entire company for it. The further your team is to agile methodologies (e.g., you've worked in Waterfall for years), the more you need to prepare it for the change.

To sum up, Scrum fails because people who implement it tend to have an idealistic approach. They believe that programmers will be willing and open to change just because they are, which is absolutely wrong.

How to convince the team to Scrum?

When I was implementing Scrum in CodePoets myself, the development teams already used this methodology, but only partially. There were Scrum dailies or retrospective meetings, but neither of our programmers had direct contact with our clients. The team was afraid of this and wasn't ready for the business to enter the project overnight. So this change had to come gradually.

The blessing of the Management Board

As it usually happens in such cases, the great change must come from the top. I knew that I needed the C-Level approval for my first Scrum project, but I didn't realize its importance.

Scrum fails when the management board doesn't actively support it and doesn't explain to the team why they want to implement it. In other words, the Board must know the answer to the question "why Scrum?", spread this argument to the entire company, and give constant support to the Scrum Master.

Even the most hardened and unfavorable development team will agree to Scrum if the Management Board presents it with the correct arguments.

Examples of good reasons to introduce Scrum:

  • We want to work closely with our customers to deliver better products
  • Competition is on our heels, and we want to verify business hypotheses faster


Examples of wrong reasons to introduce Scrum:

  • There have been no changes for a long time; it's time for a breath of fresh air
  • Scrum has worked great in a friendly company, so let's try it with us


Notably, you need to transition to Scrum gradually. You can’t limit this process to a one-time, 30-minute PowerPoint presentation. Instead, the management board must dose these arguments and remind them regularly at company meetings and 1-on-1’s.

On the other hand, as a Scrum implementer, you must take care of the management's support yourself and consciously use it in your day-to day work.

Allow one team to infect the other

Once you have the approval of the Board, it's time to move on to practice. If you work in a company with one programming team that works closely with the management board, your work will be much easier. What if there are several teams and they work separately from each other?

From my own experience, I recommend "infecting" teams with Scrum. It consists of introducing Scrum first in one unit, preferably in the one already familiar with agile methodologies.

The First Scrum Team will pave the way for the other teams. Once they get to grips with the benefits of Scrum, the other teams will start growing interest; they will ask about the new system, the tools, and the new processes.

Infecting another team with Scrum will only be a matter of time. However, remember that whatever you plant in your team's mind will spread to other groups, so plant Scrum wisely. :)

Slowly but surely

Additionally, if you start implementing Scrum from one team, it will be easier for you to work with business goals and specific Scrum tools. When you work with one team, you will find it easier to show how Scrum works, and you will get to evaluate the work results better, draw conclusions faster and implement them more precisely.

Of course, you can work with all teams simultaneously and revolutionize the entire company. It's doable but much more difficult. It requires full readiness of all units and training or implementation of several Scrum Masters at the same time.

In my experience, however, Scrum is such a significant organizational change (even concerning teams that already know it and partially use it) that it's worth implementing it gradually. You want to focus on one team, teach it Scrum by the book and, having solid Scrum foundations in the company, spread it wider.

The Scrum Revolution applied to many teams simultaneously may mean that some tools will be fully implemented in one team, while in another one, they will not. This, in turn, can create a mismatch between the teams' processes and operational standards.

Scrum fails if it's introduced too quickly to all teams at once and when individual units are not prepared and trained enough with it. This is why I suggest implementing slowly but surely.

Why does Scrum fail? Summary

  • Don't take Scrum for granted; be aware that you need to convince people to change,
  • Reach for the support of the Management Board,
  • Start with one team, especially if you can't thoroughly train all employees who will be implementing Scrum,
  • Make changes gradually,
  • Make sure you aren't making these five mistakes in your day-to-day work.