The Lean, Lean Grass of Home* – DevOps Pt.4

^*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 Toyota¹.  The practice is geared towards the elimination of waste, or in The Toyota Way (Liker, 2004)² 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“³  identifies the following eight, specific to IT:

Waste Element	Examples	Business Outcome
Defects	Unauthorised system and application changes Substandard project execution	Poor customer service, increased costs
Overproduction (over-provisioning)	Unnecessary delivery of low-value applications and services	Business and IT misalignment, Increased costs and overheads: energy, data centre space, maintenance
Waiting	Slow application response times Manual service escalation procedures	Lost revenue, poor customer service, reduced productivity
Non-Value-Added Processing	Reporting technology metrics to business managers	Miscommunication
Transportation	On-site visits to resolve hardware and software issues Physical software, security and compliance audits	Higher capital and operational expenses
Inventory (excess)	Server sprawl, under-utilised hardware Multiple repositories to handle risks and control Benched application development teams	Increased costs: data centre, energy; lost productivity
Motion (excess)	Fire-fighting repeat problems within the IT infrastructure and applications	Lost productivity
Employee knowledge (unused)	Failing to capture ideas/innovation Knowledge and experience retention issues Employees spend time on repetitive or mundane tasks	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:

1. 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.
2. Kaizen: Good enough never is. No process can be thought of as perfect, so operations must be improved continuously, striving for innovation and improvement.
3. 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:

1. Respect: Take every stakeholders’ problems seriously and make every effort to build mutual trust.  Taking responsibility for other people reaching their objectives.
2. 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:

1. 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
2. Liker, Jeffrey – The Toyota Way (McGraw-Hill, 2004) ISBN: 978-0-071-39231-0
3. Waterhouse, Peter – Improving IT Economics: Thinking Lean (CA White Paper, 2008) [no longer linked to on the CA site]
4. Poppendieck, Mary & Poppendieck, Tom –Lean Software Development – An Agile Toolkit (Addison-Wesley, 2003) ISBN: 978- 0-321-15078-3
5. Poppendieck, Mary & Poppendieck, Tom – Implementing Lean Software Development (Addison-Wesley, 2006) ISBN: 978-0-321-43738-9

 

Author

Mark Edwards

I started my career in IT Operations, working in the machine room of a small in-house IT organisation with old VAXen and DEC Alphas.  Since then, I’ve worked on busy service desks, developed enterprise applications and spent the larger part of the last 20 years evangelising in the IT Service and Asset Management space.

I like to think that over the years I’ve managed to see everything that the industry can throw at me, but every single day seems to surprise me with yet another interpretation of some industry (or in-house) standard, so it keeps me on my toes.

I’ve always believed that the various frameworks out in the wild are there to serve as guidelines (except for the bits about interoperability standards) so like to approach projects with a pragmatic view as to how the frameworks can bend and adapt (within reasonable bounds) to the ways that an individual client would like them to work within their business.

Outside of work, I enjoy fast cars, fast bikes and international travel.  Often combining the bikes and travel into off-road adventures in striking parts of the world.