The Product Owner at Scale
Okay… everyone caught up now?
It was kind of neat to spend the time yesterday going back over all those old posts and interesting to see how the process of writing this out has shaped how I look at the whole Product Owner and scaling issue. The timing of the Scrum Gathering was good too. It was nice to get down to Orlando and talk to folks about how they are applying this stuff out in the field.
Last time around I said that the Product Owner at scale was really an issue of Product Ownership in the enterprise. How are we going to get all our teams working on the right things so we end up with a cohesive and integrated product? The key to having this conversation at an enterprise level is to have a thorough discussion around how we are going to handle the three key enterprise Scrum teams: the design scrum… the development scrum… and the QA scrum.
Product Ownership becomes a matter of deciding how to identify all the backlog items, at the beginning of the project, so we can effectively assign work and make sure the entire scope of the project is accounted for.
The role of the Product Owner… or the Product Owner Team is to break each backlog item into a design story… a development story.. and a test story. This is critical for normalizing the input to the team and making sure that each team has plenty of backlog items to work on… and most importantly… the right backlog items to work on… in the right predetermined order!
I mean… how can you write software before you have created the specification? At some point this becomes just common sense!
That said… because of the nature of Scrum at enterprise scale, some teams will inevitably have less to do at certain times in the project.
It was really cool to hear Ken Schwaber (during his keynote at the Gathering) finally discuss that to effectively scale Scrum, we need to put more definition around how to matrix people and teams across multiple projects. Ken’s point was that multiple project assignments and matrixed management is the only way to normalize velocity in an enterprise Scrum implementation.
Next post we’ll talk about the other mission critical teams that enable enterprise Scrum. We’ll talk about the BUFD scrum team… the Governance scrum team… the PMO scrum team… and the centralized process improvement scrum team. We’ll introduce some key tooling concepts like the Scrum Market Requirements Document and the Enterprise Scrum Gantt Chart.
Remember… if you do a daily stand-up and call requirements backlog items… you are probably doing Scrum! See you guys on the 2nd.
Comments (6)
V. Lee Henson
I especially like that this falls in line with what I learned about the new command and control structure at the Scrum Gathering! This may be your BEST Agile post yet! Cutting edge! It is about time people found the benefit of planning ahead and assigning things out!
V. Lee Henson – AgileDad
http://agiledad.blogspot.com
johnfmoore
Really good post, looking forward to seeing your follow-up. If you have a chance, check out one of my recent posts on why I love the daily standup and let me know what you think:
http://johnfmoore.wordpress.com/2009/03/29/why-i-love-the-daily-standup/
John
http://johnfmoore.wordpress.com
Laura Brandau
Hi Mike,
Again great post. And thank you for helping me think through the agile product owner role. I think there is a tension between upfront planning and just-in-time planning. If you get too far ahead in your specifications it can be more cumbersome to respond to change as you learn through the agile process. If you take the pre-planning too far, we are back to an iterative nearly waterfall type process. If you forego pre-planning sprints can quickly degenerate in terms of the value produced because the details are unknown and people spin their wheels.
You might be interested in some comments from Bob Hartman on my blog about the product owner role and whether this fits “inside” or “outside” the context of a sprint. We’re all forging new ground here…exciting stuff!
http://www.bridging-the-gap.com/thinking-outside-the-project-implied-responsibilities-of-an-agile-product-owner/
Best,
Laura
http://www.bridging-the-gap.com
Mike Cottmeyer
I have had a lot of folks take this post seriously… it was totally intended to be an April Fools post. I am going to have to think through the implications of this ;-)
Mike
Dennis Stevens
It’s not funny until the BUFD Scrum Team. I just though you had gone off your rocker a little at the Scrum Gathering and it was time to reel you in a little. In retrospect, the separation of QA, Dev, and Design into independent Scrum teams should have been a warning signal.
It is interesting how important the discussion of the Product Owner is. With all the challenges organizations are facing around this issue, this is probably not a time to joke about it.
Mike Cottmeyer
Your right… I tried to be over the top and obvious… but the post was too subtle until the end.