To enable fast and predictable lead times in any value stream, there is usually a relentless focus on creating a smooth and even flow of work, using techniques such as small containers, optimum size of inventory stored at each work centre, reducing work in process (WIP), preventing rework to ensure we don’t pass defects to downstream work centres. This is the most used concept in any modern manufacturing system.
The same principles and patterns that enable the fast flow of work in manufacturing setup are equally applicable to the Technology world. The only difference is that in Technology world the work is invisible (as in code, bits and bytes, applications stored in computer systems). In DevOps, we typically define our technology value stream as the process required to convert a business objectives/business requirements into a technology solutions deployed on production environments to enable a service that delivers value to the customer.
Whether one agrees or not with the DevOps methodology, This Book (The Phoenix Project by Gene Kim, Kevin Behr and George Spafford) written in a form of a story on a fictional company provides a framework in a simplistic generally understandable format. As you read there are many moments which will make you pause, reflect, connect the characters and situations to your workplace characters. They key takeaway is the “3-Ways”. The First Way is to increase the flow of work from left to right of the value stream, or from business requirements to Operations in the IT world. The Second Way is to generate consistent, fast feedback loops, amplify the feedback to help create quality at each step, and catch defects early on in the value stream. The Third Way is to build a culture of shared objectives and continuous learning. The author develops the theme from the key takeaways from the seminal book “Theory of Constraints(TOC)” by Eliyahu Goldratt and also generously refers to the Kanban system from the “Toyota Production System(TPS)”.
How do we manage Constraints?
1. Identify the constraint. This is the key step. In the production work floor, work components are visible, however in the technology world, work is invisible and hence WIP (Work in Process) and constraints will get unnoticed if you don’t have a system of status notifications, review cadence etc.
2. Exploit the Constraint for maximising effectiveness. Prioritise work at Constraint.
3. Subordinate to the Constraint. Explore workarounds, alternate workflows.
4. Elevate the Constraint. Ensure that everyone else supports and helps the Constraint in a way to ensure optimal work done by the Constraint.
5. Institutionalise learnings & Continue to look at these steps repeatedly.
Discussing a few observations to help churn your mind and generate Point of Views.
1. Brent the character which epitomises Constraint in an the IT Operations workflow, is brilliant, smart and subject matter expert in many domains. We all can relate to similar characters in our workplace. In this fiction, Brent is helpful, always eager to help without any ego or expectation of return. What if Brent was arrogant and pushes back, or worse prioritises help requests based on “What’s in it for Me” syndrome? This typically generates power centres in parallel to work centres. Think of ways to handle this type of constraint. Is he the constraint? What can be done?
2. What if Brent is an Information Hoarder, to brand himself the indispensable hero?. Is his brilliance an asset or has it become a liability to the optimum work flow?.
3. How do we scale Brent.?
a. Let Brent coach and guide other people instead of doing it himself. This system of mentees if you will may be help scale the “constrained work centre” and reduce the constraint.
b. Prioritising work requests to Brent to ensure that only critical work gets assigned and no other interrupts.
4. Do you find the DevOps flavour in the old Indian system of “Jugaad”. Mostly found in medium scale enterprises with lean workforce by design more than by choice. The workforce takes on multiple roles simultaneously and adopts a very iterative process of development, deployment and operations.
5. As a Leader, how would you feel to be a Constraint? What steps should a Leader do to scale.
Some more musings using analogy to compare and contrast the “3 Ways” with the various Communication Protocols & Systems evolved over time.
If I were to apply the “3 Ways” principles to the evolution of the data communication industry, some fascinating thoughts emerged. In the early days of IBM-SNA, Mainframe to terminal communication protocols, X.25/Frame relay communication protocols, there were mechanisms of implicit & explicit flow control signals at each step of the data flow. The end to end data flow was consistent, predictable, with negligible wastage of information blocks, although the data block chunk was small compared to networks today. This is similar in a way to the manufacturing floor work flow from each work-centre to work-centre using Kanban cards to signal. This ensured that there was no single work-centre or hop becoming a Constraint to the flow. Over time emerged the IP Networking protocols and different options of flow control emerged with option of explicit signalling of congestion and end to end flow control (as in TCP window size control between source and destination). A more implicit mechanism is preferred with dropping of packets to indicate the sender to slow down (Yes, you heard it right. Dropping of data packets, which could be considered as wastage in manufacturing systems). A whole school of thought and bodies of deep research emerged over the years proposing options of regulating data flow across networks to reduce data packets wastage, improve predictable latency, and self-healing upon detection of a constraint in any intermediate node. Many protocol white papers/RFC’s were written. Fascinating to think, that this in concept is very similar to the studies done by Toyota Production Systems & TOC striving to create optimum work flow of components and products, reducing wastage with consistent quality in the manufacturing floor. Amazing to see that concepts can be unique to an industry domain, but still can be applied across industries and setups, you just need to refine it for the target environment.
The references in the book with the manufacturing flow principles borrowed from the TPS and TOC, revived nostalgic memories from my early days of production supervisor apprentice in Siemens, India. The manufacturing floor layout was optimised for the flow of product (Induction Motors and Switchgear Control Panels) as it gets built from scratch to final assembly. The system of final integration test and occasional pile up of completed products at the Systems Test QA work centre some times causing the entire work flow to stop are the some of the often recurring problems in Manufacturing which has been since then solved with seminal bodies of work like TPS and TOC. The same principles are now rehashed, refined to match the new environment of the Technology value stream and given a new name called DevOps principles.
No comments:
Post a Comment