One Core Team working on Multiple Products with Multiple POs
I'm a relatively new SM and have been tasked with overseeing our core 'Platforms' team, which historically has been a team for our own products that members rotate in and out of when not on customer engagements. (A VERY unstable team obviously, with one permanent member) We have decided to now hire a core team of 6, who will be working on 3 products we wish to develop. We use a Scrumban board, have one-week sprints, and there is one Product Backlog containing all the Initiatives & Epics for each product, and different PO's for each. I'm struggling in how I might make the most of this situation, thinking rotation might be my best bet. It doesnt feel like scaled scrum, I want to make sure the engineers are able to achieve the sprint goals and not get silo'd... any suggestions would be appreciated!
Pushing 3 products onto a single team will not cause the work to be completed more quickly. Rather, there are likely to be net losses due to context switching. It's better to limit work-in-progress...in other words, to stop starting and start finishing.
Where does the decision to work on three products right now actually come from, and how has this been squared with the availability of just one team? It doesn't sound like a pull-based decision made by team members who understand their capacity.
How would a decision be to invest in one product, over another; and who would account for that?
any suggestions would be appreciated!
Focus on enabling empiricism, by providing transparency over the situation and the problems it will cause, along with encouraging inspection and adaptation by those who are in a position to do something about it (that might be team members, stakeholders, other co-workers, or management).
It might be necessary to let a flawed system fail, rather than trying to prop it up, and ultimately masking the underlying problems.
+1 to @Ian Mitchell. This isn't even Scrumban as I know it. It sounds more like chaos to me. How are items ordered in this combined Product Backlog? How do the 6 developers know which items to pull in when they have time? Who is ultimately responsible for maximizing the value that the development team produces?
Consider the scenario where you have 1 kitchen that is making food for 3 different restaurants where the menus are constantly changing. Would you actually consider the service to be great?
At least you solved the problem of rotation. A team that frequently changes its composition has a tough time developing and maturing to the point of working well effectively. But another problem (or two closely related problems) were introduced.
Having a Product Owner for each Product does make sense. And, unfortunately, having a team support multiple products is a real situation that organizations face. It's not optimal, but having the three Product Owners can be a setup for spinning out new teams to take over these products in the future.
The biggest issue that I see is the single Product Backlog for all of the products. This is the first change that I'd recommend making. Splitting up the work would help the team order the work associated with each product and identify dependencies. Each Product Owner can be responsible for ordering the Product Backlog associated with their product and they can negotiate with each other to determine which product will be worked on by the team in a given Sprint. The ideal situation would be to focus on one product each Sprint and err on the site of planning goals much less than projected capacity to ensure that there is a clean wrap-up each Sprint should the next one be focused on a different product.
What do the PO's feel not having a dedicated team and competing with resources with other PO's?