9 Practices that Haunt Developers Working with Scrum

Why Scrum has a bad name

Willem-Jan Ageling
Serious Scrum
Published in
8 min readSep 11, 2022

--

Scrum promised to be liberating for developers. It should have been a radical shift from the command and control practices that defined many waterfall projects. Scrum is about self-managing teams and sustainable pace. It should be an “ennobling experience” (Agile Software Development with Scrum (Schwaber and Beedle), 2001).

The world is flooded with Scrum Trainers, Agile Coaches, and Scrum Masters that spread this message of self-managing Scrum Teams who determine what they do and by when.

But the reality is very different for many Scrum teams and developers suffer from this. Many feel nothing has changed for the better. In fact, some think Scrum is worse than waterfall.

Here are 9 practices that haunt developers working with Scrum.

Photo by Ron Lach : https://www.pexels.com/photo/man-looking-outside-his-cell-10473516/

Crunch time every Sprint

Before Scrum took over the world of software development, organizations usually used traditional project management methodologies. Often referred to as “waterfall”.

Waterfall projects typically had detailed long-term plans and no feedback loops to inspect the product increments. Waterfall projects typically had a crunch time at the end of the journey. In the last weeks of the project, teams would often be pushed beyond their limits of sustainability to deliver according to plan.

Despite all the promises, many Scrum teams face crunch time far more often, almost every Sprint. Teams will end the Sprint with multiple days working overtime under high pressure to deliver “as promised”. This is a worse situation to be in than the occasional crunch time with traditional projects.

Scrum should not be about this. Teams should not worry about delivering according to plan every Sprint. They should focus on finding the best ways to achieve their goals. Not on delivering as promised. However, this is only the theory. The practice is that many teams suffer from crunch time.

Story Point Misuse

The majority of the (hundreds of ) Scrum teams I know use story points. At least half of them struggle with story points. The initial idea of story points was to move away from estimating…

--

--

Willem-Jan Ageling
Serious Scrum

https://ageling.substack.com Writer, editor, founder of Serious Scrum. I love writing about maximizing value.