Introducing Lean thinking to DevOps

DevOps seems to be on everyone’s lips right now. It has surpassed Agile and become the newest and blackest of blacks.

The definition I’ll give it for the purposes of this blog is “…a lot of technical stuff done using strangely named products with the intent of creating a frictionless and smooth flow of value to end users”. I mean, Chef, Puppet, Git. Who names these products? Nevertheless, the important part of that definition rests in the last ten words; a frictionless and smooth flow of value to end users.

When thinking of flows of value the first thing I see in my mind's eye is Lean, which has been used to deliver smooth flows of value since about 1947 at Toyota, and since the early 2000s in IT thanks to visionaries such as Tom and Mary Poppendieck and David J Anderson. This is the first of a series of blog posts where I will try and explore core Lean concepts and how they relate to DevOps. So, where to start? How about the end?

The end in this case is value in the user's hands, and right before that is all that DevOps stuff that involves lots of ‘deploys per day’. From a user or client’s perspective the number of deploys per day is only relevant if there aren’t enough of them. For an Amazon or Trade Me that might be thousands of deploys per day. For a government agency that might be once a week, or even once a month. You see it depends on how often I (as a customer) need new value in my hands.

Here I want to introduce my first Lean concept; Takt time. Takt is a German word for tempo or beat and it has been used for many years in Lean manufacturing to describe a production cadence dictated by the needs of the customer. It is one of three fundamental ingredients of Just in Time production, the others being a pull system and continuous flow. Essentially, customer demand ‘pulls’ new products through the overall production pipeline at exactly the rate at which they are used.

So, if we think about that in terms of DevOps, it means we synchronise our delivery of value to the cadence required by the customer. Not too much (as that would use resources better invested elsewhere), and not too little (or we start to get ‘air gaps’ in the value pipeline). That means we must start with the end in mind. We must agree with our customer how fast is fast enough.

We cannot get caught up in fondness for tech toys, nor should we go significantly faster than other parts of the value stream. If changes also require new policy, regulation, operational procedures, user training, etc. then we need to be synchronised. Obviously this may sound strange to IT peeps, who for many years have been the thin capacity-constrained pipe through which all change must go. But the reality is we cannot afford to go too far in the opposite direction. Just as inventory in physical production can be seen as an asset (with associated storage costs), inventory in IT could be an asset, or it could represent the waste of over-production. Features don’t sit well on the shelf…

So how do we do this? We can set a work in progress (WIP) limit on the release process that is calibrated to the average time it takes to deliver a feature. This creates a genuine pull system (rather than just releasing everything ready on a set date, which may overload the business with change).

If there is no "pull" from the business (e.g. their capacity for change has been reached) then the system will slow and then stop based on the WIP limits above. At this point the team has many other good options; it can see what it can do to help the business get ready for more change, it can deliver value for another part of the business, it can spend time on process improvements or paying down technical debt, etc.

Looking only slightly further upstream from the deployment end of DevOps, that Dev part of the value stream is already suffering from ‘air gaps’. Most Agile teams I work with have a common complaint; how difficult it is to get sufficient input from business SMEs and decision-makers. That will be the subject of another blog post.

To summarise: make the most of DevOps, it offers some real advantages. In the short to medium term DevOps should allow IT to be much less of a capacity-constrained resource and serve many customers with just the right amount of value. But also recognise that Dev, and Ops, and all those tools with funny names sit within a much wider context, and the overall aim is “…a frictionless and smooth flow of value to end users”.