Lean as the core of the Agile transformation
A KPMG study carried out in more than 17 countries shows that 81% of organizations have undertaken at least 1 Agile transformation over the last 3 years, and 63% declare that implementing Agile is their strategic priority. At the same time, the disappointment of Agile and Scrum is growing, where the transformations have failed to bring the desired results. Why? The reason is that Agile transformations themselves are not carried out in the Lean spirit.
Agile draws heavily from Lean. It can’ t do without Kanban or Scrum that allow to really implement it in the organization, and which come from this methodology. However, it is worth going back to basics of Lean to understand why sometimes Agile transformations do not bring the desired business results.
Let’s start with a simplified definition of the purpose of implementing lean methods, which is to eliminate waste. Both in terms of excessive production, through uneven loading of elements of the production line, to low-quality products that do not provide value to the customer (e.g. are part of a complaint, return or lack of customer satisfaction).
The origins of lean and its basic principles
Lean historically refers to an efficient production line. Imagine that the projects we manage are intended to continuously deliver value without wasting resources (including time, finances, hardware downtime), but also to eliminate the production of defective or incomplete products.
There are 5 basic principles at the core of lean:
- Deliver value to the customer.
- Identify the stream of value delivery to the customer.
- Focus on the flow – optimize your product/service delivery flow.
- Design the process so that each step is followed by another.
- Keep optimizing the process.
- Visualize the process.
This is how the basics of the Agile transformations can shed new light on them. Agile meant as an iterative work in short loops focused on delivering value works well as a first step in the process of organizational change. However, to ensure that the delivery of a product, e.g. a software, a building, a financial product, is effective, efficient and on time, it requires implementing a well-functioning production line, meaning adding Lean methods to this mix.
3 steps to build a design and production line
STEP 1: Products and subproducts
Back to the production line metaphor. No one builds a production line on which a car is constructed entirely. The construction of each product means from a few to several thousand sub-products, forming the final product. For a car, these will be e.g. gaskets or engine components.
In order to optimize production, a car manufacturer usually subcontracts the production of components to companies specializing in specific subproducts. As a result, the manufacturers do not waste time to switch between the production of various parts, they provide a high level of precision in their production, so the sub-product is of high quality and the cost and production time is optimized.
Splitting the main product into smaller iterations, which consists of e.g. user stories delivered in sprints, is nothing else than just splitting the main product into subproducts. To make splitting the main product into subproducts effective, we should remember::
- repeatability of production of particular elements,
- dedicated production line matching the subproduct specification,
- the possibilities for entities (persons, departments, organisations) to specialise in particular products,
- the granularity of sub-products in the process.
Organizations performing the Agile transformation often make a mistake here and continue to maintain a traditional organization scheme built on the basis of the business domain or technology used, rather than splitting up into teams that aim to deliver specific subproducts in a repetitive process. This is a source of enormous waste at the organizational level.
The Agile transformation in IT is a perfect example:
- The division by business domain is e.g. the division into IT products for the travel industry for airlines, travel agents or tourists,
- The division by the technology used is often a division by competence, e.g. back-end, front-end, testers, etc.
The division into teams in which the process of delivering specific subproducts is repetitive would make more sense. An example of such repetitive processes is for example
- the process of developing a website based on WordPress,
- the process of developing an Android mobile application,
- the process of integrating the web platform with mail servers for sending e-mail communications, etc.
A significant proportion of the steps are repetitive in each such process. They can be closed on a finite task checklist and thus measured in terms of quantity and quality. This also enables the visualisation of the flow, ensuring that the individual steps of the process are linked to each other, as well as providing a stream of constant delivery of value to the customer. Because of the repeatability of the process we are also able to better understand the needs of our customers.
Thus, concluding, it enables us to carry out the principles of Lean efficiently.
STEP 2: Quantitative measurement
Another difficulty associated with the business validation of Agile transformation success is often the lack of measurement of its real business results. No wonder – without repetitive processes it is extremely difficult, time consuming and expensive. However, how to determine whether something is a success without measuring the scale of that success?
In a repetitive process, measuring is simple. Lean tells you where to start.
Set the flow rate of value delivery in the process – it should be measured first. The measures of the process value stream delivery can be different. The basic ones are:
The construction industry is a perfect example here. Let’s say that the project concerns the construction of a single-family housing estate. We will have here a series of repetitive processes e.g:
- the process of pouring concrete,
- the process of installing the roof,
- the process of screeding,
- the process of laying paving stones around the house,
- the process of installing lightning conductors, etc.
It’s easy to see that some of the processes provide key value for the customer and others are side processes. The key measure to be measured will be the downtime between construction crews. Minimizing it reduces costs and at the same time maximizes profits (the time-to-market time is shortened and the number of products delivered per unit of time is increased, and thus the company’s profit is higher).
Naturally, to measure the real connection between downtime optimization and cost and profit, it is necessary to measure::
- cost of production of 1 product,
- the cost of one process,
- profit per 1 product.
The starting point is the measurement of the real time of processes and their components.
STEP 3: Quality measurement
Focusing on time optimization can lead to neglect of quality criteria. Hence, the next step is to define quality factors for product reception and each sub-product.
Back to the example of a production line: a quality controller is a key role when it comes to production. So are clear acceptance criteria. Production companies understand perfectly well that even a single defective component can affect product sales and returns.
The lack of quality criteria in the process, however, is often a problem that bothers companies operating in the design spirit. Therefore, during the Agile transformation, quality validation in the process is crucial.
The key quality measures depend on the industry, they might be:
- a number of complaints / changes,
- number of quality control errors detected,
- the cost of complaints / corrections,
- profit/savings resulting from the reduction of complaints,
- customer satisfaction indicators, e.g. NPS, % of customer returns, LTV.
Agile without Lean is not Agile
Agile was founded as an idea of agile software development. It has spread to other areas of life, such as project management – not only in IT. However, Agile roots are based on Lean methods, adopting their soft side (people over processes and tools, cooperation with the client over formalities, a working product over documentation, responding to changes over following the plan).
However, we forget that the word “over” in the Agile Manifesto does not mean giving up processes, tools, formalities, documentation or plans. All these elements are also important for the success of projects and products that result from them.
Moreover, it should be noted that Agile was defined at a time when repeatability of processes in IT projects was difficult. At that time, IT companies operated in a situation of constant change and dynamic development. However, after 30 years of digital transformation, the need to build repeatable processes as well as to standardize and measure them can be observed. Agile’s return to the roots of Lean would not only make its business value real, but also enable its further development.
Articles aren't enough?
Would you like to learn about the whole process and how we could carry it out in your organization?