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.  

The mother of all wastes

Let's describe your product from problem point of view.

(you know... Problem / Solution ... )

You may have 10 categories or problems to solve with an average of 15 problems per category and each problem will have an average occurrence of 100. So, simplifying, you need to solve 150 distinct problems and a raw total of 15 000.

So, ideally, you can solve a problem once and re-use it for 100 times. That could simplify a lot your product and the overall work. Of course, a solution for a repeating problem could have improvements and it is difficult to go back to already implemented parts and adapt every time to the latest form of the solution.

Sadly, the most common reality it is much worse.

Yes, you will rather have up to 100 different (~ too many) solutions for the same problem. Each "solution" will have other logic and other conventions so the overall complexity will increase exponentially.

What about improvement?

You will have a better solution in time, but (these better solutions) will not be re-used as you may think. In fact, the degree of reuse is rather related to the degree of existent usage.

Can we call this "creativity"?

No, we can call this one of the types of waste by over-processing. ... and because it is such common situation it is a candidate for the supreme title of "the mother of all wastes".

Root causes?

Many engineers have the belief that they are some "pure creators", some artists. They forgot about re-use and they forgot about consistency. So, we are producing some kind of expensive "luxury products", where too many things are "hand-made" and too few are standardized. Also, too many times they do not talk enough to each other in order to harmonize the solution and share their experiences.

Then what is the software creativity?

It is the creativity of a mathematician and of an engineer: as much as possible make the things that are similar in a similar way and things that are different in a different way.

How is that creative?

You need to use your creativity to simplify, to reduce the complexity because complexity is your generic problem to solve. And at the same time...

... continuously find a better solution for each problem, while minimizing the number of solutions in use for the same problem.