Sunday, September 12, 2021

Technical debt and waste: check trends and act preventively

I will now discuss a concrete case (...I actually found it in several organizations) in which one of the main risks for a software development company is the high level of technical debt for the product and its documentation.
The final effects are the followings:

  • Components difficult to modify and fix
  • Economic inefficiency in developing and maintaining several product variants, as required by the market
  • High risk when technologies need to be changed: components need to be completely rewritten, documentation does not reflect current functionality, but only a long series of change requests, time and cost high now, and impossible to bear in the future.
  • The risk for the future, given that technologies change very often (even if you keep the same technology, it will change at a rapid rate) is infinite.

How did they get here? 

They somehow complied with the basic recommendations for technical debt and flow optimization:

  • Technical debt was not a major impediment… until it became so
  • Flow delays were not a big problem… until they became so

For a while, at any time, they could have told you “Our flow is good, we have no major delays and technical debt does not cause us much trouble"
Important - the technical debt accumulates, it's like in the metaphor with the Boiled Frog. You also need to consider measurements trends and future implications, not just current ones.
My advice about Technical Debt: measure the trends and act preventively.
Likewise, to avoid waste: it is not enough to measure the delays in the flow, this being only the final effect of many sources of waste. Find the various sources of waste, calculate the trend, and take preventive action.

We have more strategies to deal with the waste (read more here):

  • correct
  • correct early 
  • avoid

Tuesday, June 1, 2021

Using Lean - From Solution Discovery to Problem Discovery

CONTEXT: IMPROVEMENT - the problem/solution terms are used here in the context of process improvement. "Problem": a weakness in the process that reduce effectiveness and efficiency. "Solution" - a change in the process that will improve the e&e factors

SOLUTION RECIPES. A typical  "process method" will provide us some solutions with the implicit or explicit guidance to use them as recipes, sometimes as universal recipes.

SOLUTION DISCOVERY. A a much better process improvement approach will provide solution discovery guidance. Your situation is unique, so you need a tailored solution. 

Typical agile methods do not even provide support for solution discovery

PROBLEM DISCOVERY. A robust approach should also provide problem discovery guidance. We need to find out what are the root causes that affect the effectiveness and the efficiency of our work. Optimizing the whole is a fundamental lean principle. Without problem discovery guidance we will not optimize the whole. This is also important because its is often difficult to identify the root cause of visible symptoms.   

Important observation: the two word guidance - "do retrospectives" or "inspect and adapt", is just a title, not a real guidance.   

DA FIRST IMPRESSION. A first impression about Disciplined Agile (DA Toolkit) might  tell us that DA focuses only on solution discovery (that is, anyway, much better that just offering recipes) but does not address the problem discovery aspect. Let's take a look.   

INITIAL DA. There are several aspects that are related to problem discovery even in the initial form of Disciplined Agile.

Capability Map & Guidance - DA organizes its guidance based on process capabilities (process blades and process goals). If our process is in trouble, it is much easy to find out  where the problem is, looking at process capabilities. Here are some examples from DA Delivery (solution development):  Improve quality, Accelerate value delivery, Grow Team Members, Coordinate Activities, Address Risks. All these concepts are very easy to correlate with potential issues and could help to discover where the real problems are. 

Adapt to context -  Letting the team (the people directly involved) decide and adapt to context are fundamental concepts from DA and is strongly linked to a better problem discovery. Enterprise Awareness - is another example of a principle that could help in this direction.

CURRENT DA. Disciplined Agile has continuously evolved and also improved its support for problem discovery

DA has now a generic, holistic, Lean-based guidance for problem discovery. Here are some examples:

  • Optimize the whole - consider the whole value stream, not just teams local aspects
  • Slice the work at business level, not just for development 
  • Asses the process problems and try to find the root causes

There are still some problems to be solved

  • The lean based guidance is based too much on detecting delays compared to detecting the other sources of waste and avoiding waste in general. Se my previous post for more info. 

A STEP FORWARD. My improve proposal is to provide more support for the problem-discovery dimension.

 

A guidance toolkit could be developed for this aspect as well. We can capitalize on the existent knowledge and experience about different types of waste and use this knowledge to more easily  detect our concrete problems in our concrete situation. The content of this guidance could refer:

  • Waste source map. A map for known categories of problems. Description of different source of waste: what kind of actions and behaviors produces such waste and what are the usual symptoms. Here is an example.
  • Lean patterns - see below section. 

LEAN PATTERNS - A pattern describes a category of solutions for a category of problems. There are already many lean patterns, but sometimes disguised as "principles". If that guidance will tell us more about the "how" part, it may not be a principle.


Here are some example of lean patterns

Source of waste: defects. Some categories of solutions that could address this waste: build-in quality, test-first approach, non-solo-work. We can see from the start that there are multiple strategies available to address the defects and multiple possible choices of practices inside each strategy. When an Agile method will tell you that they have one "best practice" for defects that is debatable from the start. 

Source of waste: big inventory that come from use of long releases. Symptoms: increased complexity of work, hard to manage the high number of change request that a longer "project" could accumulate. Category of solution: slice the work and deliver in smaller batches.  

Source of waste: big inventory that come from "parallel work", multi-tasking. Symptoms: lack of focus, increase complexity, delays, defects.  Solution category: serialize the work.  

 

AN INTEGRATED APPROACH FOR IMPROVEMENT

Set up the goal to reduce/avoid waste with whatever strategy works best in your case. 

Use holistic lean principles and guidance 
  • e.g. optimize the whole value stream, try to find the root causes
Use existent knowledge about categories of problems - sources of waste and their symptoms to
  • Identify waste/problems - check if we have concrete problems from these categories: check the symptoms and if any of these sources of  waste are present 
  • Asses the impact of the waste -  to get an idea how much we want to solve that problem
Leverage lean patterns - Use known lean patterns to have an idea about the category of the solutions.
 
Select process capabilities to improve - Use the problem description, the ideas about the impact and possible solutions to select the process capabilities to address.
 
Leverage DA Toolkit guidance about solution discovery and select - for your context - concrete practices and, eventually, bring to life the solution ideas from the lean patterns.   For example you may find more practices that could realize build-in quality, test first approach or non solo work in your context.

Potential Solution! Kaizen. (update) "It's not really a solution until you've verified that it actually solves the problem."- Scott Ambler feedback. Yes, we will identify a solution and then experiment to see if it works. We can use the Kaizen approach - a loop of continuous improvement in small steps, in which each step is an experiment with a new identified "solution". We can even do better than that and use Guided Continuous Improvement with Disciplined Agile Toolkit.

The purpose of this post is encourage the further development of the DA Toolkit (or similar) to fill the gaps from the support for the Problem Discovery dimension.