Advice for grouping people for several products
Hi forum,
At this time, I have 2 teams consisting of 5 TM's in total, grouped like this:
- Team A: 3 TM's working in 2 products (P1: average, P2: complex) with 2 PO's who are also domain experts.
- Team B: 2 TM's working in 3 products (P3: simple, P4: simple, P5: complex) with 1 PO and 3 domain experts.
Every team has his own SM and share a QA specialist from other teams (50% +/-).
P1 and P2 are really different with different clients also. At this time, P1 is in stand-by waiting P2 to finish soon (higher priority).
P3, P4, and P5 have something in common (same platform: ODOO) and share same client.
At this time, I am experiencing some overhead in both teams (e.g. many meetings trying to coordinate with other technical areas), mainly because both are small teams not self-sufficient. Also having 2 SM's seems to much for such small configuration.
So, I was thinking about merging both teams and assigning a QA specialist full time, but that solution doesn't seem to fit well because of many PO's.
Is it worst having small teams of 2 TM's (1 PO) and 3 TM's (2 PO's), or one single team of 5 TM's with many PO's?
Can you suggest me how to handle this configuration.
Hi José,
Within your comment, I detect a few things that you may want to reconsider, if you use Scrum.
- How many Product Owners does the Scrum Guide say should be on a Scrum Team?
- Do you feel your approach to team selection is compatible with the self-organizing teams described in the Scrum Guide?
- What advice does the Scrum Guide provide about the size of Development Teams?
- What does the Scrum Guide say about different roles within the Development Team? What impact could assigning/unassigning these roles have on the team and its members?
- Are all products complex enough for Scrum to be a useful system?
- One of the Scrum values is focus. Is focus important to your organization?
What potential risks and benefits do you see from allowing team members to focus on:- being in a single team
- working on a single product
Can you suggest me how to handle this configuration.
Instead of you making the decision, why not let the teams self-organize? Why not encourage them to find the best way to create “Done” increments of the various products?
What can you do to put transparency over any dependencies which emerge, and what else might you need to do to facilitate and inform their decision?
Thanks @Simon for your time.
I am aware about what the Scrum Guide says, that is why I am struggling with this situation. According to your questions, Scrum as a whole does not fit well in this situation.
"Focus" is kind of a wish for every manager, but in practice multi-tasking is what every manager here asks for. So in practice, real life projects need a creative solution but always based on best practices.
That is why I am asking for advice in this forum, willing somebody has experienced something similar during his agile journey.
Thanks also @Ian.
Letting the teams self-organize was my first move. It worked fine until overhead started to be a serious impediment, so TM's started to ask me for guidance.
I was trying to find a better way to arrange teams according to Scrum Guide. Sadly every arrangement was in opposite to some part of the Scrum Guide (Team Size vs Product Ownership vs Value Stream).
I know I am trying to find the best of the worst possible scenarios, but I am still positive about improving both teams productivity.
By the way, I found a real case googling a bit:
https://www.boost.co.nz/blog/2018/04/multiple-product-owners-scrum-case…
Any other advice would be really appreciated.
"Focus" is kind of a wish for every manager, but in practice multi-tasking is what every manager here asks for.
Focus is one of the 5 Scrum values. If you are not promoting Focus, you are not doing Scrum.
That said, perhaps your initial efforts should be spent educating your management on the perils of multitasking?
https://www.psychologytoday.com/us/blog/brain-wise/201209/the-true-cost…
https://www.joelonsoftware.com/2001/02/12/human-task-switches-considere…
http://www.realization.com/pdf/Effects_of_Multitasking_on_Organizations…