More on: The Product Owner and the Team

There has been some interesting discussion on this topic recently.  Two things I wanted to add to my prior post.

1. The business side cannot force the Doers to “do all that I say” in the Sprint.

This is of course a well-known rule of Scrum. But this rule does not eject the PO from the Team.

So, in one scenario, the PO cannot force the Team to do all X stories that he or she wants done in the Sprint.

But even before that, the PO should want reliability, meaning, if the Team commits to 8 stories (based also on the known velocity of the team), then at least 8 stories will get done (or done, done — if you prefer) in that Sprint…with a fair amount of reliability.  The PO does some of the ‘real work’ (in the form of providing information about the stories and feedback, mainly), so the PO has a say about what he/she can or cannot do to support the Team that Sprint.

What I usually find in the real world is that the Doers (eg, the coders and testers) want to over-commit.  And the PO (at least) should be saying “no, let’s not over-commit — I and we need to predict for the customer, and we need to know what the Team can really do fairly reliably at sustainable pace.”

But at least the Business side (often in the person of the PO) cannot force the Team to do 8 stories when, in their professional judgment, they can only do 7, as one example.

Exactly how the Team self-organizes to reach that judgment is up to each Team, but ejecting the PO is not an option.  The PO has at least some lights on the problem, and so should be heard, just as, for example, the junior tester has some lights on the problem.

There are many possible scenarios, but these are the basics.

2. The issue of whether the PO is part of the Team is far greater than just the issue of Sprint commitment.

Yes, Scrum teams have problems with the Sprint commitment. All kinds of problems, with multiple root causes. This was partly discussed (indirectly) in a recent post.

But in the shorter term (eg, intra-day) and in the longer-term (eg, release), the PO is an important part of the Team.

Let’s take the Release, and the use of Pareto’s idea of the vital few.  So, the whole team must be optimizing the 80-20 rule at every level of work (tasks, stories, epics, etc.).  And discovering how to do the least amount of work to deliver quickly the best possible product. (Note the reference to Agile Principles.)  This is a Team effort, led in large part by the PO.  But still a full Team effort.  The key related idea is cost-benefit analysis (hey, there’s another new one!)… how to get the most benefit or business value for the least effort.  Again, a joint effort by the full Team.

When troubles arise (and troubles in some sense always arise), who is the Team that will address them?  It is both the Business side and the Technology side together who must collaborate to address them.  We might too easily say that in general, both sides must compromise.  Each side must accept “lack of control” but high “power to influence”, and create some modus vivendi….some way out of the problem together.  How do we do this in a practical manner?  The simple way of saying it is that the full Team (with of course the PO) must figure it out.

Again, there are many scenarios, but those seem to us the basics.

***
Yes, I know there is much ‘legacy code’ in our wetware (our brains, etc.).  But this I think is the way forward.

For example, it may be that the PO is very senior, and at the start is intimidating in the other team members’ eyes.  And, in a short transition period, maybe we make some accommodation to this impediment. But it is not a reason to say that the PO is not part of the Team and should not come to any Team meeting.

« « We must have working software at the end of the Sprint! || Who should fix Impediments? » »