Are We Seeing the End of Scrum?

As Agile is outgrowing IT and the world starts talking about Business Agility, we see Scrum attempted in various setups - Marketing, Sales, Legal, Management. Although it can be technically used in such contexts, Scrum was invented to help software teams deliver software, and as such, it dominated the industry. But the most recent State of Scrum report might be marking the end of an era.

According to the report, in 2017, only 16 percent of the teams implementing the framework used it "by the book". This is a significant drop compared to the 43 percent that stated so in the 2015 survey. These results come as no surprise as there are multiple challenges that Scrum has no definitive answer to.

Who Betrayed Scrum?

When Scrum was disrupting Waterfall, the sprint was instrumental to the success of the framework. It forced teams to deliver every 2-4 weeks, which was a 10x improvement to the best Waterfall organizations, which used to deliver once per year (the norm was more like once every few years). Sprinting led to faster feedback loops, less rework and a radical shift in the developers' minds, which ultimately propelled the entire industry to a whole new level.

Ironically, it's the Sprint that's marking the demise of Scrum. When teams deliver hundreds of times per day, iterations of any sort are rendered useless. Besides, why bother planning even a week of work, when it's almost certain that priorities will change? Why bother estimating work, when you can slice tasks to be a few days long and focus on value-adding activities only?

You may disagree with this statement but there is evidence and it can be found in the very same survey mentioned above. It shows a very interesting trend. As much as 60 percent of all surveyed Scrum practitioners stated that they use Kanban too; a 20 percent increase since 2015. This means that more Scrum teams use Kanban than Scrum itself.

Although Kanban and Scrum can co-exist successfully, there is one significant difference that sets them far apart. Kanban focuses on continuous flow and not iterations or sprints. There's no start and stop but just smooth, never-ending flow of value. When so many teams are falling for Kanban, then they must be appreciating the flexibility that comes with the absence of sprints.

Joshua Kerievsky said in one of his keynotes that Scrum was outdated and that it was no longer fit for purpose. Is he right?

Dissecting a Sprint

There are a few core issues with the sprint as a concept. First and foremost is the fact that you need to plan what work fits into the two-week period. If the sprint takes more than two weeks, getting the estimation right is even harder. So, you sit with your team, play planning poker, and if you're well-prepared, you'll be done in a few hours. Chances are that your product owner has been very busy and wasn't able to prepare all the stories in the backlog. If that's your reality, you might actually not know what to work on, even after spending those few hours. If you are one of the lucky ones and have a PO that's always available, then it's time to get to work.

But, hold on, what should you do with the stories that weren't finished during the previous sprint? Yeah, just move them back to the backlog and hope the PO never gets to those again. She might not even notice our issue number two here - stories we couldn't finish and have to carry over to the next sprint. This is probably the most frustrating thing of all - you spent the time to groom this story, estimate it, maybe even work on it, and then - back to the backlog. What a waste!

Issue number three is called story point inflation. Here's the deal:

• Sprint 1: Work amount X is estimated with Y story points.
• Sprint 1 fails (meaning that not all stories are finished)
• Sprint 2: Work amount X is again estimated with Y story points.
• Sprint 2 fails (technically speaking, there's no failed sprint, but people keep saying it)
• Sprint 3: Work amount X is estimated with Z story points, where Z > Y.

When the teams try their best and fail at estimating the work right, they start allocating reserves, you know, just in case. So, at sprint 3, the very same amount of work is estimated with more story points (inflated) just because the team was reluctant to "fail" the sprint again. That's a lesson about how you get less done.

And how do you deal with those unplanned tasks? A customer defect or urgent production issues? You either leave some free capacity in case something happens, or you have the option to cancel the sprint. Both options sound sub-optimal, especially in comparison with Kanban, where you pull the next most important ticket and work on it.

The bottom line is that sprints have a lot of hidden issues, and teams simply get tired of dealing with them all the time. This must be one of the reasons why they abandoned the pure form of Scrum. But that's not all...

Scrum, Kanban, and Michael Jordan

When Scrum was invented, it was meant to shield the team from the outside world, so that they could do a better job delivering software. This means that Scrum was meant to work in isolation from the very beginning. By definition, it's a local optimization.

Lean and Kanban, in particular, focus on the whole system. They aim to optimize the flow of value through a network of services and connected workflows across entire value streams. In a way, Scrum compares to Kanban as Sprints compare to Marathons. One is optimized for the short term and the other for the long term.

This whole story would be just a random thought if it wasn't for the huge implications that follow. Because Scrum was meant to work inside a single team, the problems it aims to solve are much smaller. Because the problems are smaller, the chances of success are higher. Therefore, the failure rate is much lower. But failure is a precondition for success:

"I've missed more than 9000 shots in my career.  I've lost almost 300 games. 26 times I've been trusted to take the game-winning shot ... and missed. I've failed over and over and over again in my life. That is why I succeed." ~ Michael Jordan

The best basketball player in history is no fool. He knows that failure and grit are what matter in the long run. They are the precondition to a healthy culture and sustainable, long-term results. This is where Scrum fails, sometimes big time. Because it doesn't serve a big enough challenge, it impedes the realization of the true potential of the organization. There's no radical focus on flow, and therefore, the stimulus for optimization is not that strong. Sounds strange, but it's a fact.

So, Are We Seeing the End of Scrum?

This is not a simple yes or no question. Scrum is one of the most popular Agile methods/frameworks for project management that has helped countless teams improve and achieve better efficiency. However, the framework has started to lose popularity as some teams discover other approaches work better for them.

The limitations that come with Scrum are becoming a problem for more flexible teams that need to be as adaptable to change as possible, which leads them to try other ways of managing work.

It is fair to say that Scrum won't disappear anytime soon. However, you can expect to see an even greater decrease in pure Scrum implementations and even more elements of Kanban added to the framework.

Our prognosis is that in a matter of several years, the sprints will completely disappear from Scrum, and the framework will more and more resemble a flow-based implementation. Unless that happens, we will definitely see the end of Scrum.