Why Scrum Fails: The 2 Main Reasons
Scrum fails far too often. Why? For two main reasons:
- Scrum Fails Because It’s Applied Incorrectly
- Scrum Fails Because It’s Not Enough
Scrum Is For Every Project
Do you think I’m anti-Scrum or anti-Agile? I adore Scrum! It’s the best Agile approach on the planet.
Every project in every industry should be a Scrum project. Even fixed bid, multi-million dollar, civil engineering projects should be run as Scrum projects.
Is that enough Scrum love for you? Too much for some of you.
Scrum is a simple yet incredibly powerful set of principles and practices that helps teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change.The Scrum Alliance
#1: Scrum Fails Because It’s Applied Incorrectly
Many people attempt to apply bits and pieces of Scrum, without applying all of it, and without understanding the underlying Agile and Scrum principles.
Keep the Scrum Board Simple
Lots of people have a Scrum board, but don’t understand its purpose. They overcomplicate it by building in their team’s detailed workflow processes. The board becomes too complex to maintain without specialized tools. And then you lose the board’s main benefit of being a simple way to communicate what’s going on to both technical and non-technical people.
The Scrum board needs to be something that any stakeholder can walk by and see at a glance what is going on. It shouldn’t require stakeholders to learn a complex workflow, or to learn different columns for different projects.
The Scrum board should only have 3 columns: To Do, Doing, and Done. I know it’s tempting to add other columns “for clarity” such as a Testing/QA column. Don’t do it. You’re a team. Keep it in the Doing column while you’re testing it. Change who it’s assigned to, but keep it in the Doing column.
What about a column for Releases? That belongs on a release schedule, not a Scrum board. Keep the Scrum board focused on the current sprint. If each sprint ends with a release, then you don’t need the column – or a release schedule. If each sprint doesn’t end with a release, then use a release schedule.
And use a physical Scrum board if at all possible. I know that electronic ones have benefits, and that sometimes they’re necessary when managing virtual teams. However, you’ll lose the benefit of stakeholders walking by and seeing it. Electronic Scrum board simply don’t get the same visibility as physical Scrum boards outside the core project team.
Simplicity–the art of maximizing the amount of work not done–is essential.Principles Behind the Agile Manifesto
Want to avoid Scrum failure? Keep it simple. 3 columns.
Keep them short. No more that 15 minutes at the very most. 5-10 minutes is better.
Stay focused on the 3 questions:
- What have you done since our last daily standup?
- What are you working on today?
- What barriers/impediments are in your way that, if removed, would improve your productivity?
Lots of other questions will come up that need to be discussed. Have the discipline to address them after the daily standup. You may want to reserve the whole hour so that you have time to follow up the daily standup immediately with a meeting or two to discuss the issues that came up.
Don’t let Scrum become an excuse for sloppy meetings. Avoid Scrum failure by keeping your meetings tight. Apply good meeting management principles, like having an agenda and sticking to it.
Keep your product backlog and your sprint backlog well groomed to ensure that they have the appropriate level of detail (less in the product backlog, more in the sprint backlog).
Rank order both backlogs – with no two tasks having exactly the same priority – especially the product backlog. The backlogs need to be a queue, with each item in line where it belongs relative to the other items.
One of the most critical benefits to Scrum is to focus on the highest priority features first. Deliver the highest value items first. If you run out of money, you can end the project early, but still have delivered a lot of value to the customer. Or the customer may decide, after spending 20% of the budget and getting 80% of the value, to end the project and redirect the funds to another project with features of higher value.
Measure Your Velocity
Many people complain that Scrum is unpredictable. On the contrary. Scrum was built to bring more predictability to projects that the waterfall approach has failed completely to accurately predict. Upfront predictions provide the illusion of predictability, and then frequently disappoint stakeholders with slipped schedules and cost overruns.
The whole point of using relative sizing, story points, and planning poker is to more accurately measure how long a project will take and what it will cost. Instead of basing your budget and timeline on up-front estimates, you measure how long it’s actually taking to get things done, and then use this information to forecast the rest of the project.
So take your relative estimates seriously, and track your velocity in each sprint. After a few sprints, you should be able to forecast your project with more accuracy than with a traditional waterfall approach.
Scrum fails when you fail to measure your velocity and use it to forecast your project’s time and cost. You end up with a project that goes on and on, with no end in sight.
That’s not going to leave your stakeholders with a good impression of Scrum. They’ll go running back to the false sense of security of waterfall’s exhaustive documentation and colorful Gantt charts.
Improve Your Velocity
Jeff Sutherland, one of the co-founders of Scrum, claims that with Scrum you can do twice the work in half the time. In other words, you can be 4 times more productive. How can that be?
First, by focusing on improving the productivity of the team, not just the individuals. That doesn’t mean that you ignore the productivity of individuals – just that there’s a lot more productivity gain to be realized from improving the productivity of the team as a whole.
How? By identifying and removing impediments. What processes are slowing things down? Are there unnecessary steps? Too many handoffs between people? Are there missing processes? How much time would it save to invest in quality (e.g., a few key automated tests) rather than scrambling to find and fix quality problems (bugs) later?
The whole point of sprint retrospectives is to identify what you can do to improve the productivity of the team. Look for pain points, but also look for opportunities.
It would fill a book to enumerate all the ways that Scrum fails because it’s not applied properly.
This is just a beginning of the complete set of Scrum practices that you need to be applied properly – with an understanding of the purposes and benefits of each practice – in order to get the most out of Scrum.
#2: Scrum Fails Because It’s Not Enough
Scrum itself is not complete. Even if you fully understand and properly apply Scrum, it’s still not enough.
Scrum doesn’t cover all of the best practices of project management. I don’t believe that it was ever meant to.
Scrum does a great job of managing some of the most critical aspects of scope, schedule, and cost. And to some degree, communications and change.
Scrum manages scope using the product backlog, with each item prioritized in rank order, and with all of the details needed for each item, including the definition of done. The schedule (and costs) are managed using timeboxed sprints. Communications is managed using colocation and daily involvement of a product owner as a member of the project team. Change is managed in sprint review meetings with stakeholders providing feedback.
However, there are many best practices that complement Scrum. Scrum is like the engine in a car. It’s an important part, but it’s not a car without a lot of other stuff around it.
Let’s consider just a few examples.
How about we start with the project charter. What’s in the project charter? Oh, things like:
- A high-level description of the project
- The expected benefits of the project
- The business case
- The preliminary budget
- The expected timeframe
- The initial list of key stakeholders
Scrum doesn’t cover any that. It’s outside the scope of Scrum. It’s assumed to have been done before you start a Scrum project.
Yet how many Scrum projects have failed because of the lack of a simple, clear, shared understanding and agreement of what the project is supposed to build, what the benefits should be, why it will be profitable for the organization, who the key stakeholders are, and a rough idea of the time and money the organization is willing to spend on it?
Agile and Scrum are about embracing change over following a plan. That’s not the same as not having a plan. You need a plan. You need to understand the organization’s needs, expected benefits, the project’s business case, etc. in order to know which changes to embrace, and which to reject.
Not having a plan is what causes many Scrum projects to spin out of control and fail.
Requirements Traceability Matrix
A requirements traceability matrix links each user story to the business needs and organization strategies. This helps you to prioritize user stories appropriately – especially feedback from stakeholders received during sprint reviews.
Many of the suggestions you receive will not be consistent with the benefits that the project is meant to deliver. A requirements traceability matrix can help you to filter out requests that don’t belong to this project and keep your Scrum project from becoming a free-for-all for everyone to add whatever they want.
Requirements Management Plan
The Requirements Management Plan is where you would specify this process for how you’ll use the requirements traceability matrix to keep the project aligned and on track. Scrum does not specify how to maintain this alignment. You still need the traditional best practice of a requirements management plan.
How about change management? Scrum doesn’t specify how change requests will be reviewed and approved. To keep your Scrum project from spinning out of control with scope creep, you need change control, and it should be specified in your change management plan.
Scrum projects are particularly prone to scope creep, which inevitably leads to failed Scrum projects.
And how will you ensure that changes don’t break things all the time? That’s the job of the configuration management plan.
Talk about Scrum failure! Keep breaking things all the time, and your Scrum project will fail. And good luck ever getting the chance to try Scrum again with that organization.
What about risks? You don’t want to ignore risks, and end up with all sorts of surprises that derail your Scrum project. You still need risk management. Have a risk management plan, identify risks, perform quantitative risk analysis, perform quantitative risk analysis as needed, plan risk responses, implement risk responses, monitor risks. You still need to do all of these things.
You need a quality management plan to identify your quality requirements and ensure that your work meets those standards.
You need a stakeholder engagement plan. It’s not enough to have a product owner collocated with your team. There are a lot of other powerful stakeholders that you had better engage properly.
And speaking of these stakeholders, you’ll need to communicate with them with more than the scrum board and the sprint reviews. As valuable as those are, you also need to communicate with those who don’t attend your sprint reviews.
Scrum doesn’t tell you how to develop your team. Don’t abandon all of the best practices in team development just because Scrum is great at some things.
Manage Project Knowledge
And how will you manage project knowledge? Sprint retrospectives are great, but how will you share your lessons learned with other teams, or remember them months later on your own project? You may want to take a look at how Spotify has done this by organizing team members into functional groups and guilds.
If you’ve been able to avoid Scrum failure on your project, don’t you want to have the same success on other Scrum projects in the future? You need to apply best practices in managing project knowledge in order to share and embed these lessons learned in your organization.
Combine PMP and Scrum to Avoid Scrum Failure
PMP and Scrum are not opposites. They’re complementary. They need each other.
Scrum needs the broader context and application of best practices in project management that you learn from becoming PMP certified.
PMP needs the Agility of Scrum – especially for projects with a lot of uncertainty.
The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant. But I have no doubts that it will mature further, become more open to the outside world, more reflective, and also therefore more effective.Philippe Kruchten, 2011
P.S. Don’t overlook the value that Scrum practices such as daily standups, sprints, and sprint reviews can add to more predictable projects – even fixed bid projects. For more about that, see Scrum on a Fixed Bid? Yes, You Can!