Why Scrum sometimes fail

The organization is not ready to adopt Scrum
Maybe the most common way for Scrum to fail is that organizations are not ready to adapt agile development. The Product Owner continues to work controlling instead of facilitating, doesn’t empower the team, and won’t let them come up with their own way of working. This fear of loosing control is seen when requirements are over-specied and the team has lots of constraints. It is therefor essential to have an experienced Scrum Master who can help the Product Owner write requirements more abstract and to make sure that management knows what is needed in order for Scrum to work in their organization. In conclusion, for Scrum to work, a change of mind-set is necessary.

The Product Owner can’t prioritize
Another thing that is guarantied to wreck a Scrum project is if the Product Owner is unable to prioritize the work. One major benfit is that the development team always should work on what gives the most business-value. This can of course only be done if the Product Owner know what he or she is doing, make good decisions, and is able to effectively communicate and collaborate with the team.

The teams are not ready to work cross-functional
Traditionally there arefixedxed roles within the team; designer, programmer, tester, CM etc. In Scrum, everyone in the team should work cross-functionally.
The benefits of this is that everyone feels much more responsible for quality and the overall success of the project.

The team are not willing to improve their engineering skills
Much like some organizations and managers can have problems adapting to a new method, so can developers. A common problem is that developers doesn’t work in an Agile fashion when it comes to method and technique. They have to use the power given to them and react to upcoming problems – otherwise the project is doomed.

Already existing problems become obvious
The problems that will arise the first time you try Scrum will probably not have anything to do with the method itself. Instead, it causes problems that are already there to become obvious.

  • Every day you might find out that the people in the team didn’t do what they were suppose to.
  • Only one team member knows how to build the system.
  • By looking at the Burndown chart, you will early see that your project is not on track.
  • At the end of every Sprint you might find out that the team are not progressing as marketing (project management) has hoped.

On the bright side – you will find this out while you still have time to fix it.


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