Use delays detection to improve the process

 

SOURCES OF WASTE - there are more significant sources of waste and a good approach to improvement should consider reducing and eliminating these various sources.

WHY DELAYS ARE IMPORTANT - The Delays (Waiting) waste plays an important role for several reasons 

• a great business/process will react in timely manner, so delays preclude a good process
• usually, the benefits of reducing delays are bigger that other improvements 
• we act to improve locally and we forgot the delays between different teams and business units  
• most others significant source of waste will have delays as an effect 
• any delay will produce further delays in cascade

It is obvious that we should discover the delays starting with the inter-teams workflow and we should act with high priority on reducing and eliminating them.  

IS DELAY REDUCTION A SILVER BULLET ? So, knowing how important it is, what would be the recommended course of action for improvement?

A GAME -  Let's play a game: what happens if we relied mainly on detecting and then eliminating delays for improvement?

Is rather reactive and not proactive – It is rather reactive and not proactive - we measure the last effect of different sources of waste and it could be too late: we are already compromising costs, time and quality in a significant way.

We need to be prepared to identify the root causes, not just to measure the effects. So we need to learn and practice by discovering the other significant sources of waste and their common cause.

A classic example: A Scrum team that relies solely on the practices of the Scrum Guide and does not take into account technical excellence and internal quality. It could go fast for a few months, maybe two years and only after a while they will become slower and they will discover the delays as an effect. It is too late! We already have a product with high technical debt and as a consequence: is rigid (difficult to change), fragile (any change will cause uncontrolled defects). The team could solve this debt, but it will cost money and cause other delays. Moreover, the team should start just now learning and practicing how to produce software with better internal quality.

Future hidden delays - delays are sometimes the accumulated effect of our work habits over a significant period of time. Measuring only the final effect - the delays - will be too late and, consequently, a source of more delays and waste.  Even worse - these other waste can instantly induce other waste - avalanche effect -  until we could measure some delays.  

A better approach - we should pay attention, discover, measure and avoid all known significant sources of waste, including those with delayed effects such as lack of built-in quality (which creates defects, modifies delays, corrects delays and more). We should also take into account the trends of wastes, so as not to react too late to these wastes and related causes.

Even better: Guided Process Improvement We measure, monitor and react to all known and discovered source of waste. in case of problems we will fail fast and maybe we will improve in due time. With Guided Process Improvement (which is recommended by Disciplined Agile) we can use knowledge bases - as DA toolkit -  to succeed early instead of failing fast.     

Assess versus Prevent -  Identifying delays is perhaps the power gun for assessing the current problems of the process. However, in order not to end up with significant problems - to prevent them for the first time - we need a much more sophisticated arsenal.  Remember - Lean is about Avoiding Waste.  

 

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.