Multiple concurrent sprints

Ideally probably? That is in a perfect world and in large part that is the way it works. You might be getting that 100% fully committed jargon confused.

The team being 100% fully committed to the delivery of an increment in a sprint.

Here is my explanation it will not jive with some scrum purist on the board but hey I deal in the real.

They can be on more than one team. That goes back to resource and capacity planning which is not really covered in the scum guide. Resource and capacity is a different skill. I have developers who have 100% capacity on one team when they are on that team. And then have 100% capacity on another team when they are on that team. Example I have one developer who has a capacity of 6 hours a day of 100% committed to developer work.  But he works on 2 teams. He works 3 hours 100% fully committed on team A and then pivots to work 3 hours 100% fully committed on team B. Another example in the instance he does not have work on team A on a Tuesday. The teams agree to shift his capacity of 6 hours to be 100% fully committed on team B for that Tuesday.

These are all team decisions not a Product Owner, Scrum Master, or some other level of management.

Many people get stuck on the theory of scrum and try to over think it. Agile Scrum as it says is a container for techniques. It does not say here is how you should do it just gives ideas of how you might do it. Of course, there are what some would call best practices. But I have performed the scenarios above for 12 years not all the time but sometimes when needed.  To which I hear “you are breaking the rules” but sometimes you just have to break them. Agile Scrum or whatever flavor you choose cannot always cover everything.

My understanding is that members of a sprint team should ideally be working on one sprint at a time. For example, a developer shouldn’t be working on two or more concurrent sprint teams.

is this accurate as I can’t see anywhere in the Scrum guide that actually states this

One of the values asserted in the Scrum Guide is “Focus”. If a developer worked in multiple Sprints concurrently, what impact might there be on this?

Ian in my example I gave the real developer I used was focused 100% on each team while he was on those teams.

I don't want you to think I am attacking you. To the contrary, I know you have a great deal of scrum theory under your belt if not by your lengthy list of certifications but by your contributions here. But do you ever break out of theory because real work dictates it?

That has always been a problem I have had with Agile trainers. Sticking to the script at all times. Then I come in as a veteran and say no you can’t do that or yes you can do that and here is how.

I need more of an idea of their dynamic and ecosystem but this can certainly be done.

Here is my explanation it will not jive with some scrum purist on the board but hey I deal in the real.

Dan, I'm not sure what your intention was; but in your first comment, I already interpreted your tone as provocative.

That has always been a problem I have had with Agile trainers. Sticking to the script at all times. Then I come in as a veteran and say no you can’t do that or yes you can do that and here is how.

Ian has just pointed out one relevant part of the Scrum Guide, and has challenged any curious reader to consider the situation in the context of the Scrum Guide.

I don't see that as sticking to the script. It's a valid coaching technique.

People are free to disregard the Scrum Guide.

If they omit mandatory parts, it's no longer Scrum.

If they follow the rules, but don't appreciate the reasons things are put together in a certain way, they might not be getting the best out of Scrum.

I can’t see anywhere in the Scrum guide that actually states this

As Dan says, this can be done. Scrum is a lightweight framework, so where the Scrum Guide doesn't give you the answer, you probably need to work it out for yourself.

Whether it is a good idea in your situation, that is a different matter. Take this as advice, and try to make the right decision with your Scrum Teams.

Having someone work on two teams will often seem the easiest answer, but it probably does have some down-sides, and often it is a sign of a skill silo amongst too few people.

Some might choose to avoid the easiest answer, if it aids transparency, and perhaps ultimately leads to cross-functional Scrum Teams.

Simon take it as you will. I think I will stop posting because when I come here I don't see real answers to real problems that people ask. I am a scrum guide and scrum purist when I coach until I do not have to be. I just would like to see people get answers rather than “well the scrum guide says”. Jason asked a question and I gave him a real answer.

So that is my intent. I struggle at times to discern if many responders have run Agile scrum teams or just cramming to get certs.

I am also that guy who speaks with brevity because it's what's required.  I am not everyone’s cup of tea, but all my scrum teams are productive and happy. 

While I will continue to switch from the scrum alliance certs to scrum .org certs I think I will remove myself from these conversations.

Good luck to you all.

Sorry Dan if you are leaving, but I interpret your tone to be quite provocative and antagonistic.

To directly address one of the points you made, context-switching is a scientifically-proven drain on capacity.   Asking a team member to split their time 50% across two teams does not result in a 100% utilization, but their overall productivity is actually reduced by 20%, and by 20% for each additional initiative they are tasked with.

