Skip to main content

The same developer / development team - for several projects

Last post 12:32 am March 5, 2018 by Alex Kudinov
5 replies
04:51 pm February 21, 2018

Salute!

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!


05:25 pm February 22, 2018

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

Chris

 


12:55 am February 25, 2018

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.


01:56 am February 27, 2018

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


11:27 am March 2, 2018

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.


12:32 am March 5, 2018

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.