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.

Learn about Scrum – Why does Scrum fail – The team is just not ready for a change in their processes to handle Scrum

In the previous post, I took a real life example of a team (Daily Scrum and ScrumMaster) where Scrum was getting implemented, and yet soon after the actual work started, we were finding that things were not going on schedule, and that there were a lot of issues about commitment from the team, analysis revealed that this was due to the ScrumMaster, and when steps were taken to modify things, then we started getting better results.
In this post, I will talk more about a team commitment to implement Scrum, and what happens when Scrum is implemented when a team is not ready; even when outward appearances seem to reveal that the team is ready. There are 2 specific cases that I came across that causes us significant problems.
Case 1: Temporary people from other teams and their feedback: We had a case whereby a team was facing a schedule problem, they had to do a number of features in a certain period of time and they had insufficient resources. So, for a team that was around 8 members, another 4 members was added to their team from another team (where the other team was not doing Scrum, while the first team was implementing Scrum). So, you had a case where 4 new members were added to the team who had no knowledge of Scrum, and nobody really though of even working them through a walkthrough of the benefits of Scrum, its need, its core concepts, etc. Instead, they were presented with a list of what they needed to do, told that there would be a daily meeting where they would have to present their updates, and what they planned for the next day. And in those turbulent times, the meetings seemed totally like Daily Status meetings rather than what the objective of a Daily Scrum meeting is. As a result, when they came back to their parent teams, they informally presented back to their colleagues a version of Scrum that was heavily distorted. When a few of us started talking about what Scrum is, and whether it is something that the team was comfortable with, the feedback we were presented was very different from what we expected, and then we realized that all of this feedback was due to the work that these few team members had. It was also hard to change opinions, since the team members had indeed worked in another Scrum team, and their feedback had the stamp of a realistic portrayal while whatever we spoke about was more in terms of a theoretical presentation of Scrum. The biggest problem was the depiction of the Daily Scrum as a way of generating status, with no value for the people present in the meetings.
Case 2: This one is a shorter portrayal. The team had a number of people who had spent 5 plus years on the same product, and who were used to the way we were doing things, they are very uncomfortable with some of the concepts of doing Scrum, most of it centered around the concept of a Daily Scrum meetings. In a couple of situations, other teams have taken to doing a daily meeting when in panic situations, and calling such meetings as a Daily Scrum. These daily discussions did benefit the teams, but have unfortunately led to a perception that the Daily Scrum meeting is a good way to fight situations when the team is in problems, but not on a regular basis. For these teams, we are now struggling to provide a level of training that would show them the benefits, since the mistakes made by other teams have a perception that has caused setbacks.

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>