You are correct that this is not specifically addressed in the Scrum Guide, but there are many ancillary disciplines (process flow, Lean) that do address this.   Perhaps you would benefit from some self-awareness that you may not have all of the answers, and that you can always improve?

Asking a team member to split their time 50% across two teams does not result in a 100% utilization, but their overall productivity is actually reduced by 20%, and by 20% for each additional initiative they are tasked with.

Timothy, do you have a source to support this? I agree that splitting time can be very damaging, so if I can back this up with evidence, that would make it easier whenever I need to raise the issue.

Simon,

Peruse the links below to learn more about the poor effects of context-switching:

https://www.joelonsoftware.com/2001/02/12/human-task-switches-considere…

https://www.psychologytoday.com/us/blog/brain-wise/201209/the-true-cost…

http://www.realization.com/pdf/Effects_of_Multitasking_on_Organizations…

Thanks everyone appreciate all the comments

My impression.

When I read that I have impressions that discussion covers two slightly different perspectives.

1. Splitting time of one person between two teams.

2. Changing context as something what destroys person focus and efficiency.

My opinion.

While I agree with with point 2 in general I am struggling with making equation between 1 and 2.

Splitting time does not equal for me switching context always. I can imagine (even saw it working well) that for some roles it is almost impossible provide amount of work for full time. Event non UX activities/tasks can hardly fill that gap to full time but even if we would do that that would not be good utilization of skills and capabilities. Specially that in big products we have much more than once team and to be inline with guideline all team should be capable deliver increment.

E.g. For UX specialist it is rather hard to ensure full time activities inside one Development Team - at least for me.

I understand that discussion is related to developer (but still some of them can be apply here).

So I agree with Dan. that is very hard in reality make sure to not split time between teams during sprint. 

But I agree also Simon that can be destructive.

Expectation.

So I would be really interested if community can share best practices/experiences/cases how to merge water and fire :).

How we can share team member time and avoid destructive aspect of switching context. Or rather minimize I should write.

In my experience, one way to mitigate specialization that will not be resolved anytime soon (ex: UX) is to have them serve Scrum Teams by request.   Important - they should not be considered a member of any Scrum team; instead, they will float among Scrum teams on an as-needed basis.

Since they are an external dependency for that Scrum Team, it is imperative that their capacity be evaluated as part of Sprint Planning to ensure that they will be available to work on the item with the Scrum team.

This is a less-than-ideal solution though, for many of the reasons already mentioned.

As has been pointed out, yes, a developer can be on more than one Scrum Team. However, as has been pointed out, certain issues may arise that will not arise when a developer is on only one Scrum Team.

I'd like to add one of those issues, as I haven't seen it mentioned in this discussion:

Conflict of Interest. If the sprints go smooth and everything is well, switching between the teams might be possible (if the loss of productivity through context switching has been mitigated/accomodated somehow). Problems arise when one, or both, sprints go wrong. If Team A has to scramble to meet its Sprint Goal, will the developer stay with Team A to help them achieve it? Or will he switch to Team B to meet his obligations there?

Moreover, regardless of the decision he makes, what will be the impact on team dynamics in the teams? It's not a capacity issue, it's a human issue and it needs to be kept in mind when making the decision to have a developer on multiple Scrum Teams.

Hi, Can someone please let us know what's the final answer to this? Is the scrum guide allows the parallel sprints? 

There is no final answer.  There are guidelines, suggestions, ideas but in the end the final answer is what is best for your organization. The Scrum Guide doesn't actually allow anything. It provides guidance and a framework with which to work in order to provide some structure and consistent behavior. 

However, you should really consider whether having 1 person working on 2 different teams at the same time is the best use of that person's abilities.  When you factor in the context switching required to do this will be individual actually be as productive as they could be? Will they be providing the full value that your company is paying them to provide? Will their work be as high quality as it would be if they were allowed to focus on one set of problems at a time?

The discussion above provides some really good guidance and many thought provoking questions.  Personally I don' think you will be able to get a better answer than what has already been provided.

IMO, if we can minimise this approach wherein a developer is serving 2 teams, do so. If not, just like what Daniel Wilhite mentioned, we need to consider that person's maturity and abilities in handling this scenario. In my previous employer, we only use this approach on lead developers because our management assumes that they are mature enough to know the pros and cons of context switching or multi-tasking.