Best practice to utilize one dev team for multiple products.
I started working for a company that has a core product which they fully customize for each client. We have one Dev team scrum board and a separate scrum board which is visible to each client. Currently we map the tickets to the dev scrum board from the clients’ scrum board. The issue I'm facing is with prioritization. Many times project managers are fighting (no literally) to get their tickets in dev before others due to deadlines. This creates a lot of issue and we are not able to become fully Agile.
Any suggestions on how this process should be streamlined so priority on the board is set for the dev team?
One team supporting multiple products is a less-than-ideal situation in Scrum, but I do have experience serving in such situations.
I am hoping that your Dev Team is working from a single list of work, and that the various "project managers" have a subset view of that list based on their area. I will offer advice based on that assumption.
What ultimately helped my team is insulating them from the discussions from the various input-stream owners. The team must receive a consolidated and singular offer to evaluate; otherwise, it is just a shouting match for the team's bandwidth.
I found that by scheduling a pre-sprint planning meeting with just the various PO's for the team helped facilitate such an offer, as different PO's gained awareness of their priority in relation to other work being asked of the same team, and also gained perspective on the other work streams. Whatever will promote collaboration at the PM-level and provide a singular offer to the team should help your situation.
I would also question where these project management deadlines and estimates are coming from, and whether they are truly valid if they are not coming from those doing the actual work.
There are still many inherently poor practices that remain with this approach. Perhaps working with the various project managers about the negative effects of multi-tasking and context-switching may convince them that taking turns with work assignment can actually help finish work faster? Also, there may not be a good understanding of the Dev Team's capacity (perhaps even capacity at an organizational level), which will continue to exacerbate the situation until management takes an honest assessment of what they can potentially accomplish in a given time period.
Good luck!
Who is in charge to prioritize the Dev Team backlog? What does make a Project Manager's ticket more important than another? Are all the Project Managers aware (and agreed) of what does change the priority of an item? Who does have the power to have the final decision?
How many products and Product Owners are involved? If there's one product then there ought to be one Product Owner, and he or she ought to manage stakeholder expectations, including those of any so-called project managers.
3 clients >3 products > 3 project Managers > One Dev Team with 20 developers.
Is it possible to have three Development Teams to work on only one product per team? Each team will work on one backlog with one Product Owner.
3 clients >3 products > 3 project Managers > One Dev Team with 20 developers.
After reading the Scrum Guide, what conclusion would you draw about these arrangements and the streamlined process you seek?
3 clients >3 products > 3 project Managers > One Dev Team with 20 developers.
Fahad, what are your observations about this 20-member Development Team?
The Scrum Guide is explicit about its recommendations for Dev Team size:
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains.... Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.
If you have three clients, three products, and three PMs (Product Owners?), it seems that you are already configured to support three value streams with one Scrum Development Team per product.
Keep in mind, what you have currently is not representative of a "team", but rather a "working group", in my opinion, and you will struggle to recognize any Scrum benefits with this approach.
Thanks for you valuable input guys! I really need to come up with a strategy to organize the process.
Hi Fahad,
I am not an expert but try and split the dev team into 3 teams. 7 developers in Team 1, 7 developers in Team 2 and 6 developers in Team 3. Each team should have a PO.
Would these 3 team of dev share the same source code? Or would the team work on different sources?
As to what goes into DEV ready first it should be up to the POs but to be discussed with their respective dev teams to see what provide more ROI but also mitigate risk to create more issues/bugs in the product.