I have just finished listening to the audiobook version of The DevOps Handbook Second Edition - an excellent book for anyone working in IT… meaning every company out there today.

The first four chapters are relevant to everyone, which includes non-IT personnel, to get a better understanding of the abstract complexity of the systems that support most (if not all) business processes today.

Back in the day…

I never read the first edition, and not even The Phoenix Project when it was released. I was an early, busy evangelist of DevOps and had read several of the source literature the Phoenix Project and The DevOps Handbook was based on, especially Peter Senge’s The Fifth Discipline and Eliyahu Goldratt’s The Goal regarding The Theory Of Constraints. Today, I have read The Phoenix Project, The Unicorn Project and now the DevOps Handbook and can perhaps better understand some of the disconnect trying to explain concepts from a Learning Organization and TOC without being able to relate these ideas to someone who has only read e.g. The Phoenix Project and not the extensive systems thinking literature.

That said, having been interested in Systems Thinking for a long time, I may perceive the message in The DevOps Handbook a bit differently than if I would have only read this book and The Phoenix Project. I do think that The DevOps Handbook is an excellent introduction and summary of systems thinking and Theory Of Constraints.

The Three Ways

The authors have separated DevOps as a principle/philosophy/method into three areas (my words):

1. Systems thinking (flow)
2. Feedback
3. Continuous learning and continuous experimentation

These are known as The Three Ways in The Phoenix Project and The DevOps Handbook. For a systems thinker this division is perhaps a bit strange as the first principle - systems thinking - invariable lead to or encompass the other two. Without continuous learning and continuous feedback, there is no long-term, systemic systems thinking going on.

A high-blame environment is an effective way to stop all openly shared systems thinking as people will not have an incentive to talk about the problems they see in the system. Of course, you can say that thinking only stays in your head, but that is the same as saying we do not allow freedom of speech within our organization. Similarly, there will be no systemic change without systems thinking by just implementing a few DevOps or lean tools here and there. These may improve performance significantly short-term, but will inevitably be reverted over time as the practice of thinking in separation rather than in wholes will keep stakeholders from seeing the changes and related cause-and-effect in their system over time.

Just take the many implementations of lean as a tool to reduce cost by laying off people. Like saying “help us make our company a better place with a more innovative, inclusive culture and increase our performance so that we can lay off a bunch of people”. That sounds crazy, but has unfortunately been the reality. For a sytems thinker this is beyond comprehension as the behaviour effectively kills all innovation and aspiration towards improvements. The Toyota Production System was and still is oriented towards growth, not cost-reduction, there is a big difference.

Another example is the one-piece flow in Lean where wait-time in front of the system’s main constraint significantly drop performance, while a buffer in front of the constraint would increase performance, but then it is not one-piece flow anymore and thus ideologically incompatible even if the system is performing better. A system is perfectly designed to produce the result it is currently producing, but you can only realize that if you are thinking in systems.

“The harder you push, the harder the system pushes back.”

— Peter Senge, law number 2 of 11 Laws of The Fifth Discipline

The separation of systems thinking into three categories may lead a reader to think that systems thinking is just static value-stream mapping, which it is not. Mental models and description of structures need to be updated continuously if the process is thinking in systems.

“Systems thinking - The Fifth Discipline that integrates the other four.”

— The Fifth Discipline by Peter Senge

The five disciplines according to Senge are (expressed mostly in my words)…

1. Personal mastery (clarifying and deepening personal vision, seeing reality objectively)
2. Mental models (deeply ingrained assumptions, generalizations, images of how we understand the world and take action, realizing that those actions are seated into our mental models)
3. Building shared vision (the skill of creating pictures shared in such a way that it leads to true enrollment towards of a future state, i.e. not merely compliance)
4. Team learning (dialogue, not discussion, suspending assumptions and enter into genuine “thinking together”)
5. Systems thinking (the discipline integrating the other four)

However, I agree that if you want to emphasize feedback and continuous learning and continuous experimentation in order to not end up in a common misunderstanding of what systems thinking is, then you need to mention them. So perhaps this is a good approach, and a good shortcut to systems thinking.

VSM is not TOC

Early in the chapter about systems thinking VSM - Value-Stream Mapping - from Lean Manufacturing is mentioned. This is a good tool and probably a good introduction into thinking of the whole flow rather than processes in isolation. What I lack in the book is the fact that VSM focus on a single value-stream at a time and not the whole production line. A production line may produce several products and thus be the riverbed of several value-streams. A production line capacity constraint could affect all of them, some of them or only one of the streams. You would think one has to start somewhere, and that is the purpose of VSM. However…

The approach of Theory Of Constraints (TOC) is a bit different. It is to walk the factory (yes, you can walk a software factory too) and find the constraint of the system - the single bottleneck limiting the pace of the whole flow and limits all other processes. It doesn’t really matter what value-streams pass through it if it sets the pace for the whole production line. The main constraint in the whole system highly likely pull resources from one or all of the value-streams, but the problem is that in each VSM, the bottleneck may be erroneously identified being somewhere other than where the real, system-wide bottleneck is. In software development it is usually in testing, review, approval committees, change-advisory boards, etc. As in manufacturing, this is where work piles up in front of the bottleneck. It is never the shiny expensive thing or the “rock-stars” of the organization.

Yet, the systems thinking part has several references to The Goal and TOC as well as Peter Senge’s The Fifth Discipline. The Phoenix Project is an IT version of The Goal and finishes with a homage to The Goal. The references are all there and invite you to read them, which I find excellent.

Feedback

The chapters about feedback has many good examples of “shift left”, especially concerning testing and emphasizes to head for faster and faster feedback loops. The andon cord is there as an example, but I miss the analogy of Jidoka where Toyoda’s mechanically automated loom stopped when it discovered the thread had broke and the staff would swarm over the loom to resolve the problem. Illustrating the concept of fixing issues early when they are small rather than letting them pile up and become big.

Continuous learning

…is all about psychological safety (from the perspective of industrial and organizational (I/O) psychology). The authors mention Ron Westrums three organizational cultures: Pathological (power-oriented), Bureaucratic (rules-oriented), and Generative (performance-oriented). There are several references to Senge’s Learning Organization from The Fifth Discipline. In the second part, which is more practical, blameless postmortems (retrospectives) are discussed at length which I find really good. The best tool I have had experience with creating psychological safety in a team within an otherwise non-pathological organization is After-Action Review (AAR). See my post about After-Action Review for more information.

Final words

I think The DevOps Handbook is an excellent introduction to Systems Thinking and management philosophies to become a high-performance organization with ways to practically align and accelerate towards this more prosperous, generative, innovative state.

Part I, chapter one to four of the book ought to be mandatory reading for anyone in IT, alongside The Goal (Eliyahu Goldratt), The Phoenix Project, The Unicorn Project, Fifth Discipline (Peter Senge), and High-Velocity Edge (Steven Spear).

Gene Kim has done and is doing a tremendous job getting this message out there. Visit IT Revolution for books, videos, the Idealcast podcast, courses, and more from the publisher of The DevOps Handbook.

For more information about Theory Of Constraints, see the following excerpt from the movie version of The Goal…

The following video by Shrinivas Gondhalekar is an excellent instructional video on TOC…

Marris Consulting has a lot of material on TOC on their YouTube channel…