DevOps has been instrumental in transforming IT responsiveness to business, as is evident by the fact that we have enterprises from all walks of life including Banks adopting DevOps. It’s certainly not a thing that hip web companies do now. However, with this rush to “do” DevOps comes the noise associated with it and hence, the confusions.
I’ve been asked quite a bit off late we’re practicing Lean Kanban already how would DevOps help us? or even Do we need to do DevOps when we’re practicing lean? This blog is an attempt at two things, at showing how DevOps borrows Lean principles and it’s really not an either/or equation between these practices as they complement each other.
While there are many definitions of DevOps the one I like to stick to is:
A cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while automating the process of software delivery and infrastructure changes.
While there wasn’t necessarily anything more to DevOps than an observe and solve sort of cycle initially. Over the years we’ve had a more formalised way of working in DevOps. I’d still say most of it is common sense but then creating a structure or nomenclature does help majority of human beings to identify better. DevOps therefore has certain principles that make up most of what we know as DevOps today.
Most of us would know Lean well enough; the classic definition in IT industry context is
Lean IT applies the key ideas behind lean production to the development and management of IT products and services.
And to know more about Lean Production you can start from here. Let’s look at the lean principles before I elaborate on this blog’s theme.
AFAIK the There ways of DevOps first appeared in a blog-post by Gene Kim, and there’s been quite some commentary (include criticism) on them. I won’t delve into just what the three ways are, but into how they appear derived from lean to my eyes.
The first way looks at maximising flow of work from the “left” (business idea) to the the right (finished product); represented by the, rather deceptively facile, diagram
Gene Kim uses the word Systems Thinking for the first way, which basically is the practice of looking at system holistically and studying how its parts are connected or dependent so as to improve the overall system performance. And goes on to explain how we should maximise the flow of value through the system as a whole, using the Deming Cycle to ensure delivering value. While another (I’d say better) interpretation is Flow. Where the flow of value is to be maximised from business to customer. Studying each step of the flow, analysing bottlenecks and solving each of the parts in context of improving the whole.
If you stop here and look back the aforementioned lean principles you’ll notice where this might be stemming from. It essentially appears to be a mandating principles 1 to 4 in this form. Which makes sense too, I can passionately argue you cannot really define the flow of a system as a whole without a meticulous study of each of the parts into a value-steam so essentially you’d be applying Lean when you’re working at this first way of flow. If you were to implement the first way you would invariably deploy these (in addition to other practices)
It’s for this reason I believe the first way is an application of Lean to the entire delivery pipeline, unlike Scrum (or similar Agile practices) focused largely on development practices (unintentionally).
The second way is about creating amplified feedback loops between each steps of the flow or parts of the system, other than providing critical operative information to teams this essentially is a step towards eliminating overburden and inconsistencies thereby reducing waste in the system. Let’s see how, when you are able to get feedback form each stage of your delivery life cycle, you can build actionable information about the bottlenecks and act on them. With amplified feedback therefore, you’d move toward what’s rightly mentioned as Tribal Knowledge by Tim Hunter. There isn’t a direct correlation here but if you look at Lean tools there’s a natural tendency to gain deeper insights at each step as it would help improve the flow at each step. Having said that to say it necessarily is an application of Lean would be my desperate attempt to retrofit everything to it.
The third way is about fostering continual experimentation and learning and creating a repetitive operations so as to help increasing the throughput. This again seems to be stemming from pursuing perfection, and removing inconsistencies and overburden ideas that Lean introduced to the software world. While the practices can be manifold I would again say that the intention is binging this higher state of knowledge to the system as a whole than just it’s individual parts.
So I’d like to rest the opening questions to this blog by saying there is no DevOps or Lean equation; DevOps (like Agile) is Lean. In other words, do not look at DevOps as a framework or isolated practice. DevOps does not substitute your exiting knowledge in any way, it complements the knowledge and capabilities of the entire organisation to help them achieve higher performance. And I we’ve shown you in this article, it plays out well with Lean.