SCRUM is Dead

Story points are a myth and SCRUM is an agile anti-pattern

When Agile is mentioned, people usually associate this with Scrum ceremonies and story points.

These rigid rules regarding the handling of teams and their production of value are the opposite of Agile. Let me explain why.

Agile is about incremental changes

But Scrum has the same rigid sets of meetings and ways of working. It values process.

Why don't we start basic and work upwards, applying process as we need it?

The reason is that a business needs an adapter for its waterfall soul, to allow Agile to operate inside it.

Story points are unnecessary

Applying story points or t-shirt sizes to stories does not make sense. This arbitrary illusion of effort applied to something that should be as incrementally small as possible does not make sense. How about just make it small. Teach how to break a piece of work down instead of how to point it up.

Sprints aren't necessary

We have sprints as a mechanism to deliver value in timely slices, but what if we just deliver value as fast as we can, for every ticket even.

Agility comes from the ability to quickly pivot on our goals according to business needs, but the sprint in Scrum is watertight after we apply sufficient points to fill a quota of available people power.

The sprint goal, for the comfort of the company might be replaced by a theme to allow outsiders of the work to understand our vague direction. Perhaps each ticket might have its own goal. A sprint goal in scrum railroads tickets to be of a theme, encouraging us to strip out non goal tickets. Sometimes though, we have goals (plural). As long as they are not competing, this is fine. Let's set a theme or a vision instead and let this guide us and communicate our mode across team boundaries and to the business.

Retro is too late

We wait until the sprint is over to talk about any problems we had or things we can do to make things better. This does not sound like Agility.

Instead, take advantage of your daily and in the morning, ask as we go, what can I do to make this better?

Ask for each ticket and ask the team as a whole. Reducing the time, we need to wait to talk about and execute a solution that provides better ways of work.

Retrospectives are too late. Fix problems straight away, not in two weeks.

🎙️ Lee here. This is a culture thing. It's normally the case that developers and businesspeople are so used to the retrospective that it's hard to realise that the goal is betterment, and that this should happen every day and not every two weeks. I've worked in places where this approach worked well, people were happier and there was one less meeting every sprint. I've also worked where people felt uncomfortable without this meeting. Your mileage may vary.

The backlog is toxic

A backlog for sprints tickets is usually a long list of things people have thrown in there, debris from previous ideas that no longer make sense and barely finished stories that an engineer could not work on unless they consult the business.

For the maximum Agility, logically, we need an empty backlog that is only filled with the current business needs, nothing more.

🎙️ Lee here. The term YAGNI means 'You ain't gonna' need it'. We use this to stop ourselves from using our wild imaginations to scope creep a story. It stops us from making assumptions and coding in the wrong direction. Sometimes we can use things like this in places outside a ticket, like here in the backlog. Why plan so far ahead. You aren't going to need those tickets so why keep them around?

If a ticket is actually important, then it would be in the sights of the business. If we delete one and it is required, then it will come back in some form or another.

Strip your backlog bare. It's full of things people forgot about long ago and no longer apply to the problems at hand.

Build your backlog by walking ahead by a week or so with the business teams to build or fix things that are a problem right now, let the current instinct of the business drive you to produce value, not some mouldy old forgotten list of relics.

From zero

Each team, product and organisation need to work a different way to another. A framework like SCRUM flies in the face of diversity by prescribing the same medication for everyone.

What if instead we started with the most basic Kanban board, a daily for blockers and went upwards from there?

We add bureaucracy and triggers for actions when we need them, with the goals of getting better and producing value the business needs. Given enough time, most teams will arrive at the velocity that suits them.

Teams can talk amongst themselves about what works and form their own work style.

Taking a canned work style might seem like a great shortcut, but in the long term it's not great for allowing teams to be autonomous.

🎙️ Lee here. Take a step back from your team and look at what is effective around you. There are always new ways of working or ways you have not tried yet. Usually, problems teams are having are already solved by somebody somewhere. Your job is not to create a new solution but to find a team with a similar solved problem and try their approach. We get brave and just try it.