Scrum Wanted! » Scrum Ignorance

Why Scrum projects fail

admin — Mon, 19 Jul 2010 10:31:19 +0000

Recently, a couple of agile fellows and I discussed why we see many Scrum projects fail. Here are some reasons we witnessed or experienced ourselves during our work on so called Scrum projects. The purpose of this list which is by no means exhaustive is to help you avoid making the same mistakes when you start out using Scrum on your projects:

Adjusting Scrum to organizations instead of adapting the organization to Scrum
Adapting Scrum even before it is applied correctly
Blaming Scrum for the issues being surfaced (”Scrum does not work because …“)
Changing the Scrum process model
Changing or omitting the Scrum roles
No cross-functional team
No self-organization among the team
Team is too big
Scrum is scaled too early
Missing engineering practices
Missing management buy-in

I am interested in hearing your thoughts about why Scrum projects can fail.

“Oh, we just call it Scrum!”

admin — Fri, 18 Dec 2009 10:24:29 +0000

There is an interesting discussion going on in the Scrum discussion group on XING: The question is why organizations call projects Scrum projects although they seem to have no intention to use Scrum at all. Some people in the discussion suspect this a trend to make projects sound modern and appealing. I absolutely agree and think this is clear evidence of growing Scrum ignorance.

Scrum Ignorance: “Scrum does not work because…”

admin — Wed, 02 Dec 2009 06:36:09 +0000

Photo by Flickr user "johnscotthaydon" http://www.flickr.com/photos/johnhaydon/3252135212/

“Scrum does not work and I won’t even give it a try!”
— anonymous ignorant

This collection of all the ignorant statements I have come across since I have been using Scrum should help you reply to similar statements in case you will ever be confronted with them:

Scrum Ignorance: “Daily Scrums are micro-management. Let’s skip them!”

admin — Wed, 02 Dec 2009 06:35:07 +0000

Photo by Flickr user "johnscotthaydon" http://www.flickr.com/photos/johnhaydon/3252135212/

“Daily Scrum are micro-management! Let’s skip them!”
– anonymous ignorant

I will comment on this very recent statement soon. Meanwhile, feel free to comment on this statement to share your thoughts with me.

Scrum Ignorance: “Scrum is not fault-tolerant!”

admin — Thu, 26 Nov 2009 22:25:12 +0000

Photo by Flickr user "johnscotthaydon" http://www.flickr.com/photos/johnhaydon/3252135212/

“Scrum is not fault-tolerant! It causes too many issues! Hence Scrum does not work!”
– anonymous ignorant

Of all the ignorant statements about Scrum I heard during the last weeks, this is my favorite one. It clearly shows that some people still don’t get the principles of Scrum: Scrum is not meant to be fault-tolerant. If it was, projects and teams would not be able to improve. Instead, Scrum has been designed to make everything clearly visible which is blocking the team from getting their work done (to deliver working software at the end of each Sprint) and from becoming more productive.
If you are new to Scrum and about to apply Scrum to your project or organization, expect issues (we call them impediments) to come up. If you don’t find any impediments, you are not looking hard enough! Keep asking yourself, the team and the product owner what could be done to make the project or the organization more productive.

And when you start hunting down these impediments, prepare yourself for some hard and sometimes frustrating time. As Scrum practitioners keep saying, “Scrum is easy to understand but difficult to implement!”.

Please read “Sprint reviews are waste of time” for an example of why it is vital to resolve impediments.

Scrum Ignorance: “Sprint reviews are waste of time! Let’s skip them!”

admin — Thu, 26 Nov 2009 22:22:52 +0000

Photo by Flickr user "johnscotthaydon" http://www.flickr.com/photos/johnhaydon/3252135212/

“Sprint reviews are waste of time! Let’s skip them!”
– anonymous ignorant

Another ignorant statement: Why bother with Sprint reviews? Just one example of an impediment from one of my recent projects. When I joined the project, the team was not able to run Sprint reviews as the development was done on an environment which was not able to run the entire code. The first reaction from people involved in the project was “Let’s skip the demonstration, it is wasting team’s time anyway. We should concentrate on coding instead!”.

Well, that is maybe the worst idea on an agile project – and it is extremely dangerous: As opposed to a waterfall approach where your point of reference is a fully fledged specification, the only chance to check if you are still on track is the Daily Scrum and the only way to check if you are still heading into the right direction is the Sprint review where you demonstrate running software to the product owner at the end of each Sprint. In this situation, skipping the Sprint review is even worse than following a waterfall approach! Because is means you will lose one of your two reference points!

On the project I was talking about, we put the development of new features on hold for two Sprints and focused on fixing the development environment to solve the underlying issue.

Scrum Ignorance: “Scrum is waterfall because you are working on stories consecutively”

admin — Thu, 26 Nov 2009 22:19:16 +0000

Waterfall Palenque Mexico by Flickr user "zoutedrop" http://www.flickr.com/photos/zoutedrop/2297190795/

“Scrum is waterfall because you are working on stories consecutively!”
– anonymous ignorant

Of all the ignorant statements I’ve heard so far, this is my new favorite one. Obviously this one is dead wrong because for each story, you complete analysis, design, implementation, testing, and documentation (see figure 1) before you move on to the next story whereas in waterfall, you first complete the analysis for all requirements, then design for all requirements, then implementation, and so on and so forth (see figure 2). So the big difference between Scrum and waterfall is that you deliver small chunks of value to the customer and users with every story while in waterfall, you deliver value only at the very end of the process (and only if you are lucky and the requirements haven’t change since you captured them in the initial analysis phase… But that’s another story).

: figure 1: Agile

figure 2: waterfall