*with apologies to Curly Putman
Welcome back dear reader to this, our fourth instalment on the DevOps journey. So far, we’ve taken a look at the foundational principles of DevOps, affectionately known as ‘CALMS’, and have explored the first two in some depth. So, we now come to the third principle – ‘L’, which stands for Lean.
Lean is a widespread and generally well-understood practice in most industries, and is more of a mindset than a methodology, so I’ll approach it in a slightly different manner than previous posts. First, we’ll begin with a short history lesson and explore its origins before moving on to what it means in practice.
~
The Lean methodology originally stems from the Japanese motor industry – although it has origins much further back than this. The term first being used by John Krafcik in an article he wrote in 1988 based on his experiences at Toyota1. The practice is geared towards the elimination of waste, or in The Toyota Way (Liker, 2004)2 the improvement of flow or evenness within a process.
Lean identifies multiple types of waste that need to be eliminated in order to improve flow:
- Muri– Literally translates to ‘unreasonableness; impossible; excessive’ and relates to the unreasonable work imposed on workers and machines by management. Essentially asking greater performance from a process than it can handle without skipping parts of the process. Muri is often a cause of multiple variations in a process.
- Mura– Literally translates to ‘unevenness; irregularity; inequality’ and relates to how work is implemented. Elimination of Mura adds directly to the improvement of flow throughout a process through the removal of bottlenecks and excessive, unproductive work.
- Muda– Literally translates to ‘uselessness or futility’ and relates to everything that is in direct contradiction to value-added work (i.e. things that detract directly from your process or product).
Originally, Lean identified seven types of Muda, although over time various authors have added others. Peter Waterhouse, in his 2008 paper “Improving IT Economics: Thinking Lean“3 identifies the following eight, specific to IT:
| Waste Element | Examples | Business Outcome |
| Defects |
|
Poor customer service, increased costs |
| Overproduction (over-provisioning) |
|
Business and IT misalignment, Increased costs and overheads: energy, data centre space, maintenance |
| Waiting |
|
Lost revenue, poor customer service, reduced productivity |
| Non-Value-Added Processing |
|
Miscommunication |
| Transportation |
|
Higher capital and operational expenses |
| Inventory (excess) |
|
Increased costs: data centre, energy; lost productivity |
| Motion (excess) |
|
Lost productivity |
| Employee knowledge (unused) |
|
Talent leakage, low job satisfaction, increased support and maintenance costs |
So, now that we have a foundation in identifying the types of waste that Lean attempts to reduce, how does it go about doing so?
Essentially it breaks down into two guiding principles – Continuous Improvement and Respect for People. These each break down further into more basic principles:
Continuous improvement:
- Challenge: Having a long-term vision of the challenges you need to face to achieve your goals, or what you need to learn rather than what you want to do.
- Kaizen: Good enough never is. No process can be thought of as perfect, so operations must be improved continuously, striving for innovation and improvement.
- GenchiGenbutsu: Go to the source to see the facts for yourself in order to make the right decisions and create consensus in order to ensure goals are attained at the best possible speed.
Respect for People:
- Respect: Take every stakeholders’ problems seriously and make every effort to build mutual trust. Taking responsibility for other people reaching their objectives.
- Teamwork: Develop individuals through team problem-solving.
If you cast your minds back to the second part of this series where we looked at the culture required for DevOps, you’ll start to see the direct parallels to Lean thinking where we enable our development and operations teams to collaborate and empower them to make their own decisions.
~
So, how does this all directly relate to DevOps? Well, most development and management methodologies that are key to DevOps are directly related to or complement Lean. For example:
- Agile, Scrum and Lean Software Development methodologies (and their variations)
All of these methodologies rely on removing waste from the software development process by breaking down work into clearly identified packages which can be delivered in short, discrete time slices. By reducing lead-time and eliminating non-value activities on projects they aim to increase delivery velocity whilst simultaneously reducing the number of defects that are delivered, thus increasing customer satisfaction. Tools such as Kanban, and the Deming Cycle (plan, do, study, act) are fundamental to these methodologies. - Six Sigma
Six Sigma focuses on removing the causes of defects and the variation in processes by using statistical management tools to monitor quality. Can be combined with Lean to provide statistical rigour to the metrics and measurement of your continuous improvement efforts. - CMMI
The Capability Maturity Model Integration helps to improve processes and process integration by providing a framework against which the existing organisation can be benchmarked. Unlike Lean, it does not focus on waste elimination or complexity and can thus be viewed as a counterpoint to Lean. - ITIL
The IT Infrastructure Library provides a best-practice framework for the management and operation of key IT governance procedures. It is entirely compatible with the objectives and methods of Lean, through careful implementation of its concepts and policies - COBIT
Control Objectives for Information and Related Technology is another set of IT Management best-practices in a similar vein to ITIL. Primarily provides metrics, processes and best-practices to maximise the benefit of IT and achieve compliance with regulations and align IT investment with business objectives.
You will probably recognise many from the above list from within your own organisation.
With the adoption of Agile practices to your DevOps organisation and teams, you will find that the efficiencies and waste reduction and process smoothing espoused by Lean naturally follow after the initial adoption period.
The ongoing challenge is to identify how you can continue to apply Lean principles to your existing processes and eliminate observed waste, apply continuous improvement and define adequate metrics (or refine existing ones) to monitor both the quantity and quality of what, and how you are delivering.
References
There are many publications relating to Lean thinking and Lean IT, below is a small sample of recommendations if you want to read further:
- Krafcik, John – Triumph of the Lean Production System (MIT Press, 1988). Available as a free download from the Lean Enterprise Institute (pdf): http://www.lean.org/downloads/MITSloan.pdf
- Liker, Jeffrey – The Toyota Way (McGraw-Hill, 2004) ISBN: 978-0-071-39231-0
- Waterhouse, Peter – Improving IT Economics: Thinking Lean (CA White Paper, 2008) [no longer linked to on the CA site]
- Poppendieck, Mary & Poppendieck, Tom –Lean Software Development – An Agile Toolkit (Addison-Wesley, 2003) ISBN: 978- 0-321-15078-3
- Poppendieck, Mary & Poppendieck, Tom – Implementing Lean Software Development (Addison-Wesley, 2006) ISBN: 978-0-321-43738-9
