Agile and Digital Business Clinic: Product Owner/Manager Question
Can you have horizontally organized Scrum teams? An Agile expert explains why you can, but your probably shouldn't, and drops a few more bits of Scrum knowledge.
Join the DZone community and get the full member experience.Join For Free
An old product manager friend writes….
“Just started a new gig as senior product manager at blah blah blah. Discovering that Scrum teams aren't organized around products but rather engineering components. For instance a product manager has to work with three different Scrum teams:
- data science
This makes it hard for Product Managers to manage but I assume easier for engineering. I've not encountered this before. Thoughts?
At any given Scrum meeting there may be two or more product managers, as opposed to a single product manager per scrum team.”
OK, let's see…
The organization is horizontally organized, not good - we’re back to Conway’s Law. Getting anything of business value delivered is probably going to entail getting the frontend team to do something, the back-end team to do something else, and then the data science team to do something.
Now it is possible that that is the way the work falls. It's just possible that a lot of the work falls inside one component, e.g. data science, and that alone delivers business benefit. If the majority of the work is like that then horizontal organization makes sense.
But, in my experience, that is rarely the case, and your comments suggest this is true here too.
Think of it in user story terms: stories rarely relate to one function, you are far more likely to need a little bit from each functional team. No one team can complete a whole story, they need the other teams to do something.
This makes work for project manager types to do - has team A done their bit so team B can start and why isn't team C talking to team A?
The approach normally advocated by Agile folks is vertical teams.
Each team should be staffed to deliver business value itself: if it needs a representative from each function then so be it, if team members need more training, or need permission to go into a different part of the code, then make it so.
Horizontal organization isn't that uncommon, it is usually adopted on the grounds that you need specialists and specialists need to focus on one thing. While you may still need specialists you want people to cross boundaries and be business priority driven.
Then there is the question of product managers and product owners, oh not again…
In this context, the product managers ARE the product owners. Pick up the Scrum book, replace every instance of “product owner” with “product manager” and things are clearer.
And it is OK to have multiple product people in the Scrum meeting - by the way, when you say “Scrum Meeting” do you mean “Stand up” or “Planning” meeting? Either way, it doesn’t matter, you can have two Product people in each.
The important thing, especially if you mean the planning meeting, is: the product people speak with one voice.
Perhaps they have a common backlog.
Perhaps they have a pre-planning meeting of their own to decide priorities.
Perhaps they divide the work up as Strategic Product Owner/Manager and Tactical Product Owner/Manager.
Perhaps they agree one looks at segment X and the other looks at segment Y and they compare notes.
However, if they do it they need to speak with one voice. They need to agree.
A more interesting question is: why do you even have two?
Does each one focus on different markets? Different aspects of the product? Or different time-frames?
It is entirely possible that if you had two vertical teams instead of three horizontal teams that one PM feeds one team and the other PM feeds the other team. During their down times, they both get out and see customers and decide between themselves what the longer term strategy, tactics, and plans are.
Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.