Software Delivery in Small Batches

Adam presents the ideas in Wiring the Winning Organization with a vignette from his time on gemba. Plus, a giveaway!

Here's how to win a FREE copy of Wiring the Winning Organization. First, follow me on LinkedIn. Second, post a link to Small Batches podcast episode with what you learned using the #SmallBatchesGiveaway hashtag. The giveaway runs through January 2024. The winner will be announced on February 1st. You can enter as many times as you like.

Want more?
Chapters

Creators & Guests

Host
Adam Hawkins
Software Delivery Coach

What is Software Delivery in Small Batches?

Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.

Hello and welcome to Small Batches with me Adam Hawkins. I’m your guide to software delivery excellency. In each episode, I share a small batch of the theory and practices along the path. Topics include DevOps, lean, and conversations with industry leaders.
Now, let’s begin today’s episode.

Welcome to 2024 everyone. I’m kicking the new year off with a larger than usual episode on Gene Kim & Dr. Steve Spear’s new book: _Wiring the Winning Organization_. If you don’t recognize these names, then go and study. They should be immediately recognizable.

Gene and Steve make their point with two vignettes, or short stories. The stories demonstrate three ways organizations are wired to win.

First, is slowification. They slow down to engage in deep problem-solving. Second is simplification. They simplify problems so they are easier to solve. Third is amplification. They ensure problems are seen and solved.

I’m taking a play from Gene and Steve. So in this episode, I’ll explain slowification, simplification, and amplification with my own vignette. The vignette is lifted directly from my experience on the gemba.

One other thing before we get started.

I think the lessons from _Wiring the Winning Organization_ should be share, so I’m giving away a FREE copy to one lucky winner. The winner can choose between a digital or print copy. The giveaway runs through January 2023. The winner will be announced on February first. Listen through to end of the episode for instructions on how to enter.

Alright, now onto the vignette.

My organization recently had a reorg. My team had to rejig our Datadog and Pagerduty setup to fit the new team structure. The aim was simple: ensure the right team is paged.

So, by what method?

Building a shared mental model was the first step. The team needed to understand the target condition and current condition.

We had an additional challenge. The team gained new team members in the reorg. They did not know how Datadog and Pagerduty fit together. Nor did they know how the team approached work like this, but they did know it was different than how they worked before.

This work presented an opportunity to solve a business problem, to share technical knowledge within the team, and to expose new team members to a new culture.

The team relies heavily on visual management. We created a miro board to visualize the target condition. We held deep planning meetings centered around the Miro board.

Datadog and Pagerduty are coupled. Changes in one require changing the other. Luckily, there is a boundary between them. Datadog monitors mention a Pagerduty integration. The Pagerduty integration determines who to page.

We created a grid. Columns indicated systems, one column for Datadog and one for Pagerduty. Rows indicated different parts of the system. We added sticky notes into each cell for specific target conditions. Examples were “Audit team”, “Rework Orchestration”, “Migrate monitors”, or “Rename Escalation Policies.”

Stickies are a center piece to the team’s visual management. Building the board was part knowledge sharing and planning. All team members were encouraged to call a pause if anything was unclear.
The pause signaled the team to go and see with a gemba walk through Pagerduty, Datadog, and our infrastructure as code repository. Team members annotated the Miro board with visuals including code snippets, screen shots, and check lists during the gemba walks. The visuals enabled all team members to better understand the current condition, target condition, and related work. The team iterated with gemba walks until everyone could give a short explainer for each sticky.

The stickies serve two purposes: they mark completion of the entire effort and indicate status of WIP. The team uses four primary colors. Gray means not started for whatever reason. Blue means all good. Yellow means OK but assistance may be needed. Black means problem, stop and fix. Green means done.

The planning sessions and gemba walks built a shared mental model. The team had a clear understanding of the target condition and sufficient understanding of the current condition. The next step was simple: turn the stickies green. But how?

The team set out to organize the work. Do we pair on rows or columns in the grid? The team decided to pair on columns because the systems were coherent. There was one column for Pagerduty and one column for Datadog. Working in columns meant pairs could work independently.

The team had an action plan. Bluework complete. Time to move to redwork. There’s more to this vignette, but let’s sidebar to identify slowification, simplification, and amplification so far.

The team is practicing slowification by moving problem-solving out of fast-paced production environment to a slower-paced learning environment. The team could simply jump into making changes, though that could break the organization’s paging system, thus creating more reactive and high-urgency stop-fix work.
We see this in the bluework aimed at creating a shared mental model. The mental model includes the target condition and current condition. This demonstrates one part of slowification: planning. Taking the time allows the team to build the first step in the PDCA loop.

The team is practicing simplification by reducing the problem into smaller batches. The team starts with a high level problem, make sure the right people get paged, then modularizes it across the high-level systems involved. That partitions the problem space into two halves: What do we need to change in Datadog and What do we need to change in Pagerduty? Now the questions are neatly boxed inside boundaries.
Creating the stickies demonstrates incremental problem solving. The team is not attempting to solve everything everywhere all at once. Instead, it’s a set of small coordinated changes.

Partitioning the problem space along coherent boundaries also demonstrates simplification. Each pair can tackle the target conditions inside their boundaries independently. They don’t need to concern themselves with unrelated problems. The bonus point is that pairs may solve problems faster and in parallel.
The team is practicing amplification by defining a signal to stop and swarm problems. The signal is coloring a sticky black. Team members are encouraged to signal early and often.

This first half of the vignette demonstrates most techniques of slowification, simplification, and amplification. The second half will demonstrate the remaining techniques of slowification and simplification.
OK, back to the vignette about Pagerduty and Datadog.

