Lean Applied to IT

Lean comprises two pillars: jidoka on one hand and just-in-time on the other. These two pillars are closely interlinked and are often implemented together.

Jidoka

The first pillar of Lean, or jidoka, can be roughly translated as “automation with a human touch”. Sometimes the term “autonomation” is used. It involves endowing machines with the ability to detect problems and to immediately halt production as soon as an issue is detected. This concept of “stopping at the defect” is crucial, as it limits the propagation of errors.

By halting production at the very moment a problem arises, one avoids producing defective parts that are passed downstream and potentially integrated into the final product. These faulty components diminish the quality of the deliverable and ultimately reduce customer satisfaction.

Applied to software development, jidoka entails stopping the production of code as soon as an anomaly is detected, and doing so as early as possible. This could be due to an unclear specification, insufficient or failing tests, anomalies revealed by static analysis, typing, etc. Every detected anomaly actually represents a deviation from a specific expectation or standard. Defining these standards is an important aspect of jidoka.

Ideally, these anomalies are detected at the very point where they can occur: in the code itself, that is, within the code editor. The build and deployment pipelines (commonly referred to as CI/CD pipelines) form part of these mechanisms, aiming to halt software production and prevent the delivery of defective software that deviates from the expected standards.

Just-in-Time

The second pillar, or just-in-time, consists of producing only what is necessary, when it is necessary, and in the required quantity. This approach aims to reduce inventories at any given moment as well as production lead times. It notably involves an analysis of lead time, that is, the time required to produce a product from the moment production is initiated until it is completed.

Applied to software development, just-in-time means producing features in small increments and delivering them as soon as they are ready, in order to present them as frequently as possible to end users. This regular exposure allows one to gauge users’ sentiment, their level of satisfaction, and to subsequently adjust future software developments to better meet their expectations.

One of the components of just-in-time is the pull system, which involves triggering replenishment based on actual consumption. An illustration of the pull system would be to initiate the production of a new “user story” only once the current one has been fully developed and delivered to production.

Just-in-time, for its part, is the broader mechanism that aims to synchronise supply and demand.

One consequence of just-in-time is the drive to reduce the size of backlogs, which are essentially tickets specified too early and whose relevance may diminish over time, owing to a lack of regular exposure to end users.