Lean Thinking principles in Software Development

In software development, Lean Thinking proposes systematically identifying and eliminating the waste generated when creating or evolving a service. Fran Ávila, Regional Director at Codurance Spain, gave a workshop in which he explained the principles of this philosophy and offered keys to implement it. 

According to Ávila, three stages mark the path of the Lean methodology:

Toyota Production System

The first period runs from 1948 to 1975 with Taiichi Ohno, Head of Engineering at Toyota, who seeks to transform and optimize the processes of production, logistics, and car sales. For 30 years, he developed the Production System, which allowed the company to increase its sales exponentially. Based on three pillars:

  • Just in time: Do only what is needed, when and in the required quantity.
  • Jidoka: Automation with a human touch. Detect, stop, correct and investigate the cause. 
  • Kaizen: Continuous improvement

Lean Thinking

The Toyota Production System beat the Americans in the world of automobile manufacturing. It opened a series of research about procedures. These studies eventually materialized in the book Lean Thinking de James P. Womack & Daniel T. Jones, published in 1996. The concept of Lean is defined as a way of production that allows added value while generating less waste:

A way of thinking about the different activities to generate value and the processes that are inadvertently generated but make that process work worse.
 
5 Lean Principles
  • Value: created by the product owner but defined by the consumer. This allows us to put the consumer at the center and seek to understand what those needs are.
  • Value stream: how value is produced, from the time someone orders something until they receive it, and everything that happens in between. Understanding the value chain makes us see where the inefficiencies are and try to optimize them. 
  • Flow: to provide constant value instead of manufacturing things in lots to ensure the process is continuous. 
  • Pull: work on demand. It is associated with limiting the work in process; instead of generating a lot and then passing it on to another phase, the generation occurs because someone has initiated that need.
  • Perfection: eliminating waste and removing all the parts that add nothing to the process. We must hate Tim Woods, i.e., the inefficiencies that generate waste: Transportation, Inventory, Motion, Waiting, Over-processing, Overproduction, Defects, and Skills not used to the fullest. 

Lean Software Development Principles

The Lean movement originated in physical goods production but has since been applied to different industries. Ávila introduced us to Mary and Tom Poppendieck, the authors of the book Lean Software Development, who took Lean thinking and used it within the software development industry. He then explained each of the principles of Lean Software Development through examples and tips. 

1. Eliminate waste

Making things work. One of the primary wastes is partially completed work because the only thing that produces value is what is done. To overcome this inefficiency, you can, for example, work by branches that allow you to integrate continuously in a practical way. Other activities that generate waste are creating extra functionalities and changes in non-competitive requirements. It is essential to be goal-oriented and to check whether what's created or modified achieves the established goals and offers real value to the final user.

Likewise, constant re-learning or questioning and knowledge transfers generate waste. It's better to record or document processes and promote cross-functional teams that expand knowledge naturally through practice. Task changes, delays, and dependencies between teams create bottlenecks and increase production time. For this, it is better to develop vertical teams that generate value from start to finish. 

Finally, a defect occurs when something does not work as expected, which generates waste by revisiting and modifying the process. A solution for this is automated tests that allow you to check the performance during the creation process. 

2. Build quality in

Put quality at the center of product development. If you consistently find mistakes, your mistake is in the process, and you need to change how you do things. To drive this change, you can prevent bugs before they are found through Agile testing or moving QA to the left. Also, speeding up feedback loops or having executable specifications, for example, through pair programming and TDD helps reinforce the final product's quality. 

Another practice that contributes to maintaining quality is to write clean code. Always look for simplicity and only over-engineer things that you will need. For this, it's essential to understand the problem you are trying to solve and recognize that quality is the whole team's responsibility: PO, QA, and Devs. Rules and quality standards help get the entire team on the same page and aligned to a common goal. The more explicit these rules are, the faster the process of getting a new team member on board.

