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 – There is the reluctance to allow the team to be self-empowered and modify some processes for their betterment

In the previous post (Team not being ready), I talked about how in some cases, the team has not been properly positioned into Scrum, and as a result, have not understood the benefits; and in some cases, they are introduced to an implementation of Scrum without the required training or at a time of stress, and cannot adequately benefit from Scrum (in fact, at such times, it is very much possible that what they are experiencing is not Scrum per se, but a process whereby the strains have caused people to modify the process into something that apparently gives them more control).
In this post, I will talk about an important part of what makes Scrum successful, the ability to give the Scrum team more power and more empowerment, and the effect that this has on the regular managers in the team. This was struck during a conversation between 2 managers who are part of the organizational structure in a team that is implementing Scrum, one of whom is also the ScrumMaster, and the other who is the manager of all the development people in the Scrum team. The net problem was what one of the managers told me: “I believe my responsibility is to be more of a coach rather than the conventional manager role that we see in software development processes”. I totally agreed with what the person told me, and the problem was not in this statement; it was that this manager believed that the other managers in the team had not got this, and it was difficult for them to give the kind of independence that the team desired.
One key effect was seen whenever there was something like an introspection, or a retrospective, whereby team members would suggest some modifications in the process, or in the technologies or designs used, and this would conflict with the views of the senior team members of the managers. Any of these more senior people would use slightly more forceful language or a sharp response (inspite of earlier discussions that they needed to let the team take more authority, and act in the nature of a coach, so that if some view was not practical or workable, the discussion would make that fact come out); using such a tone would effectively shut down the person who would be making that comment, but when later questioned, the person would admit that such an exchange of opinion seemed to be different from the practices of Scrum that was taught to them during the training, and it was difficult for them to reconcile such differences. Many of them understood that the managers did not easily want to give away authority, and this was fairly consistent feedback.
To correct this, we are now doing more training sessions for the managers to get them more accustomed to their roles as a coach who needs to get the team more empowered and ensure that the team feel comfortable in getting more improvements into the 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>