LeSS adoption without frameworks

I have advocated to balance framework focus with experiment focus in the use of LeSS. As the framework focus is already strong, I’d like to elaborate more on the experiment focus. Is it possible to adopt LeSS without adopting its frameworks? I think yes, as that is actually continuous improvement inspired by LeSS experiments.

Continuous Improvement inspired by LeSS experiments

Let me explain this in two parts - continuous improvement and inspired by LeSS experiments.

Continuous improvement

The purpose of LeSS adoption, be it framework or experiment, is to improve product development. To continuously improve, two things could help.

1. a continuous improvement cycle, based on year/quarter/month, release/iteration/sprint, etc. Though a framework often brings a cycle of continuous improvement, we don’t really need a framework to create a cycle; life is full of cycles:)
2. an improvement approach such as PDCA. We define improvement topics, design and take actions, learn and adapt. In order to improve the quality of improvement, we may apply systems thinking, referring to the article “Practice Systems Thinking: 2) from Fishbone Diagram to Causal-Loop Diagram” for more information.

Inspired by LeSS experiments

While defining improvement topics - what & how to improve, we benefit from learning about LeSS experiments. We may start from analyzing problems, then seek inspiration from LeSS experiments for possible causes and solutions, even redefining problems. We may also start from LeSS experiments, then seek opportunities to improve our own situation. I call it the meeting of problems and experiments.

Where do they meet? a system model. We analyze problems and learn about related LeSS experiments in one system model. Although one experiment can be a unit of action, it is not really a good unit of learning, because a group of them share a context, and it is more effective to learn them in the larger context altogether. This is consistent with the suggestion to analyze problems in the larger context. The system model provides this context.

An example - improve legacy code

Let’s say, we have an improvement topic on legacy code. We may define our problem as “legacy code slows us down”, and our action as “rewrite the legacy module A”. We put this into a system model and the below can be one way. I name B1-loop as “rewrite to clean legacy code”.

Let’s learn about related LeSS experiments for inspiration. There is a chapter called legacy code in the 2nd LeSS book. The first thing you notice would be that those experiments are grouped into two parts: one is how to avoid creating new legacy code; and the other is how to clean the existing legacy code. In fact, that’s a typical stock & flow thinking - if you identify some variable as stock, you think about its inflow and outflow; even though CLD doesn’t require explicit differentiation of stock and flow - they are both variables in CLD, we benefit from this thinking for more completeness. So, we refine our model by separating/adding legacy code related variables.

We continue reading the chapter. The first part is how to avoid creating more legacy code, and the below is a list of related experiments.

• Avoid…Fixed content with unrealistic deadlines
• Try… Transparency and customer collaboration
• Avoid…Hiring many weak developers
• Avoid…Believing universities teach development skills
• Try…Increase organizational support for learning development skills
• Try…Support more self-study
• Avoid…Trivializing programming
• Try…Raise awareness of the negative impact of legacy code

There are two major causes for creating legacy code: one is the unrealistic schedule, and the other is the poor developer skill. While reading through them, we further refine the model.

As you notice, the model is expanded a lot. Let me explain them piece by piece.

B2-loop is a typical response for a gap between expected output and actual output, and I name it as “pressure for more output”. Then, R1-loop shows an unintended consequence, and I name it as “hurry/tired developers create legacy code”.

B3-loop is another response, and I name it as “hiring for more output”. Unfortunately, hiring good developers takes time, shown in the model with a delay. When we can’t wait and do it in a hurry, we hire weak developers instead. Therefore, more hiring causes lower developer skills, further creating two more unintended consequences.

R2-loop shows one unintended consequence, and I name it as “weak developers are slow”. R3-loop shows the other unintended consequence, and I name it as “weak developers create legacy code”.

With the help of this system model, we learn more deeply about the related experiments, such as “Avoid…Hiring many weak developers”, “Try…Increase organizational support for learning development skills”, “Try…Support more self-study”, etc.

Continuing further the second part on how to clean existing legacy code, the below is a list of related experiments.

• Avoid…Rewriting legacy code
• Try...Clean up your neighborhood
• Try…Write both high-level and unit tests
• Try…Rewrite lethal legacy code

Finally, we see the experiment related to our initial B1-loop. Wait, there are two related experiments - one is “Avoid…Rewriting legacy code”, and the other is “Try…Rewrite lethal legacy code”. This is interesting, why both avoid and try? we dig deeper… leave it for your own learning:) Then, I add B4-loop for “cleaning up your neighborhood”, which is another path to clean legacy code. The below is the updated model.

So, what are LeSS experiments in the context of this system model? They are influencers for the system; they influence certain variables, links, and loops.

After seeing all those variables and dynamics, we may still decide to take the original action - rewrite the legacy module A. Besides, we take another action to ”raise awareness of the negative impact of legacy code”. Meanwhile, we understand that these actions are only for this cycle of continuous improvement, and we will continue to work on this improvement topic later.

In this example, we started from an improvement topic and one action, then moved to learn about the related LeSS experiments for inspiration. We saw variables and dynamics we didn’t see earlier; we learned ways to influence that we didn’t think about earlier. However, we can also start from LeSS experiments and contemplate on the problems that they try to influence but that are not yet into our view. It is like that we dance between our problems and LeSS experiments on the stage that a system model provides.

Final words

This path of LeSS adoption is less travelled, but it is in the origin of LeSS. When we look at those published LeSS case studies, they are mostly adoptions of LeSS frameworks. Actually, I look forward to seeing more cases of LeSS adoption without frameworks.