5 Reasons Why Scrum Fails and What You Can Do To Overcome Them

“Scrum” has become somewhat of a buzzword in recent times, especially in the business of software development. The concept was introduced to the world in 1995 at the OOPSLA Conference by Jeff Sutherland and Ken Schwaber although the origins of the framework are somewhat a mystery. With its emphasis on team empowerment, autonomy and short, sustainable iterations of work, Scrum helps provide teams with a refreshingly lightweight framework for the delivery of complex software products and projects.

Scrum prides itself on its simplistic and lightweight nature, yet it is estimated that almost half of all businesses fail to implement it correctly. So what is it about this seemingly out-of-the-box methodology that is proving so difficult to implement and what steps can be taken to ensure its success?

1. A Lack of Organisational Buy-in

This is, without doubt, the biggest challenge faced when attempting to implement any type of business change and Scrum is no different. It is no secret that people don’t like change and without the buy-in of your key stakeholders, your Scrum implementation is going to fail.

The Scrum process touches every area of software development, therefore each and everyone involved needs to be bought into the process — it will not succeed if only a minority are pushing it forward. Scrum introduces several techniques and terminologies that people may not be familiar with and goes against some long-standing rules of software development, which may make your colleagues and managers feel a little uneasy. This can be even more challenging when your organisation’s culture is at odds with the agile values themselves — for more information on this, check out the Agile Principles.

Solution: Before you start trying to implement Scrum within your business, make sure you are clear on the value that it will bring to your team and your organisation. If you are not clear on how it will benefit them then how do you expect others to be? Once you have got this sorted, it’s now time to go and talk to your team and stakeholders. Depending on the size of your team, I’d recommend doing this in several separate sessions. Remember you’re trying to win hearts and minds here, your aim is to inform your colleagues enough that they will want to start implementing Scrum themselves, rather than it is imposed on by management — do this and you’ll be far more likely to succeed.

One simple hack to fast-track buy-in is to tie the benefits of Scrum to some known pain-points within your team or organisation. If for example, the development team has a high staff turnover, you can explain how Scrum encompasses the Agile Principles such as working at a sustainable pace. Once the benefits become clear to your colleagues, they will start to see things your way too and before you know it there will be a whole team of you driving the Scrum implementation.

Once buy-in is achieved, your implementation is halfway there. I know that sounds crazy but it’s true. Convincing people to change processes and habits of a lifetime can be very difficult, so the more people who buy into the process, the better chance you’ll have for Scrum to succeed.

2. Trying to implement Scrum too quickly

This is one I hear about all the time. As with any organisational change, especially one that will resonate through the core of a software development process, Scrum needs to be implemented steadily, one step at a time. I’ve seen businesses try and change from the Waterfall methodology to Scrum over the course of a couple of weeks and it just doesn’t work. There are fundamental changes to teams and processes that won’t happen overnight.

Solution: Allow sufficient time to implement the Scrum methodology in your business or team. I recommend anywhere between 3 and 6 months although it does completely depend on the number of people involved. Treat the implementation as your very first Scrum project and break the task down into smaller tasks i.e. train the Product Management team how to groom the Product Backlog. Look to schedule these smaller tasks into short iterations of work (Sprints), making sure you review what has been achieved at the end of each iteration (Sprint Review). Remember, slow and steady wins the race.

Implementing Scrum at the right pace will allow colleagues time to get to grips with its concepts and different ways of working. It will also allow for discussions and trials of potential tweaks you could make to the methodology to better suit your team or organisation. Just be careful when doing this, not to take the easy route and drop fundamental parts of the methodology — such as cross-functional teams or sprint meetings.

The result will be well-informed colleagues, with the right knowledge and skills to incorporate Scrum into their daily work-lives. Implemented at a steady and sustainable pace, there should be no or little resistance from others to change the way the work and generally people will feel more confident in what they are doing.

3. Failing to Plan

We would not dream of pushing out a release, delivering a client project or upgrading some internal systems without a plan, so why do we think that implementing an entirely new development methodology within our organisation doesn’t need one? It balmy to think that this is one of the top reasons for failing Scrum implementations but it’s true — as coined by Benjamin Franklin, “Failing to plan is planning to fail”.

Solution: Any good product or project delivery should start with a vision or a goal. This helps focus your team on where they are headed and helps guide them through any challenging situations — Scrum implementation is no different. Set the goal early on and be sure to also define the metrics you are going to use to help measure whether that goal was achieved. For example, your goal could be “Fully implement Scrum throughout the organisation within 6 months.”. This outlines your goal and your metric for measuring whether you have achieved your goal.

