Whole team, dependencies and context

 Whole team it is an interesting agile concept that could bring more benefits

• enables organization around the product and services and usage of cross functional skills 
• reduces work dependencies between teams 

Reducing dependencies it is important because it will avoid some sources of waste such as some significant delays. 

However, you cannot do always all the work inside the team. Examples:

• work can exceed the team's capacity for a period of time
• you may need some special skills that are not usually required
  
  

Here are some example of options

• collaboration with Enterprise Architects
• collaboration with others teams 
• collaboration with members from other teams
  

Any external dependency could lead to unexpected delays and other subsequent waste. A good idea to reduce these dependencies is to include these collaborators in the team for a while. Replace external de dependencies with internal ones. Is it extraordinary or not?

Once upon a time (true story) ... a customer pays to "borrow" a team member instead of buying development services. At first glance, it was a much cheaper solution. Three moths later, the development company has to rewrite that part of the code. What happened? An independent team member could not provide the same quality of service as being part of a dedicated team for that product.

Let's study a few cases. 

Case 1 Collaborating teams. Two teams of Agile products (team A and team B) collaborate with each other. Each team works collaboratively: using non-solo work/pairing and collective ownership of all artifacts. The only major problem is the dependence between teams, which could cause delays / waste.

Case 2 New team member supplements the missing team capacity.  Team A will borrow a developer to team B for a period. The new team member cannot be 100% effective because need to learn and practice what is specific to the new team. The collective ownership in team A is broken for a while. 

Case 3 New team member provides services for changing product B. Team A no longer depends on Team B? What about the collaborative work and collective ownership of Team B? What happens to the quality of service when changing product B?

We cannot just move people between teams and pretends to reduce dependencies. We want to reduce some delays but we can introduce others delays and also other sources of waste as poor quality and knowledge gaps. 

A starting point is to consider the whole, not only inter-team dependencies, but also the effectiveness of each team after the change. There are no simple solutions. We need to talk with both teams and involve them in creating a collaboration scenario that work best in the context.