Getting Back in the Game

Okay… time to recap where we are with this whole Scrum Roles/Product Owner/Scaling Agile discussion. My hope was to drop in this morning with a new post… to finish an article I started writing before leaving for the Scrum Gathering. I’ve got to be honest… I was lost. I needed to get my head around where I’d been and where I was headed. I figured you guys might need a refresher as well… so here we are… a recap of my last 10 posts ;-)

Are Scrum Roles Really Sufficient?
https://www.leadingagile.com/2009/02/are-scrum-roles-really-sufficient

This was the first post in our series, and I have to admit… I wasn’t sure exactly where we were going at this point. Every team I work with or coach is trying to map their existing organization to Scrum and there just aren’t enough places to put everyone. Maybe I am making this too hard. Maybe everyone gets this but me. I am getting a sense that the simplicity of Scrum is actually making things hard on people. It seems we need someone to tell us where all our current team members fit… or at least how they might fit and how their jobs are changing.

ScrumMasters and Team Members
https://www.leadingagile.com/2009/02/scrummasters-and-team-members/

I’ve been thinking about the role of ScrumMaster for a while and tended to equate it with the role of the Agile Project Manager. So many traditional project managers think this is where they fit in Scrum… but ScrumMaster is not always the right role. In some ways the ScrumMaster has part of the job of the traditional Project Manager, but not all the job. If it is not all the job… where did the rest of the PM job go? This post also touches a bit of the Team Member role. The team has always been pretty straightforward to me… developers and testers… but what about the BA? The designer? The UX folks?

Product Managers and Product Owners
https://www.leadingagile.com/2009/02/product-managers-and-product-owners/

Much like the ScrumMaster/Project Manager dilemma, many organizations want to equate the Product Owner and the Product Manager. Again… the roles here are really different. Trying to force fit the Product Manager into the Product Owner role is causing trouble on most of the teams I work with. In this post I introduce that the Product Owner is actually one big abstraction for everything outside the development team. They are everything the development team doesn’t want to deal with.

Filling the Leadership Vacuum
https://www.leadingagile.com/2009/02/filling-the-leadership-vacuum/

I’ve been wanting to say this one out loud for a long time. Many teams are struggling because the business wants certainty from the developers but they themselves don’t have much of a clue about what they want to take to market. That’s fine… they don’t have to know exactly what they want… they shouldn’t have to have that figured out up front…. they just can expect to know exactly what they are going to get and when they are going to get it. Close customer collaboration between agile teams and the business helps solve this problem. The role of Product Owner is there to provide direction to the team… to be accountable for making business decisions… to make the hard trade-offs.

The Reluctant Product Owner
https://www.leadingagile.com/2009/03/the-reluctant-product-owner/

Here we introduce a theme that I plan to carry forward into all the remaining posts in this series… the idea of context and coordination. Context provides information about what we are doing… coordination provides information about who is doing it and when it needs to be done. This is a pretty simple problem at the team level and is the sole responsibility of the Product Owner. The challenge that most enterprises face is that they are solving a scaling-agile problem at the same time they are trying to adopt agile. As an industry, we don’t have much experience at this, and we don’t have much experience doing it well.

Product Owner by Proxy
https://www.leadingagile.com/2009/03/product-owner-by-proxy/

As we scale into the enterprise, the role of the Product Owner gets too big for a single person. We have talked about the role of Product Owner containing elements of Product Management, Business Analysis, Project Management, and UX design. They are abstracting the needs of the business stakeholders from the team and translating those needs into actionable requirements. One of the scaling patterns I often see is to name a Product Owner proxy for the team. Typically this is the BA or tactical Product Manager but I have also seen the Dev Manager, Architect, Team Lead, or Project Manager play this role.

The Product Owner Team
https://www.leadingagile.com/2009/03/the-product-owner-team/

Here we introduce the idea that the Product Owner role often needs to be a team of people… all responsible for making sure the team has actionable user stories that can be consumed in the sprint. This team can be led by a Chief Product Owner that delegates responsibility. I tend to want this group to be part of the team, working with the developers and QA folks on a day to day basis. This team has the additional responsibility of making sure the product backlog is groomed and ready for sprint planning. On some teams that responsibity might be held by a single Product Owner… on some a Product Owner and BA… on some teams a Product Manager, BA, Project Manager, and several designers. It’s all very situationally specific.

Feature Teams or Component Teams
https://www.leadingagile.com/2009/03/feature-teams-or-component-teams/

This post get’s off the core topic a bit… but I have a good reason for going here now. We have to decide what are teams are going to build. Do they build features or do they build components. The answer to this question is going to depend heavily on the scale of the product you’re taking to market. Smaller teams… smaller organizations… it is much simpler if you can use the feature team approach. At some scale though… you will have to figure out how to do agile using component teams. The idea of having a small team of people capable of working across the entire architecture breaks down at scale for many reasons.

How you answer this question is going to impact how you ultimately scale the Product Owner role.

Teams are the Building Blocks of Agile Organizations
https://www.leadingagile.com/2009/03/teams-are-the-building-blocks-of-agile/

Many teams struggle adopting agile because they can’t or won’t enforce the team concept… they want to optimize the organization’s resource utilization rather than maximize the team’s throughput. Any conversation about scaling agile has to begin with the idea that team’s have capabilities and teams have throughput… not individuals. The Product Owner role becomes about making sure that the teams have the right context and the right coordination… that they are working on the right things in the right order.

Product Owner or Product Ownership
https://www.leadingagile.com/2009/03/product-owner-or-product-ownership/

If you can buy that the Product Owner does not have to be a single person… you can start to think less about finding a single Product Owner. You can think more about aligning your business around its most important objectives… you can start thinking about product ownership. Decide first if you need feature teams or component teams… next realize that teams have capacity, not individuals… understand that teams have throughput. At that point we are left with deciding how we are going to apply our teams to solve our most pressing business problems.

Product Ownership at scale becomes less about a person… less about a particular role… and more about business alignment and prioritization… more about context and coordination.

Okay… now I’m ready to take this thing forward!