When implementing Scrum, I use a four-step plan. First, I focus on convincing the organisation that Scrum will add value and get the teams working on my side, this is the buy-in. During this stage, I also set out the plan phases and give the teams some homework to complete — such as a Scrum test or book to read. To help people take ownership, I task different people and teams with different tasks and arrange a series of further meetings to review progress. In step two, I move onto more advanced things, such as talking about task estimation, sprint velocity and stretch tasks. In step three I talk to indirectly affected teams, such as sales and marketing. I tell them how their work-lives will be affected and what they can do to help. Finally, I talk to the customers about the changes and what this means to them, always keeping the positives in mind.

Planning the transition to Scrum is a highly individual process and one that needs a well-thought-out plan. As mentioned above, I use a 4-phase plan, which helps build Scrum up in the organisation gradually, if you contact me I would be happy to share this with you. There are many Scrum implementation guides out there, I suggest you read through a few of them and then tailor your own plan with the help of some people in your organisation. Having a good plan will help win the hearts and minds of your colleagues, encouraging them to take responsibility for their role in the process ultimately leading to a smooth and hassle-free Scrum implementation.

If you are struggling with this, I would highly recommend you seek the help of an external Scrum coach. While these can seem an expensive and unnecessary cost, I would urge you to consider it. To give the cost some perspective, calculate the cost of a wasted week of development for your team and compare that to the cost of a Scrum Coach. You’ll most likely be surprised by the result.

4. Lack of experience and skills with Agile Methods

When starting out with a Scrum implementation, it’s unlikely that everyone in your team or organisation will have the right level of experience or skills to get off to a flying start. While this itself is not a big issue, failing to address this will lead to difficulty obtaining buy-in, a whole host of bad habits forming and will more than likely result in your colleagues falling back into more comfortable (previous) ways of working. This is precisely why creating an implementation plan is so important.

Solution: The first step in any Scrum implementation should be to get a feel for the general level of experience and knowledge with the methodology. Hold a meeting where your colleagues can speak up about their shortfalls and start creating a gap-analysis. When I carry out this exercise, I like to get everyone to write their concerns/knowledge gaps on post-its and stick them onto the wall. Once you’re done, categorize these into topics, such as “Sprints Rules” or “Definition of Done”, and write them as headings or lanes on a whiteboard. Now ask everyone to write their names on post-its and stick them into the lane or column which they would like to know more about. The beauty of this technique is your team may have ‘unknown unknowns’ — meaning they didn’t realise there was something they didn’t know. Having an open workshop like this encourage knowledge sharing and you will usually get some good results. If you prefer, you can always write the headings on the board before the meeting if you are confident enough that you’ve covered everything.

If you are struggling with this, I would highly recommend you seek the help of an external Scrum coach. While these can seem expensive, think of the cost of a wasted development team for a week. Rather than you balancing this with your everyday roles and responsibilities, outsource this to a professional who will be dedicated 8 hours a day to helping you and your organisation adopt Scrum. Teams who hire in an external Scrum coach have a much higher success rate when it comes to implementing Scrum, which in turn can save money associated with slow adoption or picking up bad habits.

5. Scrum is not the right framework

There I said it. While Scrum is a great framework for software development, it isn’t right for everyone. Some businesses have been known to adopt Scrum just because it’s what everyone else in the industry is doing or because it helps them win business by saying that they are “agile”. Do not do this. Look at your product, your team and your business, then decide whether it is the right framework for you.

Scrum is a fast moving, rapidly iterating development methodology suited ideally for new or relatively new products. It’s a framework to help deliver value quickly, focusing on concepts such as the minimum viable and marketable product. Once the product-market fit has been achieved, however, we should really consider whether Scrum is the right framework for us.

Solution: Products a little later into their lifecycle tend to favour other approaches, such as Kanban or even waterfall. These methodologies also tend to work better with larger, more complex applications that have to be installed on PCs or servers. This is because the concept of a potentially shippable product at the end of each 2 or 3-week sprint is just not practical. Instead, larger and more complex work requires a more measured approach with a heavy focus on regression and stability testing.

Something that doesn’t get mentioned too much in the Scrum tutorials is its reliance on test automation. While I’m not saying it is mandatory, it’s almost impossible to regression test your entire software platform each and every sprint. It’s possible that without test automation, your software may become unstable or require a prolonged regression period before each release.

Before diving head-first into the world of Scrum, I urge you to take a step back, take a look at the product/project in front of you and ask yourself “Is Scrum really the best methodology to move this forward?”.