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:
– front end
– back end
– 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 lets see…
The organization is horizontally organised, not good – we’re back to Conway’s Law. Getting anything of business value delivered is probably going to entail getting the front end 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. Its 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 aren’t team C talking to team A?
The approach normally advocated by agile folks is Vertical teams.
Each team should be staffed to delivered 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 is’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 do be business priority driven.
Then there is the question of product managers and product owners, o 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 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?
Do each 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. In between times they both get out and see customers and decide between themselves what the longer term strategy, tactics and plans are.
| Reference: | Clinic: Product Owner/Manager question from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
