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 – Dealing with a team that was hesitant, and it worked only after people actually were changed

If you look at the title of this post, it does not mean that we convinced the people to change; it actually meant that in some cases, people were encouraged to leave for a different group, or when they decided to leave the company, they were not stopped. This seems rather drastic, but it turned out to be the right thing to do. This was another example (from thankfully not my present organization, but from a previous organization) of how Scrum gets labelled a failure in some cases even though there are other reasons for the problems.
Consider the case of a group with a number of senior and experienced people. They are used to their own way of doing things, going off to work for complicated items, being social only when they want to be, but otherwise pretty skilled people. You would not want to lose such people. At the same time, it is also true that sometimes people can be very skilled, but can lead to making or breaking of teams, and you need to get rid of people who can spread problems in the entire team. So, you had a team with many of such people, and things were working fine. However, overall, there was a realization by management and by leaders of the group that productivity was not what it should be, and predictability was something that was a problem. It seemed that even with such skilled people in the team, one would never be clear about what the current status of deliverables is, and whether the project was on the right track was difficult to measure. Replacing the project manager did not help in any way, and the introduction of new ideas did not seem to help.
So, with all the word of Scrum in the air all around us, it seemed that this was the way to go. However, we did not just jump into Scrum; the management of the team went in for training and for intensive Q & A, and worked out the changes, what are the advantages, and what would it do to the normal way of life. And it seemed like some sessions with the team, followed by Scrum training and some simulation exercises should get the team on the right path.
Initially it all seemed to be going fine, with everybody seeming to appreciate the providing of more information and access to the Product Manager, but just when it seemed to be settling in fine, the basic inertia of many members of the group seemed to have overcome whatever advantages. Cribs about the Daily Scrum meetings, jokes about daily reciting of past / present / future (the 3 basic concepts of the Daily Scrum meeting) and so on started causing problems in the team. It was fairly easy to identify the people who were starting to come unstuck, and some counselling seemed to work, but only for some time. It got fairly problematic that the regular activities of the Scrum team starting getting vitiated. Radical solutions were prescribed, and this meant the introduction of more Scrum oriented senior members from other teams, giving the message to many of the difficult folks from the existing team that they really should start working as committed team players, or they would need to start looking out. This radical therapy worked wonders, but is not really practical in many situations (you cannot easily bring in new experienced members so easily).

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>