DevOps and the Three Ways
The Three Ways were introduced in the Phoenix Project as principles upon which all DevOps behaviors and patterns are based. Their foundations are derived from Lean Manufacturing, and study of them reminds us how integrated Lean, Agile and DevOps are in practice.
The First Way reminds us to think flow from left to right (start to finish), with smooth throughput, limited batch sizes and visualization of the work. The Second Way emphasizes feedback from right back to left, ensuring that problems are detected and eliminated. The Third way enables trust and experimentation, amplifying feedback further, and creating a system that supports continual improvement.
The First Way Of DevOps
The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow.
The typical direction of IT work is often left to right from Development to Operations. The First Way states the importance of this path flowing quickly and smoothly. Our ultimate goal is rapid throughput, i.e. reducing the amount of time for changes to reach deployment to users.
To achieve this flow, a number of Lean principles are emphasized:
- Visualization – “Vision trumps all other senses” states John Medina in his brain research and therefore it is critical to maximize the effectiveness of that sense. Display the work and the flow of work using Kanban boards and other visual tools.
- Limiting Work in Progress (WIP) – while perhaps not trendy with multi-taskers, we’re encouraged here to start and finish one thing at a time. This mandates good prioritization and helps us to eliminate partially completed work.
- Reduce batch sizes – closely related to our previous point in limiting WIP, smaller batches of work are what we strive for. The ultimate goal here is single-piece flow, and this we’re finding in today’s most efficient Continuous Delivery pipelines of DevOps.
- Reduce the number of handoffs – handoffs reduce speed and increase lead time. If our processes mandate too many people, tools, approvals and other overhead, our flow is decreased. Keep it manageable to ensure flow.
- Expose and solve problems – rather than sweeping them under the rug, we’re reminded to elevate and get rid of problems. Bugs must never be passed on to other people in our process. And constraints such as bottlenecks need be addressed for they ultimately dictate the (lack of) speed and flow in our work.
- Eliminate waste – sounds so simple, requires such diligence. Identify the waste in your work, and work to be done with it.
DevOps and the Three Ways are by definition an acknowledgement of systems thinking, taking the “whole of IT” into account. In that regard, development and operations MUST cooperate based on mutual processes in order to produce the best IT for the customer.
The Second Way Of DevOps
The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.
Building upon the directional flow of the First Way, the Second Way reminds us to loop back. Feedback is the key word, repeated over and again. Much like salespeople should listen more than they speak, we IT professionals are encouraged to use the ears of feedback loops in order to listen to our customers and the results of our work.
Agile principles have built this right into their backbone (sprints, reviews, retrospectives…) and the Second Way wants us to think in this manner. Testing is not something to perform when the development work is done (and if we have time), but instead testing is designed and coordinated INTO the development work. Customers and users are involved to give feedback throughout the work cycle.
Negative feedback becomes opportunity and the work is focused to learn and grow from it. Swarming to solve problems and principles of Jidoka and Toyotas Andon Cord are a natural part of the work. Quality control and being responsible to it is expected in the Second Way, and when established, it becomes its own generator of momentum to the overall flow of work.
The Third Way Of DevOps
The third way is about creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure; and understanding that repetition and practice is the prerequisite to mastery.
Our first two ways emphasized directional left to right and then looping back. The Third Way encircles this movement and creates a culture of continual learning, experimentation and improvement.
Traditional management methods are challenged by the Third Way. The role of a leader is no longer to make and enforce decisions, but instead to establish an environment that brings forth communication and problem-solving within the team. (I highly suggest McChrystal’s book “Team of Teams” and some of his other writings for further inspiration here.)
Critical is creating an environment of security and trust in order further the experimentation and risk-taking necessary for improvement. As in the Second Way, problems are viewed as opportunities. Blame-games are replaced by reflection and learning from mistakes. Ultimately these behaviors are injected into daily work at the source of production. Behaviors become positive habits, and in turn establish a high-performance culture.
Right to left flow, loop back with feedback and surround the work with a secure environment encouraging experimentation, learning and improvement. The Three Ways provide us with guidance in how to provide more value for our customers, sustainably over time.
One… Two… Three. Time to get to work.
Learn and practice the Three Ways
Our DevOps in 2 Days course introduces you the basics of DevOps AND provides you with immediate practice in the Phoenix Project business simulation. You can expect to leave day two with tools and inspiration to start your DevOps journey.
Idag växer rollen produktägare i många organisationer, både i betydelse och komplexitet. Det agila ramverket har ett tydligt fotfäste som arbetsmetod för förändring, och därmed blir rollens utövning avgörande. Hantering av krav, produktförståelse och kommunikation...
En av de tidiga aspekterna av en agil transformation eller för den delen en förflyttning mot ett mer lättrörligt arbetssätt är att sätta ihop ett agilt team (ibland kallat ett scrumteam) I regel brukar man säga att ett team består av 3 huvudroller. Produktägaren,...
Agilitet har länge varit förknippat med startups och mindre organisationer medan de större bolagen förknippas med långa beslutsvägar och en svårighet att dra nytta av nya möjligheter som uppenbarar sig. De är helt enkelt för långsamma på bollen och har inte...