The same developer / development team - for several projects
What is the best practice in the following cases:
1) - when one developer is involved in several teams (for example, a designer)
2) - when one team is working on several projects (sprints are time-separated or run at the same time)
- Is it possible to bring everything into 1 mix-backlog and 1 sprint?
- Or is it possible to create 2 product backlogs and 2 sprints. If yes - sprints are time-separated or run at the same time ( If at same time - with separated for each team meetings or glued meetings for both ) ?
Thanks a lot!
Hi Andrey - The issue you have with either your current state situation or two proposed solutions still results in the problem of multi-tasking (which is waste)and impacts focus. Multi-tasking, otherwise known as context switching, makes your teams less productive and may hurt team health. Here is what comes to mind and why I would advise against the proposed options:
- Assuming each Product Backlog is owned by a different Product Owner, wouldn't this cause prioritization conflicts and focus issues for the team?
- Wouldn't having the team attend two Sprint Planning events, 2 Backlog Refinement meetings, etc. be waste?
- If you brought everything into Product Backlog, how would the team be able to come up with a unified Sprint Goal? How would the team stay focused?
Have you asked the team on the best way to organize? Might they be able to split up and each focus on a unique Product Backlog? Can they grow their T shaped skills to become cross functional enough to take on the UX work themselves? If not can the UX dependency get done ahead of the Sprint?
All the best
Well, we all love pure Scrum and it's easy to identify and point out waste and all that. But the reality is that sometimes a team has to tackle more than one product at a time. Some uniquely qualified people have to contribute to multiple efforts at once.
With your UI guy (or gal) - I presume UI here, not sure what a "designer" means otherwise - I would look into a possibility of having him/her working a sprint ahead of the rest of the team. The easiest solution would be to include some level of design / prototyping to the DOR.
With teams switching from one product to another you need to ensure that your product owners talk, are on the same page, understand that not only the team is not 100% focused on their product, but also teams' performance will somewhat suffer. Prioritization for them will become more complex for sure. But at the same time it's not a rocket science - talk to them, have a framework in place for them to agree on and move on. What the teams need to be looking into long and hard is the optimization of their CI/CD, automating as much of the process as possible. This will ensure that not only are they aware of the context switching problem, but tackle it in a very proactive manner and do everything in their engineering power to minimize it altogether.
Good luck, it's not your vanilla Scrum, but it can be done.
I agree with Alex, doing scrum of scrum can be tricky.. as all a scrum master wants a developer doing their stuff.
Overall, its a framework of what really as a group that we are creating value in the next increment. if we can't manage and balance the resource in an agile manner , then I pose the question-- are we agile at all ??
Agile is just not coding /refactoring /redesigning.. its also about people , culture and turning the knob to create value at rapid increments
Thank you guys! Is this a good practice when 2 projects will have 1 Product Owner?
The following configuration : 1 Product Owner , 1 scrum Master and 2 dev teams.
According to Scrum Guide POs and SMs can be members of more than 1 Scrum team.
I guess, as long as they are effective team members, it's all good.