Scale Your Product Owners
From the Taking the Plunge Blog
by Aaron Porter
In case you actually read this description, the beginning of the blog is about preparing for the PMP exam. It then evolved into maintaining my credential. While maintaining relevant credentials is important, it doesn't make a good long-term topic. Watch for experiments, some serious topics as I try out new things and "take the plunge", and maybe a little bit of fun.
Recent Posts
Whose Idea Is It, Anyway?
Rejuvenating Your Career
Which Certification Should YOU Get Next?
Volunteering and Change
My AI Writing Experiment - Conclusion
Categories
Agile,
Artificial Intelligence,
Business Acumen,
Career Development,
Certification,
communication,
Exam Prep,
Influence,
Information Technology,
Innovation,
Job Duties,
Lessons Learned,
PDU,
PMP,
Project Management,
volunteering
Date
A few weeks ago, I was fortunate to be able to attend the Scrum@Scale certification course, taught by Jeff Sutherland and Kim Antelo. There is a lot, from this class, that I could write about, but I'd like to focus on just one topic that I think is critical to effective Scrum, Scrum transformations, and scaling Scrum: Product Owners.
If you have multiple Scrum teams that are working on different features for the same product, you need to scale your Product Owners. I'll explain what I mean by that in a moment.
When you take the Certified Scrum Master (CSM) class, you learn the basics of leading an individual Scrum team as the Scrum Master (leading in the sense of a servant leader, not a manager). When you take the Certified Scrum Product Owner (CSPO) class, you learn the basics of participating on an individual Scrum team as the Product Owner. Neither class goes in depth into what to do when multiple Scrum teams are working on different features of the same project. I wouldn't expect them to; it's not the purpose of either class.
You might hear mention of Scrum of Scrums in the CSM class. If you're not familiar with the concept, a lot of people think of it as a combined standup meeting where a representative from each Scrum team reports on his or her piece of the product. They don't go into as much detail, and they only bring up blockers that can't be addressed at the team level.
In Scrum@Scale, the Scrum of Scrums is actually what you might call the Team of Teams. The meeting, described above, is called the Scaled Daily Scrum. Do you see what is missing? If you're going to scale your Scrum teams, you need to scale your Product Owners. Why wouldn't you have a scaled, refined, prioritized backlog, a roadmap that covers the features that each Product Owner is responsible for, and a team of Product Owners that is responsible for these things? This is called the MetaScrum, and it is sometimes missing when a company is trying to adopt Scrum. Without this, your Scrum of Scrums, whether you consider it a team or a meeting, will be less effective, which means you won't be delivering value as quickly as you could be.
For more information on the terms I've mentioned and how to scale both Scrum teams and Product Owner teams, please refer to the Scrum@Scale Guide - https://www.scrumatscale.com/scrum-at-scale-guide/.
Posted on: March 01, 2019 04:17 AM |
Permalink
Comments (6)
Please login or join to subscribe to this item
Rami Kaibni
Community Champion
Senior Projects Manager | Field & Marten Associates
New Westminster, British Columbia, Canada
Aaron, thanks for sharing the info regarding the course you recently attended. While I see your point about having multiple product owners and while it is sometimes a necessity, I think it might have a negative effect and things might get lost by having multiple backlogs and multiple product owners. I like the Nexus guide concepts of having an integrated nexus team, multiple development teams and scrum masters but I am more in favor of having one master backlog and one product owner where possible.
RAJESH K L
Project Manager, PMP| Bharat Electronics, Bengaluru, India
Bengaluru, Karnataka, India
Alok Priyadarshi
Project Manager| Tata Consulting Engineers Limited
Jamshedpur, Jharkhand, India
Excellent article on understanding of Scrum in multiple team environment. It is very well explained.
Thank you Aaron!!
Aaron Porter
Community Champion
IT Director| Blade HQ
Payson, UT, United States
Rami, I think the key to what you wrote is "where possible." It's not always possible to have one PO for all related teams. You may not need to scale for every product. In Scrum@Scale, where needed, you have a chief PO that drives the vision for the product. The POs for the various scrum teams report up to the chief PO and coordinate with each other. I'm oversimplifying, but the point is that when more than one PO is needed is needed, there is still one unifying voice responsible for the overall backlog, roadmap, etc...
Rami Kaibni
Community Champion
Senior Projects Manager | Field & Marten Associates
New Westminster, British Columbia, Canada
I agree with that Aaron - We are on the same page - Cheers !
Luis Branco
CEO| Business Insight, Consultores de Gestão, Ldª
Carcavelos, Lisboa, Portugal
Dear Aaron
Interesting is your approach to the topic
Thanks for sharing
I think this concept is closely related to the team team concept proposed by Gen. Stanley McChrysta, Tantum Collin and David Silverman in the book Team of Teams: Rules of Engagement for a Complex World
I confess that I need to read the book to delve into the subject and have a sustained opinion
Please Login/Register to leave a comment.
|
"Nothing travels faster than the speed of light with the possible exception of bad news, which follows its own laws."
- Douglas Adams
|