There's still some confusion out there about whether the Product Owner is a member of the Scrum Team. Rather than pile on the confusion, please stick to Ken Schwaber's terms: "Scrum Development Team" for the subset of the team that excludes the Product Owner, and "Scrum Team" for the dev team + ScrumMaster + Product Owner. These are defined by _The Enterprise and Scrum_ (Schwaber 2007).
More on this here: http://danube.com/blog/michaeljames/who_is_on_the_scrum_team
We can debate about if/whether/when we need this distinction, but I'd need to hear a pretty convincing reason to make up new terms rather than stick with Ken's terms.
Related topics:
- Should your Product Owner attend your Daily Scrum and Retrospective? Possibly, but I've seen cases it impeded self organization. A Product Owner seeking higher performance through greater self organization in the long run will ask the development team's opinion on this.
During Sprint execution, team members report to each other rather than any externally-designated leader. This leaves a clearing for leadership to emerge by merit and consent. The Sprint Review meeting is our chance to see how well they kept the promises they made at the Sprint Planning meeting.
Sometimes -- rarely for you I hope -- urgent short-term concerns require a command and control intervention. This creates another kind of debt which may or may not be easy to pay off.
- Should the Product Owner be highly technical? Usually not, but depends on skills and vision, doesn't it?
Modern software engineering practices tend to reduce technical dependencies, allowing business people to prioritize by business value and simpler effort estimates without deep technical knowledge. Of course, one reason we're doing Scrum is to get business people and technical people to learn from each other.
A legacy product steeped in technical debt, where technical dependencies dominate prioritization, will demand a Product Owner with a deeper understanding of the technology (and a technical debt repayment plan).
A "rocket science" project may require a rocket scientist Product Owner.
- Should we have multiple delegate (or proxy) POs for multiple teams?
Maybe sometimes, but we'll regret not tying them to one uber PO. I saw a delegate PO get UNappointed by his chief PO who didn't get the vision -- doing Scrum helped uncover the problem in two weeks.
Another time I saw it working fine because the delegate POs were completely in sync with the uber PO.
Another very large Scrum implementation had local proxies on teams who were domain requirements experts with an extremely busy uber PO prioritizing for all of them.
One way or another we need to increase the bandwidth (and reduce latency) between developers and customers.
--mj
| Attachment | Size |
|---|---|
| Is the Product Owner on the Scrum Team blog.pdf | 133.76 KB |
So, by your refinement, the Product owner is a member of the scrum team, and you use a more refined term (Scrum Development Team) for a non-cross-functional subsection of the team. Does the scrum development team include the QA, UI, analyst, UX roles? I guess I'm asking for clarification because I'm worried about the break-down of the cross-functional team idea.
I'd simply prefer saying "yes, the PO is part of the team" because the PO represents the customer, and the customer should be included in the team.
The rest of your comments talk about HOW the PO interacts with the team. In topic 1, I believe the PO should be part of daily scrum and other meetings, but they also have to understand the difference between themselves and those making the estimates and commitments. If they can't understand this, it needs to be addressed and hopefully the option of buffering/removing them from the team interactions is the fall-back option.
The third topic is an interesting problem, but hopefully this challenge is limited to large enterprise situations.
Great post.
Kevin E. Schlabach
http://agile-commentary.blogspot.com/