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.

Subscribe to this blog Subscribe to Leading Agile