Single Scrum Team with Multiple Projects / Products
We currently have one scrum team working on a single product and it works great.
The rest of the developers are split across smaller teams of 1 or 2 developers, each working on individual products. Each of these has it's own backlog and product owner. Then we have one individual that handles fixes and improvements to multiple existing products, which is basically managed by Kanban.
This all works ok, but I'm not convinced it is the best approach. E.g. The lone developers working on a product have limited support, code reviews, testing resource and nothing gets done when they are on holiday or sick.
My question is whether we should consider merging the smaller teams into a single or a couple of scrum teams that work on multiple products. I have read around the affects of task switching and realise this may be an issue.
Does anyone have any practical experience of this? The benefits I can see might be less meetings, more knowledge sharing, a better chance of code reviews getting done, support from others to get pbi's done by the end of the sprint, more consistent estimation and planning, continuation of projects when developers take holiday, etc.
We would need a good product owner able to take decisions on the split of projects. We are planning to take on more developers, but in the interim I'm wondering if this is a valid solution until we can get closer to 1 team per product / project? Also, should we bring our Kanban developer into the team too?
Thanks
Jared
> Then we have one individual that handles
> fixes and improvements to multiple existing products
This implies that the various products involve similar skills and/or technology stacks. If that is the case, it may indeed be viable to combine developers into 1 or 2 teams.
You don't *necessarily* have to find a single PO who can order and prioritize a common Product Backlog. As long as a team does not work on more than 4 products it can run weekly sprints alternating between backlogs. Each product is thereby serviced at least once per month and the task-switching boundary is subjected to clear control.
The person currently allocated to support may be included as a full team member. Given that there will be ongoing ad-hoc support requirements that may affect *any* product, and not just the one being currently worked on, the team can reduce its Sprint backlog capacity to accommodate this work. It is up to the team to self-organize and decide who actions any unplanned support requests...and this needn't necessarily be the currently assigned "support guy".
If an approach like this is acceptable, I suggest running it for a while as it may prove to be more efficient. A more informed decision about how to expand the team with new hires can then be made.
Thanks for the feedback. Having heard from you and looked up other sources, it seems the solution to our problem is to reduce the number of projects we work on simultaneously (e.g. to max of 2 per team). That will increase throughput for those projects and not introduce a major context switching issue.
Thanks
Jared
Jared,
We had a very simiar situation to yours. In our case we found out, that for real, we have one product for now, so we merged every little team to the biggest one.
Please think, if you don't really have 1 product. If not, still there can be one developers team managing 3 products. But it has to come with one Product Owner who sets the priororities in a backlog combined from 3 other product backlogs.
The benefits are obvious
Filip