Pitfalls in Scrum

Some people want to know what can go wrong using Scrum. Personally i do not believe that this thinking approach is helpfull. A lot of things will gro wrong when you try to “implement” Scrum. Maybe the idea to implement Scrum is wrong in total. Can you implement new thinking? You might be able to change the way people think or the way people behave but you can not implement new thinking and behavior.

The whole discussion of implementing Scrum leads to the concept that Scrum is a process like other processes. That is wrong and unfortunately people do not want to hear, that is not a silver bullet, that it will not help you to take your responsibility away.

To help people to accomodate to this way of thinking John Hill and I put some ideas together. Below you wil find some ideas how to deal with “common pitfalls”.

Senior Management not “buying in” or properly supporting Scrum
(read Ken’s article below):

Team members unwilling to give-up their “role”
(e.g., cross- functional teams are supposed to perform many roles. More specifically, developers should be willing to write test cases, execute test cases, write specifications, etc. QA Analysts should be willing to write specifications in addition to writing and executing test cases. About the only exception to cross-functionality is that only developers can code (although they need to do everything else to keep an iteration going).

The ability to deal with “barnacles” (i.e., unproductive team members).
From our training material: “A successful ScrumMaster must have the ability to “reform” or “remove” the team “barnacles” (unproductive team members, who like barnacles, can sink a ship – Jeff Sutherland coined the term “barnacles”). Per Sutherland, People will not change their behavior if they do not feel an emotional impact. The ScrumMaster must know how to interact with barnacles in order to sometimes “shame” them into being team players in front of the Sprint Team (not a role for the meek at heart). Per Sutherland: All of this needs to be handled firmly, impartially, and impersonally. A good ScrumMaster handles this effectively, tactfully, and persistently. S/he effortlessly converts barnacles into real contributors”.

Ineffective ScrumMasters
(i.e., ScrumMasters who are unable to meet daily at the same time for fifteen minutes, unable to produce the Sprint artifacts, unable to control the daily Scrum, unable to remove impediments, unable to perform the many “behind the scenes” tasks we’ll discuss in training, especially getting the team to succeed by “facilitation”). Successful ScrumMasters must also be “champions” for Scrum within the organization, actively resisting the “tyranny of the waterfall” and convincing everyone that Scrum does work!

Ineffective (or absent) Product Owners.
Without a committed Product Owner, the team is doomed (read my Practitioner Certification document in the link above). These are the major hurdles for you to overcome (although there will be other challenges, such as providing reporting which Executives are not used to, and must thoroughly understand before you start using Scrum).

Not having the Backlog in Place
Although it sounds weired: The most common pitfall is not having a product backlog. At the beginning of a project you might have one. It is usually a huge document with hunderts of items in it. But after a while, the product owner realise that he has no clue what he wants and he seeks help from his organization. And suddendly they are not able to answer the very important next question: What shall the team does next sprint?

You do not make the first Sprint successful
The first Sprint must be a success. Try to create a success with all your power you have. Do not take in to much work. Do not try to be perfect and do not try to convince everybody. Be a politic. Try to give every people in your organizations what he wants. Make it a success.

The Scrum Master works as Product Owner/Developer
In the ScrumMaster Certification class we do have an exercise that helps people to understand, why a ScrumMaster schould not be also a Product Owner or Developer. In the class people answer to this:
In case he is, this will lead to conflicts, unclear behavior and unclear communication. He might become an authority and this will harm the self-organization. He might not want to deal with the impediments because it is easier to work on his own than on the hard work of removing impediments.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s