Finally, pay as soon as possible technical debt, those decisions that are not the best but sometimes you need to take to solve an eventuality. The longer you take to pay for it, the more it will affect your project.  

3. Create knowledge

Learn and pass the knowledge on to others. Planning is necessary, and learning is essential. Use scientific methods to know if the product you are developing works. For example, you can set up a hypothesis, experiment, validate its performance and make a spike. Also, continuous feedback is essential and can come from different sources, such as a beta community, canary deployments, or A/B testing. 

Create standards, best practices, and templates that help do things more efficiently. But also question and update them according to specific situations. To make the transfer of knowledge more digestible, you can change the documentation format, for example, from written to multimedia, such as explanatory videos.

4. Defer commitment

Try not to make a decision that compromises you until it is not necessary to do so. Avoid the idea of having complete specifications at the beginning because you need to have all the information. When you put something off until the end, the last responsible moment, you allow yourself to gain knowledge and make a decision with as much context as possible. To get to this point, consider all possible options and try to have as few dependencies as possible, for example, through contracts or minimal abstractions that allow you to change different things. 

5. Deliver fast

The faster you deliver, the more information you will have, as you will receive feedback quickly. Fast delivery with high quality and low cost is possible long-term. The ultimate intention is that all your investment allows you to deliver faster and at a higher rate.

To measure the time of your deliveries, Avila recommended the book Accelerate, which talks about four essential metrics, DORA: Deployment frequency, Lead time for changes, Mean Time to Recovery, and Change Failure Rate. How often do you deploy, what is the time from when you want to change something until it is changed, what is the recovery time if something goes wrong, and how often does the system fail?

Another way to optimize your deliverables is to limit work in processes. Have T-people, people with more than one specialization, who can do different tasks and provide flexibility by moving through different phases of the process and avoiding creating bottlenecks. 

6. Respect people

A company's most significant competitive advantage is working as a team, having a goal, and making people committed to the group. Therefore, it is essential to create an environment of trust and security where mistakes are not a cause for embarrassment and where constructive feedback is encouraged.

Having autonomy is critical because the best place to make decisions is where the information is. Of course, some decisions need to be made centrally because they have a significant impact. Still, decentralized responses are helpful when you need a quick solution in a specific area.

Respect for people also goes through the recognition of work well done or for an action promoting a behavior or value representing the company. Likewise, building a team with agreements and symbols of identity fosters a sense of belonging and personal satisfaction.

The aim is to generate culture, behaviors, and values that identify a group and each of its members. Culture is what you do when no one is looking. 

7. Optimize the whole

Combine business opportunities with the best technologies. To do this, we have to have a vision of the complete value stream, not just the individual value of specific areas but as a whole. We have to understand the finished product. Software is a part of the product and the service that is provided. You don't just make software but solve a customer's problems through software. The issues are global, not only of the tool built. 

Systems thinking is vital to understand all the components within a system and how they relate. Eliminate silos of thought the more we work in a multidisciplinary way. With different departments, you can generate more value. These actions must be oriented to data that helps us to make decisions that prioritize the whole, such as metrics, NPS, KPIs, etc. 

Summary

To conclude, Ávila summarized the three necessary aspects that should be taken into account in any software development project. 

  • Observe and monitor. We must continually think about how to improve the system and question whether what we are doing is right. 
  • Experiment. Set a hypothesis and test how we can evolve to achieve the best results.
  • Train and prepare. The more prepared we are and anticipate what will happen, the faster we can react.

Links of interest

Lean Thinking, James P. Womack & Daniel T. JonesLean Software Development

Lean Software Development, Mary & Tom Poppendieck

Accelerate: The science of Lean Software and Devops, N. Forsgren, J. Humble & G. Kim 

Blogpost Clean Code

Implementing Lean Software Development, Mary & Tom Poppendieck

Lean Primer, Craig Larman & Bas Vodde

The Perfection Game protocol