Five Reasons Why Scrum Failed Your Software Organization
Scrum is a project management framework within the agile methodology of software development. The core theory surrounding Scrum is to put more control over work into the hands of software developers, and then allow them to do small chunks of that work in short periods called Sprints. At the end of a Sprint, a piece of software it delivered that can be reviewed by stakeholders and end users. Adjustments to plans can then happen each Sprint rather than as large change requests at the end of a project.
As great as this sounds, there are still software organizations out there that don't use it, and the reasons for that are as numerous as the stars. If you've tried to implement Scrum in your organization and failed, it may be because of one or more the following five reasons.
1. You Only Tried Scrum Because Everyone Else Was Doing It
Unless you're incredibly lucky, there are undoubtedly competing organizations that are doing better than yours. So why not look at what they're doing for inspiration? You want to emulate success, right? Well, yes and no.
Organizations that do this have succumbed to the logical fallacy of survivorship bias. This is the mistaken belief that, in a system that's filled with random outcomes, if you emulate the successful you will become successful.
The truth is that to get all the value possible from Scrum, you must believe in it. A Scrum implementation will require your organization to change more than just a project management style. You'll need to change how you organize and manage teams, and how you plan and adjust plans.
If you're still considering Scrum, implement it because you truly believe that it's an improvement on what you're using now.
2. You Used Scrum Terms to Describe Your Existing Processes
Chances are, if your organization has found itself in this situation, you're struggling to let go of your old project management practices in favor of Scrum practices.
Daily Standups--or the Daily Scrum--become daily status meetings where developers give status to the project manager and receive action items. Planning meetings become a tech lead, project manager, or some other higher up dictating to the dev team the next sprint's work.
If your organization can't get those meetings right, chances are there are many other processes that aren't conducive to the Scrum framework. If that's the case, it's time to consider that you may not actually want to do Scrum, you just want to sound like you do Scrum.
3. You Didn't Respect the Roles
In Scrum you must respect the responsibilities given to each role. And while that statement may be true for many other things in life and business, it's particularly true for Scrum. If you're allowing Product Owners or Scrum Masters to allocate points to stories or letting developers dictate priorities, then you're not doing Scrum.
Scrum works best when planning and execution is done in a top-down/bottom-up fashion. Big goals from the top and detailed implementation from the bottom. This is a collaborative relationship meant to create an executable and realistic plan.
4. You Didn't Do Points Right
Points don't equal time.
Points equal effort. They tell the relative difficulty of a task, and each team will come to different understandings of what one point is worth. That means giving the teams the time to do pointing exercises and coming to that understanding organically over time.
If you're unsure how points differ from time estimates, and begrudgingly use them because it's part of Scrum, then you probably don't get any of the benefits they provide. In fact, your teams will default back to time estimates, and you'll have created a culture where your organization lies to itself to feel better. If you're lying about what points mean, what else are you lying about?
5. You Didn't Understand the Purpose of Tracking Velocity
Velocity is the number of points, on average--usually over 3-4 sprints--your team completes in one sprint. And if you're guilty of #4, this will mean nothing to you.
Velocity is a planning and forecasting tool. Its purpose is for the development team to gauge the amount of work they normally complete so that they can commit to a sprint's worth of work during sprint planning. If you're using it for management to track how productive the team is, then you're doing it wrong again. There are many reasons why velocity fluctuates, and it has very little to do with how hard your development teams are working.
If velocity is used to track productivity, development teams will start gaming the system. Making story points and velocity mean nothing.
There's So Much More
Like most things in life, the failure of Scrum in an organization is a complicated thing. The reasons why it might not have worked for you are far greater than the five that are outlined in this article. And chances are that you've experienced these Scrum failures to some degree.
There is, of course, the chance that Scrum just isn't the right framework for your organization. Only you can evaluate that, but if something didn't sit right for you about the Scrum failure in your organization, the five reasons above may help you to understand where you might have gone wrong.