Is Scrum on its last legs?

When agile project management methodologies emerged and Scrum began to grow in popularity, it was a huge benefit for many projects. Instead of long-term planning, people began to think in shorter intervals. Six-month cycles suddenly became two-week sprints. But times are changing, everything is faster, and we can deliver new features in a matter of days.

The way we work has changed, as have the ways we deliver software, and new testing and quality control options have been added. So, is Scrum holding us back in ways that are no longer relevant? Does Scrum still have a place today?

Change in project management

I think that Scrum is starting to slow us down in many ways. The originally agile methodology has become an unchanging framework that often disrupts the natural flow of events. Perhaps it is time to review our project management requirements and propose changes that would help us better adapt to today's world.

Dynamic cycles instead of rigid sprints

Although Scrum is an agile management methodology, it often fails in this regard. A two-week sprint is too rigidly defined for a period in today's world. In many cases, we try to slice our work so that it fits into that time frame. Or, conversely, we try to assign smaller pieces so that everyone has enough planned work.

But things change quickly. Problems arise, and some things turn out to be much easier than they seemed.

We then move tasks from sprint to sprint, and developers start working on the next sprint early because they have remaining bandwidth.

During retrospectives, we then blame ourselves for making a poor plan. But that's not our fault. We're not perfect, and estimates are really just estimates.

What I used to like about Scrum was that at the end of the sprint, I could "finish" my work, let go of everything, and start something new the following week. However, development is a continuous process; and we usually only complete part of a larger task and carry it over into subsequent sprints. The illusion of completion then disappears.

I don't mind working on a feature for two months, but I do mind that every two weeks we pretend we're "done."

Prioritization instead of planning

Especially when multiple teams collaborate, planning becomes a fragile house of cards. One stumble is enough to bring everything crashing down. Every team faces problems and affects the work of other teams. Even teams that work independently encounter unexpected complications.

Prioritization often takes precedence over planning - I notice this more often in the projects I work on.

In this case, Scrum often gets in our way or slows us down.

Floating capacities

Even the experienced Superman we have on our team can sometimes hit a wall and reach a dead end. It is often more advantageous to bring in an expert for the project. The problem here is probably not so much on the Scrum side as on the capacity planning side. We have fixed roles and fixed FTEs in our teams, and there is not much room to maneuver.

I see the ability to dynamically adjust the team according to current needs as a great benefit - the team will learn something new and may not need an external expert next time. At the same time, the project will not be blocked by things we don't know how to deal with.

In many cases, of course, we are bound by contracts, and it is not possible to simply move capacities around like this. But that is a question that management could deal with.

Chat or AI instead of stand-ups

When I look at my calendar, I feel helpless. There are so many regular meetings that I often have no idea if I'll be able to get anything done that day. I'm talking mainly about daily stand-ups.

I don't know how others feel about it, but I believe we're all in the same boat. In a third of cases, I'm mentally absent because I'm thinking about the things I'm currently working on. In another third, the standup distracts me from my work, and I then have to "get back on track."

All it would take is one sentence in the team chat. Or a summary of what's happening in the repositories and tickets generated by AI.

Scrum also (more or less) forces us to separate different types of discussions. Backlog Refinement is not planning, and daily scrum is not for solving technical issues. However, this is often breached because it is simply not always possible.

I find it more effective to schedule meetings for things that really need to be addressed than to strictly adhere to Scrum ceremonies.

New old methods

Maybe it's really time to abandon Scrum and look for something new. Something that is adapted to today's world. While searching for information, I came across two relatively new methodologies and one relatively old one.

Responsibility and experience

As I write these lines, I realize that the most important element is always responsibility. And also experience. Teams composed of experienced and responsible developers often do not need any management. For me, Scrum is just a formality, sometimes even a "necessary evil."

But such a team is often a utopia.

Perhaps it is not a bad idea to be agile in this regard. Start a project with Scrum and later transform it into something that suits the team better.