At this point the team has partitioned the work, set clear target conditions, and has enough understanding of the current condition to move forward. There is a gap between the current condition and target condition. How does the team close the gap? Let’s find out.

The pairs fan-out to tackle Pagerduty and Datadog. The Pagerduty pair has the most moving pieces. Let’s follow them.

The pair has a rough idea of how to navigate between the current condition and target condition, but rough is not ready. More study is needed. This is a call to bluework.

Bluework always begins with an end in mind that leads to redwork. The outcome of this bluework is an “iteration zero” standard work. The pair aims to keep the system in working order with change.
The pair begins by creating their own Miro board for collaboration. They throw sticky notes on the board for all the things they know must get done. They re-order, expand, and contract the stickies as they coalesce their independent mental model into a shared mental model. They haven’t touched code. This is purely a mental exercise aimed at creating a viable “iteration zero” plan.

“Iteration Zero” means it’s understood enough to try it on the gemba. It’s likely incorrect. The next step is to learn just how incorrect it is.

One person drives code changes. Another person calls out the steps in the standard work. All are encouraged to stop on anything unexpected or out of order.

Multiple problems are detected. The proposed order was wrong. Pre-requisites were not met. There are variations in configuration. All of this is feedback and factored into the standard work.

Iteration zero becomes iteration one, then two, and then three. Eventually the pair converges on an updated standard work ready for anyone to do. Now, they’re ready to execute.

The pair’s visual management shows a linear sequence of steps with a token for where each person is. They agree on a signal for stopping and swarming on problems. Work moves at its own pace. The pair colors the Pagerduty stickies green on the team board as they complete their standard work.

Let’s leave the vignette now to examine the remaining parts of slowification and simplification.

The Pagerduty pair demonstrates all three parts of slowification: planning, practice, and performance. The pair goes into deep bluework to create a plan. The plan is viable standard work description.

They practice the plan, using the learning to adapt the plan. They’ve also moved to a slower-paced practice environment where they can make their changes safely in preparation for performance. The performance, pulling a sticky and turning it green, goes off without a hitch after careful planning and practice.

This planning also demonstrates two parts of simplification: incrementalization and linearization.

The pair does not do a big batch of changes. They identify the individual changes to make. That allows incremental problem-solving. The small changes make problem-solving easier while keeping the system in working order at each step of the way. This is incrementalization. That sets up the next part: linearization.

They sequenced tasks associated with completing a larger set of work so that they flow successively. This happened at the start in visual management when the team planned the order of operations.
Then each step in the flow was standardized. The standard work set the order and how to accomplish each step.

Standardizing work created a stable work environment. Anything that was out-of-spec became a problem. That’s the trigger for amplification, where the pair signaled problems, then stopped and swarmed them.

Finally, this allowed the pair to self-regulate the work. Work was isolated so anyone could complete it. Visual management tracked who was doing what and what remained.

This vignette demonstrates all the concepts in _Wiring to the Winning_ organization. The book elaborates using examples from multiple industries and goes much deeper with exemplar case studies. My favorite exemplar case study is simplification at NASA during the Gemini and Apollo space programs.

Just one last note on the vignette and why I recommend the book. My team was already working like this before the book was published or was even released. _Wiring the Winning Organization_ gave me the lexicon to communicate our approach and a reference point for others.

This is a wonderful book for anyone in management or leadership—especially those aspiring to be. It sits at the intersection of Deming’s work, lean thinking, and DevOps. If you’re into those then you’ll enjoy this book.

I gave you my own explanations of slowification, simplification, and amplification. You should hear how the authors define them. Hopefully you see these again in the vignette. Here’s the lexicon in the author’s own words.

**Slowification**: Shifting problem-solving from performance back to practice and planning with forceful backup, stress testing, and other deliberate ways of finding flaws in the thinking before they become flaws in doing.

**Simplification**: Reducing the number of interactions one component of the system has with other components of the same systems. Simplification contains three techniques: incrementalization, modularization, and linearization.

**Incrementalization**: A technique within simplification of partitioning a large problem-solving effort (a great leap) into small, incremental steps. This involves establishing a stable base and then iterating and testing changes in a few factors at a time as opposed to testing the effect of changing many factors at once.

**Modularization**: A technique within simplification of partitioning a system that is unwieldy in its size, complexity, and inter-wiredness of relationships among its many component pieces into more, smaller, simpler, and coherent pieces.

**Coherence**: The quality of having a unified whole, which requires that elements that interact frequently and intensely are included in the same grouping so their interactions can be well managed, and that those that are not are excluded. This is necessary behavior of the whole to be logical and consistent.

** Linearization**: A technique within simplification of sequencing tasks associated with completing a larger set of work so that they flow successively, like a baton passing from one person to the next. What follows is standardization for those sequences, for exchanges at partition boundaries, and for how individual tasks are performed. This creates opportunities to introduce stabilization, so when a problem occurs, that triggers a reaction that contains the problem and prevents it from enduring and from its effects spreading. Those allow for self-synchronization, so the system is self-pacing without top-down monitoring and direction.

**Amplification**: The act of calling out problems consistently so help is generated and swarms the problem to contain it and investigate, so causes can be found and corrective actions created to prevent recurrence.

All right that’s all for this batch. I have two freebies for you.

First is my give away of a FREE copy of _Wiring the Winning Organization_. The winner gets to choose between a digital or print copy. Believe me, you’re listening to this podcast. You need this book!

Second is my guide to software delivery excellency. The guide is a wonderful companion to the appendix on influential authors, thinkers, and leaders included in the book.
Find both at https://SmallBatches.fm/99.

I hope to have you back again for next episode. So until then, happy shipping!