The risk of scrum

January 07, 2010 | 2 Minute Read
This post was originally posted on my old blog.

Last month Ralph Jocham gave a talk about the Risks of Scrum.

He published the slides on slideshare: Ralph Jocham The Risks Of Scrum.

As far as I understood it, Ralph identified two Risks with Scrum:

1. Not doing it right or not practicing it to the full extent
2. Neglecting technical excellence and accumulation of technical dept

The first one is a bit a platitude in my opinion. Any failure can be blamed on not doing things right... of course with methodologies that consist of several parts, there is a danger of cherry-picking, but I am not sure that this can't work. I think it's also often a cheap excuse to put the blame for a failure on "not doing it right". I mean, who is really doing it right? How many of the successes are doing it right?

According to Ralph the second risk should be met with XP practices that focus on technical quality.

But in my opinion there is a much more fundamental danger in scrum:

Scrum gives the impression that it is possible to bring "Embracing Change" and "Getting Things Done" under the same umbrella.

This is dangerous. "Embracing Change" and "Getting Things Done" are two opposing forces. On a certain level it is inherently not possible to get things done while embracing change.

Scrum as an agile methodology is all about embracing change. With the focus on the Done-Stage on the Taskboard and the "Definition of Done", Scrum claims that those two opposing forces are actually not opposing. This is in most cases an illusion.

This is mostly a result of focusing on small stories with immediate business value. Getting these stories done is possible, and Scrum can easily misused as an "excuse" to neglect the big picture.

Progressing in Scrum means getting stories done. Often the real progress of a finished story in regard of the whole project is not measured...

A symptom of this antipattern is that certain things get touched and changed again and again by new stories in subsequent sprints... so what was actually done, the story or the real business problem?

Shortening sprint duration and focussing on smaller user stories can even aggravate this problem ...