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: Ensuring that the Product Owner and the team don’t have a breakdown

And when I say breakdown, I don’t mean the nervous breakdown (although it does come to mind when you are working for a project where everything seems to tense, the project is behind schedule and the confidence level is low) :-). If you have been in Scrum teams where there is a lot of tense relations between the Product Owner and the Scrum team, you know what I am talking about. Well, why do you think that there can be tense moments ? Well, there is always the perceived confusion between authority and responsibility, and this makes the life of the Product Owner very tense, especially when it comes to having a single interface between the senior stake-holders of the organization and the project.
One starts with a single base assumption. For everybody who is not very interested in details of how Scrum operates (and this can be many many people outside the Scrum team, including those with a lot of influence and authority), they need to have a single person who supposedly is responsible for the output from the project. And guess who this person is ? It would be the Product Owner (the name itself says everything) who in the end is typically held responsible for whether the project delivers or not. You could ask about the scrum master, and that might happen if the Scrum Master is somebody who is a senior figure, but that is not true in all cases, with the Scrum Master possibly being another member of the team itself (I have known teams where the member of the team who was interested in some kind of managerial experience was given training and then made as the Scrum Master; it is another matter that they may have done the job well, but you would not expect managerial folks to hold such a Scrum Master responsible for the project).
However, the execution authority is with the team, and that is how it is expected to be. You have the Scrum team being empowered, having the authority to decide on the actual day to day execution; the role of the Product Owner is to decide the focus of each Sprint cycle and decide on the User stories (functionality), but in the end, the delivery from each Sprint is dependent on how well the team is doing. The Product Owner can only do so much to ensure that the work is happening (he/she could ensure that the User Stories are clear, that people do not have any doubts about the desired functionality or the workflow). But, when things get challenging in terms of delays, that is when there can be a breakdown in terms of relations between the Product Owner and the team. A stressed Product Owner, seeing that work is not happening as per expectation (in many cases, the expectation would have been ambitious, and the Scrum team really would not have been able to deliver what was planned for) could step in a lot more. For example, during the Daily Scrum meeting or other meetings, a stressed Product Owner could start demanding some improvements in productivity, or even be more sarcastic or scathing than desirable, even try to guide the team.
It is the role of the Scrum Master to perceive when something like this is starting to happen, and try to head it off. For example, when the Product Owner is frustrated, it is the Scrum Master who has to remind the Product Owner that one of the highlights of Scrum is it presents the state of progress as it is in reality, not like what somebody hoped it would be. And even if the Product Owner does want to have discussions with the team, the context of the discussion should be more in terms of trying to determine whether the team sees any issues, or thinks that there are areas where productivity can be improved. Such discussions reinforce the notion that the team is still dominant in terms of execution, but that critical members of the team see some areas of improvement.

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>