Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Why does Scrum fail – the project was not actually Scrum

This is part of a series of posts that I am writing about, that deal with why Scrum projects can fail. It could be a variety of reasons, ranging from team resistance, to wrong policies, to bad management. In this post, I will deal with yet another reason as to why a Scrum project could fail. This is probably the most simple reason, yet can be difficult to determine. These are typically projects that are claimed to be Scrum, but are not actually Scrum. And there can be multiple such processes that the team could claim to follow, but the basic reasons for failure in a number of such cases would be that the team thought that they were doing Scrum, but were missing out on many of the core processes, which eventually led to failure. Some of these cases could be:
– The team decides to have a daily stand-up meeting, and considers that they are doing Scrum. However, they would find over a period of time that the stand-up meeting does not really lead to many advantages, and start deferring the meeting with people cribbing about the meetings appearing to be a waste of time. The reason would mostly be that the meetings were being used for status, or were not succint enough, or did not focus on the past day / present day / impediments only approach, and turned off people due to the time lost. Just meeting daily and talking about issues does not make a Daily Scrum meeting.
– One of the ways that people start to believe that they are following Scrum is when they believe that the Scrum team is empowered to take decisions, but when you get down to basics, that is fiction. To allow the team to be empowered enough to take decisions after thinking through the implications is something that is easy to state, and difficult to actually implement. In a number of cases, the managers of the various teams get involved in the decision making, and more critically, do it in such a way that the Scrum team is not actually involved. This makes the team members start doubting the actual concept of the empowerment that they were promised during training sessions.
– I have seen numerous cases, where when a team is in trouble, they start meeting daily for 10-15 minutes to gather around and discuss status, and then later call these as Scrum meetings. This is certainly not Scrum, those are typically status meetings run by some manager, and is there to ensure that the team is working according to a desired game plan, but just a short meeting daily does not make it Scrum.
– In other cases, teams cannot handle the openness that Scrum data as well as retrospective meetings entail, and start trying to limit the scope of discussion and modulate the discussion and data analysis rather than working through the data in order to figure out exactly where the team is. This can lead to significant deviations from the openness desired from a Scrum process.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>