Getting Out of the Trap of Scrum

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.


If you are having troubles with Agile at the team level you should read this – Scrum as Example. It is designed both for those using Scrum and those about to start. It is an extension of Scrum in that you can start with Scrum (the practices in the example are Scrum practices), but by realizing that these practices represent decisions that Scrum has been made for you, it gives you the opportunity to make better decisions when your context warrants it.

Continue reading here if you are interested in why Scrum often gets teams into trouble by its design, training method and promotion approach.

The Challenge of Scrum

Everyone acknowledges that there is a lot of bad Scrum out there. People often do some of Scrum’s practices but not all. This has derisively been called “Scrum but.” Unfortunately, the cause of this is inherent in the way Scrum has been designed, the way it is taught and the way it is promoted.

The Design of Scrum Is Flawed

Scrum is designed to discover impediments to development in a couple of weeks (for the purpose of this article we are assuming 2-week sprints are being used) and then to remove them. For example, interruptions, not having cross-functional teams, and doing daily standups. The idea is that by removing impediments you will be able to do Scrum properly. While Scrum can lead to succcess if can follow all of Scrum’s prescribed practices, they are not always the best practices for a team to be doing. This leads people to stick with Scrum even when it is not appropriate and they do not know alternatives that will meet the same objectives.

The Challenge of How Scrum Is Taught

This situation is exacerbated by how Scrum is taught – “use the Scrum practices until you understand them and can go beyond them.” The challenge here is that using them as defined may not get a team to effectiveness. So teams struggle with the Scrum practices. Unfortunately, they’ve been taught to follow Scrum as is. Their understanding on why they are doing the practices is not deep. This leaves them to try things on their own when they can’t get the practices to work. Without understanding this often leads to just different bad practices.

The Promotion of Scrum Makes Things Worse

This situation is exacerbated again by how Scrum has been promoted. Many Scrum proponents have equated Agile to Scrum, ignoring the fact that Scrum is just one way to achieve Agile. But the impression for people who have decided to do Agile is that they should start with Scrum. Furthermore, Ken Schwaber, one of the creators of Scrum, says “Scrum is simple, just use it as is.” The challenge here is two fold. First, consultants who only know Scrum and make their living off of it succumb to what Upton Sinclair referred to by saying “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!”. The second is it sets up the notion that Scrum is providing an answer to the teams and it’d work if they’d only follow it. This is why, if you want to use Scrum, it is better to use someone who also knows Kanban. S/he won’t be attached to either.

The bottom line is that these three things combine to have people learn Scrum, try to follow it, and then not know what to do when it doesn’t work.

Getting Out of the Trap

I am not suggesting that Scrum should not be used nor should people abandon their investment in it. Just the opposite. I created Scrum as Example so that one can still use Scrum while getting out of the above traps. Being aware of these traps is important, however, as it is easy to fall into them.

Another way out of the trap is to consider Scrum as a tool in your toolbox and not the entire tool box. Scrum has many brilliant ideas. It is where I learned the value of teams. But as a set solution, Scrum may be a trap.


In Praise of Swarming by Dan North. A must read about the state of the Agile industry.