There is no question about it, Scrum is a great development process, but there are some situations where it can fail. It is not Scrum’s fault. It is more about misconceptions about Scrum and what it was designed to do. After years of experience in software development, we must say… we love Scrum!
Here are some common misconceptions and situations in which Scrum may have a hard time to succeed.
The company is unwilling to accept Scrum on all levels of the organisation
Although Scrum itself is a very flexible development process, it comes with a set of rules and practices that work well together. We found that two types of companies struggle the most in accepting Scrum in all its glory. Namely, small start-ups and big corporations.
When you are building a start-up from the ground up, you are most likely very passionate about your idea. The project is your baby, and it is hard to see it getting raised by strangers. That often means that the founder can not let go and share the responsibility of the product with other employees. The founder is the Product Owner, Scrum Master, and the Scrum Team all together.
It is easy to see how this can get exhausting for the founder/company leader and how it can shift their focus from bigger issues to unimportant details.
Where corporate companies are shifting to Scrum, it is more about losing old habits and accepting that everyone has to change, not just the development team.
Corporate leaders implement Scrum as they see it as an opportunity to boost the developer’s performance. That boost in performance comes from giving back some control over development to the engineers in the Scrum Team. In Scrum, there is no role of Project Manager, Team Lead, Document Owner, etc. Often it happens that a company’s former Project Manager becomes a Product Owner where only the title changes without any real change in organizational responsibilities.
To implement Scrum in one’s company, it is crucial to clarify that the change will affect all the layers of the company and that successful transition to Scrum depends on everyone’s willingness to accept that change.
The company has a misconception about how to build cross-functional teams
A big part of the Scrum process is to make the engineers feel empowered. It means telling people what to do, not how to do it. Believing that the team will overcome any challenge given.
The term cross-functional teams describe a team that can handle any challenge. However, people often think every team member has to know everything, which is far from the truth. In fact, the diversity in skills between the team members makes the team rely on each other and grow stronger.
From the company’s perspective, it is easy to see how these misconceptions form. With so many programming languages, frameworks, team roles, etc. it is easier for the company to think about developers as universal pieces of a machine that are replaced easily.
Vacation, sick leave, maternity/paternity leave, etc. are all situations where it would be convenient to have a team member that can easily be substituted. Situations like this make it prudent to have team members with overlapping skills, but it does not mean that everyone should be able to do everything.
Forcing everyone to develop skills in all directions can make the team members feel overwhelmed. In their mind, all their misery at work started with Scrum, so they are resilient towards it and blame it as the source of all the stress at work.
The company tries to solve problems with Scrum which it was not designed for
This is mostly true for companies that are having an identity crisis, meaning that they have lost their company vision.
Scrum can make a good team better, or it can make the problems within the development process visible, but it can not solve a problem like a lack of company’s vision. It can only help the company to reach its potential, not increase it.
In times like that, implementing Scrum is a desperate move to turn things around, or as a way to shift blame from bad decisions made in the past.
It is like they say: Never drink to feel less sad, only drink to feel happier.
Requirements change faster than a sprint allows it
It is perfectly fine to change requirements as often as a project needs it, but in cases like that, Scrum may not be the best choice.
Although Scrum is an iterative development process ready to respond to requirement changes, it does not allow for changes in an ongoing sprint. Sprints can be 1-4 weeks long and if requirements change less than weekly, the team will not be able to respond to them in time.
Fortunately, there are other development processes (like Kanban) specifically designed for projects like this.
Following Scrum ceremonies too blindly
Like we said before, Scrum comes with a set of rules and practices that work well together. Still, it can happen that the company’s situation is atypical and that the team sees some Scrum ceremonies as a waste of time.
Scrum is all about “eliminating waste” and if that means getting rid of some ceremonies or even ditching some roles, then, by all means, do it!
Scrum is mostly used in companies that employ engineers, and engineers do not just accept things. They need to see the logic behind it. There are situations where a particular ceremony/role is crucial, but it is not clear to most of the company.
In situations like this, the best thing to do is to implement the bare minimum of Scrum that everyone can agree on and work from there. Let the need for other ceremonies/roles arise on its own and let the teams learn by example. That way, we keep only the useful parts of Scrum and accept Scrum more willingly.
A final word
All the points made above come from our own experience of being on both ends of the situation. Either by being on development teams who just started doing Scrum, or being advocates of Scrum helping other companies implement it.
Everything comes down to doing what works best for your company. Is that Scrum? Hard to say. We believe it is a great source of knowledge forged by years of engineering experience. If you will not implement it by the book, you can surely find a great source of inspiration in its manifesto and make something of your own.
