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 confusion.
I’ve been asked this quite a bit "We’re practicing Lean Kanban already how would DevOps help us?" Or "Do we need to do DevOps when we’re practising 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.
DevOps
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 the people identify with a movement. DevOps therefore has certain principles that make up most of what we know as DevOps today.
Lean
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.
- Define value precisely from the perspective of the end customer
- Identify the entire value stream for each service, product or product family and eliminate waste
- Make the remaining value-creating steps flow
- As flow is introduced, let the customer pull what the customer wants when the customer wants it
- Pursue perfection
The Three Ways of DevOps
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
The first way looks at maximising the flow of work from the “left” (business idea) to 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 a 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 the context of improving the whole.
If you stop here and look back at the aforementioned lean principles you’ll notice where this might be stemming from. It essentially appears to be mandating principles 1 to 4 in this form. This 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)
- Continuous Flow
- Kanban
- Value Stream Mapping
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).
Second Way
The second way is about creating amplified feedback loops between each step 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 from 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
The third way is about fostering continual experimentation and learning and creating repetitive operations so as to help increase the throughput. This again seems to be stemming from pursuing perfection and removing inconsistencies and overburdening ideas that Lean introduced to the software world. While the practices can be manifold I would again say that the intention is to bring this higher state of knowledge to the system as a whole rather than just it’s individual parts.
Conclusion
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 existing knowledge in any way, it complements the knowledge and capabilities of the entire organisation to help them achieve higher performance. As I've shown you in this article, it plays out well with Lean.
Top comments (0)