Scrum can cause problems and may lead to failure in some organizations. Common Scrum issues always have to do with Product Backlog and the Product Owner competency.
“Failure” is a scary word… for some people. As Scrum is gaining popularity, late adopters are validating its success. One of the common ways people are validating its success is by asking how Scrum can fail in a project. But it is also quite common that people are asking failure stories to learn from others instead of for validation purposes. Nobody wants to fail, because we have been raised in a society that viewed failure as a negative thing.
“Failure is so important. We speak about success all the time. It is the ability to resist failure or use failure that often leads to greater success. I’ve met people who don’t want to try for fear of failing.” — J.K. Rowling
The Standish Group reported that 86% of the time, waterfall projects are either failed or challenged. While on the other hand 58% of the time, agile projects are either failed or challenged. So can Scrum fail? Yes, it can fail. But despite there are more Waterfall failure stories, people are more worried about how Scrum can fail them. And perhaps Waterfall has failed people who want to prove that Scrum can fail their project.
No matter how many organizations have become so successful with Scrum, many people will continue researching for Scrum failure stories. And many people out there would probably prefer spending (or wasting) their time doing research on how Scrum can fail their project and prove that Scrum is a bad thing for their project rather than doing something more productive for their project.
Scrum is not a project management methodology
Scrum is quite different from other methodologies that provide a long-listed project success criteria checklist. Scrum is designed to fail early and often. But for organizations that view failure as something that is forbidden, failing early and often is probably going to scare them even further from Scrum. Failing is a normal thing in Scrum “management”, it is not viewed as a scary thing because failing means an opportunity to learn and improve.
In fact, failure happens a lot in IT Projects whether you deny it or not. The whole purpose of timeboxing in Scrum is to limit the project’s failures to only the length of that timebox. Very good Scrum team are those who don’t let those failures get carries forward to the next Sprint and let it becomes a bigger failure. A very good Scrum team are those who learn from their experience every Sprint and adapt when they have to.
“I have not failed. I’ve just found 10,000 ways that won’t work.” —Thomas A. Edison
Scrum is designed for continuous learning. Unlike other project management methodologies that use the Project post-mortem at the end of the project to learn from the past experience, every event in Scrum – from Sprint Planning, Daily Scrum, Sprint Review to Retrospectives – are opportunities to inspect and adapt something.
Scrum teams should have an attitude of continuous learning something from these events and not merely attending it just for the sake of satisfying the Scrum framework. Every Scrum teams should see each of these events as a valuable opportunity to learn something new and improve themselves and the product they are developing.
” The only real mistake is the one from which we learn nothing.” ― Henry Ford
Major Scrum mistake is that Product Backlog is not ready for Sprint Planning
Two common reasons how Scrum fails is because Product Backlog is not ready for Sprint Planning and software is not Done (according to the Definition of Done) at every end of the Sprint.
The good Product Owner should really care about these needs. A good Scrum team invests 10% of their Sprint timebox to refine the Product Backlog so that it is always ready for Sprint Planning. A good Scrum team also implements modern engineering practices so they can deliver a “Done” software at the end of the Sprint. But how many Scrum teams out there are doing Product Backlog refinement and implement modern engineering practices? Amazing Agile conference is coming this year related to product development and management practices, so you may need to pay attention to the tracklist.
Scrum, as an Agile invention, is not just another methodology
Scrum should not be viewed as just another methodology. Scrum should be not only be viewed as a set of mechanics to run and manage a project. Scrum should be viewed as an attitude and culture of learning because Scrum is designed for continuous learning. Learning should be a necessity when doing Scrum and failure should not be viewed as something that is scary.
If teams are not learning anything, not improving the way they work, not pivoting to the right direction when things did not go according to plan and not removing every impediment that caused them to fail in one Sprint, they’re probably going to end up with big pile of failures.
One failure in one Sprint is probably going to lead to another failure in the next Sprint. And you’ll just have to wait at one point when the project is going to fail. Failing to learn every Sprint is the major factor that will make Scrum fails. Now, what have you learned since your last Sprint?