Lean + Agile = Devops

Lean + Agile = Devops

October 19, 2017 Agile 0

After this post you will know:

  • Two types of supply chains
  • Difference between Lean & Agile
  • DevOps Basics

 

Before we start our journey of understanding DevOps, we first need to take a few steps back. We need to do this because DevOps is a part of a larger field of knowledge called Supply Chain Management. So that’s where we’ll start:

 


Supply Chains

In short, a supply chain is a system of organizations, people, activities, information, and resources involved in moving a product or service from supplier to customer. The goal of supply chains in business is to create a product (value) and get it to the customer.

An easy way to deconstruct a supply chain is by plotting it against the amount of variability it can handle (Such as product and service flexibility, Volume flexibility or Delivery flexibility) and the amount of volume it can handle. Dr. Martin Christopher has written about this in his article called “The Agile Supply Chain  – Competing in Volatile Markets“.

In it, he described two generic supply chains, Lean & Agile, that exist at opposite sides of the spectrum. An Agile suppy chain is needed in less predictable environments where demand is volatile and the requirement for variety is high. A Lean suppy chain would be best in high volume, low variety and predictable environments.

 


LEAN

Lean is a concept originating from Japan, its purpose is to eliminate waste in a production process. According to Lean, there are 7 types of waste:

  • Defects
  • Transportation
  • Over-production
  • Waiting
  • Over-processing
  • Motion
  • Inventory

By systematically eliminating these through various techniques, any production process can be made as efficient as possible.

If done correctly, the end result is a production process that follows the 5 principles of LEAN

  • Define value from the perspective of the end customer
  • Identify the entire value stream and eliminate waste
  • Make the remaining value-creating steps flow
  • Design and provide what the customer wants only when the customer wants it
  • Pursue perfection

Goal is high efficiency and to create products in the best way for customer. Lean achieves this by using stations that the product progresses through. Once a supply chain is found, it can create only one product, but it could build that product in THE most efficient way.

 


AGILE

Agile’s purpose is to make a product that is as relevant as possible to the customer. It’s characterized by short product life-cycles in order to keep up with a ever-changing demand.  Agility means using market knowledge and virtual corporation to exploit profitable opportunities in a volatile market place.

With Agile, flexibility is the key word:

  1. Product and service flexibility
  2. Volume flexibility
  3. Delivery flexibility

Goal is high effectiveness and to create product as relevant as possible to customer. Agile achieves this by using ‘feedback loops’ to discuss product relevancy. Once the customers demands are accepted, an Agile supply chain can create any product you can think of, but only in relative small amounts.

 


Scrum?

I’ve often heard the (rather confusing) statement being thrown around: “Scrum is Agile but Agile isn’t Scrum”. What the person means by saying this is that Scrum is one way to be Agile. Another way would be to talk to your customer at the end of the day, ask them what they think and change your work according to their demands the next day.

I’ve plotted some Agile  & Lean concepts in the image below. As a bonus I’m also trying to explain why Scrum can be so confusing at times. You see, I know everything from the Scrum Guide, yet I always feel that Agile Coaches are coming up with new and crazy things that they call “Scrum”. It was only after a while I realized that there’s a distinction between the framework “Core Scrum” and the completed structure “Scrum Complementary Practices”.

These complementary practices can really be anything, as long as it follows the Scrum Core rules. This is why you’re never done learning “Scrum” even if you have all Scrum Certificates and know the core guide back-to-back. Like I said, confusing…

 


DevOps

Anyway, back to Lean & Agile.

DevOps is trying to have best of both worlds. It’s trying to be as Agile as possible for the customer, but as Lean as possible during the construction phase. By using Agile & Lean together, teams can re-envision entire Infrastructures via a few simple clicks. It’s kinda like building a house, realizing you don’t like the color, destroying it and rebuilding the house with a new color  – all in a few seconds.

So, it’s a team that’s building software in an Agile way and deploying it in a Lean way.

To really make this work, you need to daisy chain several Lean supply chains together. To keep in the housing business metaphor, it would look kinda like this:

Now, imagine that the Foundation team – the guys pouring the concrete so the house doesn’t sink – found a cool new material that would make the Foundation 10% better. In the classic IT biz, you’d be screwed since now you’re tasked with holding up the entire house as the Foundation team scrapes away the old concrete and pours the new. It’s a really messy job.

A DevOps Team would say, “nah”. Instead of going to the old house, they build an entirely new house – with the new foundation – in a few minutes. Once the customer is satisfied, all he/she has to do is move next door. The old house is destroyed and you’re done. Clean!

Now, there are two important base neccesities required to work true DevOps:

  1. Identified stakeholders – Know what your customer wants.
  2. Coding, building & deploying software – You have to build it in an automated, repeatable way and FAST!

In IT, the ‘Dev’ part requires Agile principles that are normally provided by Scrum. The ‘Ops’ part requires Lean principles that are normally provided by Cloud Tooling.

 

That’s it. That’s really it! I’m always amazed by stuff I read online regarding these subject and how often authors bring all these vague concepts to the table when trying to explain Agile, Scrum or DevOps. (I never understood why people bring up emotions as much as they are when learning about Agile theory, but that’s just me)

I hope it’s useful!