Agile

Lean vs Agile. What is the difference, really?

Oftentimes both terms are mentioned in one and the same breath, but are they interchangeable? Where do they come from?

On Lean.

Lean as a term is coined in the 90ies and reflects the ideas and practices behind the Toyota Production System (the car manufacturer). Lean is short for Lean Manufacturing and aims at focussing the production effort to generate true customer value by reducing everything else (which is considered to be waste). It’s basically a way to make manufacturing systems customer centric.

The key concept in lean-approaches is waste or, as it is called, “Muda” (Japanese for waste). Next to this direct waste (Muda), oftentimes the terms “Muri” and “Mura” are used, designating secondary waste stemming from either overburden (Muri) or from unevenness in workloads (Mura).

The reverse of waste is “value” and is, in Lean, defined as any action or process that a customer woud be willing to pay for.

This implies that in order to become Lean every process is evaluated against the customer relevance and either considered a waste or a value-add. In a service organisation this entails often that the whole meeting-approach is turned upside down (and slashed), a strong push towards automation, eradicating multi-tasking, etc. The time expenditure is geared towards the things of which the organisation knows customers will need in the future and aim for a delivery as-fast-as-possible.

The emphasis of Lean is on the system “as a whole”. There is always a helicopter perspective at play and micro-management is shunned (micro-management generates non-value-added work, which is exactly what is not acceptable in a Lean system).

Related concepts are:

  • Six Sigma: set of techniques and tools focussed on eliminating defects and reducing variability (6 sigma variance is a statistical concept by which is designated that, in case of a production line the output is 99.99966% free of defects, or in short: 3.4 DPMO (defective features per million opportunities)
  • Value Stream Mapping: method for analysing the current state of the system and designing the future state: the core to many system improvement initiatives.
  • Kanban: an inventory-control system to control the supply chain. It is the key planning tool in a lean system. A Kanban (Japanese for Billboard) is a card that states the inventory going in, being in and going out of each subprocess or task. It enables you to see the backlogs, where inventory is being built up, etc. In short where the potential for the creation of Mura and Muri exists.
  • KPI of Key Performance Indicator and Balanced Scorecard: means of tracking the system as a whole, focussing the value-add of the customer and evidentiating the interrelationships between the customer, financial resources, organisational capacity and internal processes. It’s a way to track the execution of the company’s strategy.
  • The Deming Cycle: Plan-Do-Check-Act (which is core to continuous improvement or Kaizen).

In short the lean principles are:

  1. Define Value: you need to understand what brings value
  2. Map the Value Stream: how to create and deliver the value to the customer
  3. Establish Flow: create a continuous stream end-to-end
  4. Implement Pull: make the customer aware and nurture the perceived need for the value (the customer has to be aware that there is value produced): no pull, no production
  5. Work to perfection (continuous improvement)
  6. And: mind the waste 🙂

On Agile.

Agile was launched in 2001 and comprises a set of principles put forth in the infamous Agile Manifesto and stems from the software industry as a reaction against the heavyweight methodologies that were the norm and out of frustration because so many projects were never really delivered upon within time and budget.

Agile starts with a set of values which are at its core:

  • Individuals and interactions over processes and tools: i.e. self-organisation and motivation through e.g. co-location, working in pairs…
  • Working software over comprehensive documentation: focus on the added value (working software) over wasting time on writing lengthy manuals
  • Customer collaboration over contract negotiation: not all the software requirements can be clear at the start of a project. Therefore a continuous involvement of the customers is necessary throughout the project
  • Responding to change over following a plan: quick responses to change and a continuous development

The typical work method is called the Scrum which is a flexible, “holistic” product development strategy where a development team works as a unit to reach a common goal.

A scrum team consists of people fulfilling 1 of 3 roles:

  • Product Owner, representing the stakeholders and the voice of the customer. The PO is responsible for ensuring the team delivers value to the business. Typically user stories are used to point to the value components. (S)he manages the so-called product-backlog: what needs to be developed.
  • Development Team: responsible for producing and delivering the chunks of value (called: potentially shippable increments or PSI) at the end of each Sprint. A sprint is a block of time reserved to work on an item of the backlog. Usually the period spans a couple of days to a month.
  • Scrum Master. This is not a team leader, but the person responsible to “hold the space” and make sure the team can deliver free from distractions from the outside. (S)he also ensures that the sprint runs smoothly and according to the rules. The role is that of a team facilitator or servant leader.

On Lean + Agile.

More and more we see a combination of both Agile and Lean approaches melting into one. This is especially true in a start-up/scale-up environment where scrums make it difficult for larger chunks to be handled (unless they are arbitrarily cut up in smaller pieces). A Kanban approach can provide the overall framework and the handling of larger workpieces while scrums allow for the nimbleness and the self-organisation and feedback benefits.