Scrum has had its day! What's next?

Scrum was a significant leap forward in software development methodologies compared to the traditional waterfall approach. By breaking down projects into smaller, manageable chunks and delivering working software incrementally, Scrum allowed for frequent interactions with clients and stakeholders. Also, by embracing change as a constant, it empowered teams to respond swiftly to evolving needs.

But the methodology has also brought its share of challenges, and even today many companies struggle to apply it properly. What if it's not their fault, but the methodology itself?

The problems with Scrum

First, it assumes that tasks can be accurately estimated. In practice, most companies have found that this is not the case. Unless the same task has been performed many times under similar conditions, it is unrealistic to think that estimates will be accurate. As a result, developers botch many tasks to meet deadlines, which is one of the main contributors to technical debt, which over time reduces productivity to potentially a fraction of what it would otherwise be.

Second, breaking things down into small, salami-sliced tasks creates significant overhead due to constant context switching, and makes it harder to see the bigger picture by focusing on individual pieces of the puzzle rather than the whole. Think about it: do you see workers constructing a building based on post-its where they have to 'place the door latch', 'place the lamp on the 5th floor' and then 'paint this wall and that wall'? Dividing tasks into bite-sized chunks has also damaged the morale of developers who no longer work on projects that are substantial enough.

Third, the sheer number of ceremonial meetings (stand-up, planning meeting, retrospective meeting, etc.) is not ideal for creative workers who need long stretches of uninterrupted work.

Fourth, sprints of one month or less are too short to achieve anything meaningful.

Fifth, there's the fact that the methodology isn't prescriptive enough about how to manage important criteria such as quality, rather than focusing primarily on velocity.

We could go on and on. Others have already done the excellent job of creating an exhaustive list of the problems. Time to move on!

What’s next?

In a future series of articles we'll be introducing a new methodology. A methodology where there are no kanbans, no estimates and no 2-week sprints. A methodology that has been developed by a company that has revolutionized many aspects of the software industry, and that has been validated in production over more than a decade by numerous applications with multi-million dollar budgets and revenues.

The primary objective is not necessarily to abandon Scrum tomorrow in favor of this new approach, but to show you a different way of doing things and to see how you can integrate certain aspects into your way of working, step by step, evaluate the results and adapt accordingly.

Stay tuned!