Different Scrum Teams Assisting Each Other - Good or Bad?

Question

I was reading a comment:

It affects empiricism of [the Scrum Team receiving aid] because both the outputs and outcomes of that Sprint have been affected. [...] The professionalism of knowledge sharing is certainly desired, and assisting another Scrum Team is not prohibited by the framework, there are probably more effective ways to achieve the desired outcomes.

And that got me thinking - does it make sense for different Scrum Teams in the same organization to assist each other with their work, or would the loss of stable throughput outweigh the gains in knowledge sharing? If one should refrain, then how should knowledge sharing be facilitated?

Answer 1

My answer and some associated comments (1, 2, 3, 4) appear to have sparked this question.

The original question presented a very specific case - a Scrum team has met their Sprint Goals before the timebox for the Sprint has elapsed. All of the forecast work has been completed and meets the team's Definition of Done. The team is now wondering what they should do between this particular point in time and the conclusion of the Sprint (the Sprint Review and Retrospective).

This situation is not discussed in the current (July 2016) version of the Scrum Guide. For the case of multi-team environments, this particular case is also not discussed in the current (August 2015) version of the Nexus Guide.

I believe the next place to turn to would be the Manifesto for Agile Software Development and the principles behind the Agile Manifesto.

What these guides, manifestos, and principles say to me is this:

The primary goal of an organization that is agile is to satisfy customers and users by delivering valuable software frequently. Scrum realizes these two principles through Sprints, each of which produces a Potentially Releasable Increment. When you have multiple teams coordinating, you integrate the work of all the teams and ensure it is releasable at the end of every Sprint (Nexus gives us more specific guidance and advice, but there are also other frameworks to scale Scrum specifically or agile methods generally).

By overforecasting, one team has put themselves in a position that is not sustainable in the long term. However, sustainability is much lower on the list of principles customer satisfaction, delivery, collaboration, and support and trust. I'm not sure if the list of principles is an ordered list or not, but it seems plausible that it is. Because of the emphasis on delivery of software and customer satisfaction, those need to be the immediate concern of all of the teams involved.

Another agile principle is about giving the development team the support they need and trust to get the job done. That support may come from management or it may come from another team. However, help cannot be forced upon the team - it must be offered and accepted. It may be too risky to add new developers to the mix. They may not have the right knowledge, skills, personality or temperament, and so on to provide valuable help. The team that has overforecast should be aware that one or more members of another team are available and then be trusted to make the right decision that allows for the successful completion of a Potentially Releasable Increment at the end of the Sprint.

After the immediate concerns have been addressed - either getting help to complete the Sprint Goals or not - the Scrum teams can turn to reflecting and adjusting. Again, Scrum has the Sprint Retrospective to do this. The Scrum Master role should also be involved to ensure that the teams learn from the events and adjust their upcoming behavior (how they plan and execute future Sprints). This is the point at which the team that overforecast and the team that underforecast adjust and try to return to a sustainable development pace.

Now, a lot of this does center on an assumption - the Scrum Teams are working on a single product. What if they aren't? Even so, the teams are part of a common organization. This isn't just about satisfying one particular customer or user base. It's about the organization being customer-centric and the individuals and teams that are in the organization responding to changes in the environment around them.

One team providing resources to help another team is only one option. There are others that may also be valuable, but cross-team help is in line with agile principles and should be on the table. So...yes, it may make sense for one Scrum team to provide resources to assist with another Scrum team. This shouldn't be considered the only way to share knowledge across teams, though. Also, since Sprints are projects, adding more people to a late project may make the project later. It's about balancing risks with rewards to meet the desired objectives.

Answer 2

There is a lot to unpack in there. The way I read the answer and associated comments, I interpret it as one team helping another gives the team the false impression that they can do more work than they truly can. He isn't wrong, but I would expect the teams and the Scrum Master to mitigate this. So if the team tried to commit to a same-sized or bigger goal next sprint, I'd expect the Scrum Master to step in and say "Woah! You guys needed help from another team last sprint, is this really reasonable?"

The commentor didn't say this, but one could also argue that it would throw off numbers for both teams. While not wrong, I would reject the argument for two reasons: first, other factors have a far greater impact (holidays, prod support, outtages, etc) and handle those fine; second, and more importantly, you should never do service to the metrics over service to the product.

Finally, our goal is to deliver a great product, empiricism is a tool that helps us do that. Individuals and Interactions over Processes and Tools.

Answer 3

Scrum teams should definitely help each other out.

Add the suggested support as a backlog item and have it prioritised in the usual way.

If the Product Owner sees value in the support then I'm sure they will prioritise the work and make it happen.

The idea of Scrum is to deliver business value. Restricting them to delivering value for just one product would be arbitrary.