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 …

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 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 does not work because it is not fault-tolerant”
“Sprint reviews are a waste of time! Let’s skip them!”
“Daily Scrums are micro-management! Let’s not do this!”
“Scrum is waterfall because you are working on stories consecutively!”

“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 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 …

“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 …

“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 …