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.

Scrum failure – Team giving up Scrum since short term problems make them give up hope

For teams that follow a rigid structure of a project manager -> project leads -> project team members, and where the decision making is concentrated in the hands of the leads and the project manager, the structure can seem a very rigid structure with little flexibility. When such a team decides that the advantages promised by Scrum (in terms of more predictability, more flexibility, a higher level of information to the team, ensuring that the team members feel that it is their project, a much better item to demo at the end of every Sprint) are useful enough to do the transition to using a Scrum based project, just the training is not enough. There will be challenges, in terms of issues with respect to the new role of managers, the need for team members to do an empowered role, for them to take on the responsibility of being able to estimate the effort needed for tasks and also executing them, and similar such problems. It has typically been found that many of these issues, along with the variability that comes in when people (team members) get into estimation mode for the various features, can ensure that the progress that one sees in terms of tasks achieved during a Sprint take around 1-3 Sprints to stabilise, and only after that does one start seeing the advantages. This is a fairly normal process and a well adjusted Scrum should know this and know that they need to adjust to such a scenario.
However, when the team is in a high tension zone (because of the pressure of deadlines, or when there are issues regarding morale, or when the former managers / leads of the team are unsure about their new roles), any delay in execution that is otherwise normal in a first time Scrum adoption can cause a lot of jitters to the team and threaten all the work that they have done so far. I have seen such cases where the team managers were already worried that they will lose control over what the team is doing, and more important, whether the project was on time. Now, as per their own planning, there was a calculation about the amount of work that is expected to happen by the end of a Sprint, and as described above, there was some impact of the change in methodology and the team was as much as 15% down in terms of the amount of work done. A quick feedback from the team confirmed that such deviations were expected, and the reasons were also the ones that were expected. However, the trenchant feedback from the former managers (who underlined that they were still responsible for the deliveries from the team) led to the team abandoning its experiment with Scrum, and you can guess that the team did not try Scrum again for another 3 years (that too when more team members joined who were already experienced with Scrum and who pushed for the usage of Scrum). It was only after that the team started seeing the benefits of implementing Scrum.

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>