Why should the PO attend the Daily Scrum?

Umm. Good question.  We partly discussed this in an earlier post.

First, the Scrum Guide (2011) does not require that the PO attend the Daily Scrum.  If you asked Jeff Sutherland his preference though, he would say it is better if the PO attended regularly.

OK, but why?

Well, first, the Team needs to know it is a Team. The PO is part of the Team. Yes, he is different than the others. Much like a hockey goalie is different than the other skaters.  But still part of the Team.

Often the key is: how to get Business Value and  detailed requirements into the Team?  It is not going perfectly, yet. This is very often the biggest problem. There are several ‘laws’ of software development that speak to this.

The PO is key to solving this problem.

So, the PO comes to the Daily Scrum to hear about progress (or lack thereof).  We must be careful saying it that way. The PO has a kind of leadership role, it is true. But he is not the ‘boss’ the Team ‘reports’ to. This is not the approach we want in Scrum.

We want the whole Team, including the PO to be in the same boat.  Maybe the PO is like George Washington in that famous picture. Everyone is doing things to ‘manage’ the boat toward success. They are all ‘in this together’.

The PO could ‘comment’ on Team progress. Again, careful.  What do you mean by comment?  If the Team has a question the PO can answer; during or just after the Daily Scrum, he will ‘comment’ or answer.  The idea is not that he gets to, in a big boss kind of way, stand above the Team and critique ‘the other guys’.  In Scrum the PO is part of the Team. They win or lose together.

Maybe the PO tells the Team the tasks they will do?  NO!  Even that, in a different way, we must be careful how we say it.  The PO as such would never define and ‘force’ the tasks on the Team. In part, because the PO is normally a business person, and would not even know which tasks need doing. We want the full Team to self-organize, and define their own tasks.

From a certain point of view, each PBI (product backlog item or story) represents work, and in a sense represents a ‘task’ for the Team. In that way, the PO is the person who does the final ordering of the Product Backlog. So, if the Team completes all the PBIs they ‘committed to’, then the PO can ‘give’ them the next PBI to work on in the Sprint.

The PO could  determine if the Team needs help.  Umm, again, careful how you say it.  Yes, the PO could  hear the answers to the 3 questions. The ensuing discussion could be long (busting the 15 minute time box), so the PO may only be able to identify that help is needed, then provide the help after the Daily Scrum.

Now, who actually identifies that the help is needed? Well, it could be anyone, so the best way to say it is that the Team (including of course the PO) identifies that help is needed.

One final reason why the PO attends the Daily Scrum. The PO should give his own answers to the 3 questions. Why?  In part because he is a Team member (meaning, he is a member of the Scrum Team, not that he is doing ‘Team role’ work).  By reporting to the Team, over time everyone starts to see how integral his work is to Team success.  Yes, the PO’s work is different. Yes, his work is not as tied to the current Sprint as it is for the Implementers. Still, the whole Team needs to understand how all the work is connected to the Team’s success. (If this is not clear, it needs to be explained to the Team.)

Could we imagine some ‘misunderstandings’ between business and technology at the beginning that could lead to some ‘awkward’ conversations?  Yes! This is good!  Now the Team will be addressing real, hard, and difficult issues.

Could conflicts or tensions get out of hand?  Yes. The SM must manage the conflict. Making it more useful rather than ‘just conflict’.

***

OK, that’s what I think. What do you think?

« « Latest ‘Agile Release Planning’ ebooklet || Scrum 201: Team » »