Top 5 Reasons Why Scrum Fails and What You Can Do About It
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. 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 organisation. If you are not clear on the value it will bring then how can you expect others to be? Once you are clear on the “why?”, then it’s time to go and convince 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 convince your colleagues enough so that they will want to start implementing Scrum themselves, rather than it being simply imposed on them — do this and you’ll be far more likely to succeed.
“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”
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 and before you know it, you will have the whole team 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 or delivering a client project without a plan, so why do we think that implementing an entirely new development methodology doesn’t need one? It crazy 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.
“Any good product or project delivery should start with a vision or a goal. Scrum is no different.”
When implementing Scrum, I use a four-phase 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 goals. In step three I talk to indirectly affected teams, such as sales and marketing. I tell them how Scrum works and what changes they should expect, such as more regular releases and more opportunities for feedback. 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. This plan needs to be rigid enough to give your team confidence and direction but flexible enough to change given feedback along the way. As mentioned above, I use a 4-phase plan, which helps build Scrum up in the organisation gradually.
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 urge you to calculate the cost of a wasted week of development and compare that to the cost of a Scrum Coach. You’ll most likely be surprised by the result. 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.
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 (after setting a vision) 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, categorise 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.
Once you have collated the results of this session, each of the knowledge gaps will need to be addressed. If you are lucky enough to already have the knowledge in-house, then ask these people to lead some coaching sessions and make these open to all the team. If there isn’t sufficient knowledge in-house to address the identified gaps, then think about hiring in a professional or look up some Scrum courses online. There are plenty of free resources out there if you are on a tight budget.
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.
“While Scrum is a great framework for software development, it isn’t right for everyone.”
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?”.