Software Delivery in Small Batches

Hello and welcome to Small Batches with me Adam Hawkins. In each episode, I share a small batch of education to guide you toward excellent software delivery.
Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.

Flow refers to the smooth and continuous progression of work from start to finish. The faster the better. Would you rather be stuck in traffic or speeding down the road?
Fast flow is crucial in today’s competitive digital world. The faster you can deliver value to customers, the faster you can iterate based on feedback. Simple, but not easy.
You’ll need a bit of theory and practice to improve flow.

Let’s begin by traveling back in time. Dr. Eliyahu Goldratt published The Goal in 1984. This was a seminal moment because it introduced the world to a new way to think about manufacturing. Now the ideas have spread into knowledge work like what we do in software and IT.
The book tells the story of how a struggling factory was saved from closing by applying the Theory of Constraints.
Theory of Constraints, or ToC, state there is always one constraint in the system that limits flow. Call that constraint a bottleneck. The only way to improve flow is to identify and manage the constraint. Improvements made elsewhere are meaningless. All that matters is managing the constraint.
The story plays out on the shop floor. It’s easy to see work piling up at certain machines. For example, if everything must be painted and that’s the slowest part of the process, then that’s the constraint.
A key aspect of the story is switching from push-based work to pull-based work. Pull-based systems have numerous benefits. I’ll touch on more of those later. For now, let’s focus on the mental model needed for pull-based systems. That’s queues and buffers.
Goldratt’s TOC introduces drum-buffer-rope management. The aim is to maintain a continuous flow of work by reducing variability and uncertainty. The Japanese term for this is mura, or “unevenness”.
The drum represents the rate of production. The buffer protects the drum from the fluctuations of the process. The rope is the signal to start the next task. The idea is not to starve or overwhelm the constraint.
Queues and buffers are easy to see when looking at a manufacturing line. There’s a visible flow of materials. Some things are moving. Some are not. Our visual sense is the strongest. If we can see things, we’re far more likely to understand them.
There’s a popular quote by Peter Drucker. It goes: “What get’s measured, get’s managed”. Here’s my version: “What get’s visualized, get’s managed”.
This is where we transition from the visible work of a manufacturing process to the invisible knowledge work. Luckily, pull-based are easily visualized as series of connected queues. The presence of an item in a queue is the signal to pull into the next step. We call this by the Japanese word for “signal”: kanban.
Kanban visualizes work on a board moving from left to right. The aim is simple: move work off the board by pulling it to the right. The customer is at the right of the board. Therefore, value comes from finishing work, not in starting it. The customer does not care about work on the left, only when the finished product is in their hands.
Visualizing work like this identifies where work is moving—or more importantly—is not moving. In this way, it’s a tool for revealing problems in a process. Are there a ton of tickets sitting in the review queue? Well then, best to go and see what’s happening. Perhaps it’s an opportunity to identify the constraint in the system.
The most common reason for slow flow is the amount of work-in-progress or WIP. Again, think of the highway. The fewer the cars, the faster they go. That’s a simple example, but we can do better. There’s actually an entire scientific field related to this. It’s called queuing theory.
This is one of my favorite aspects of switching from push-based to pull-based work. Adopting queues and modeling processes as networks of queues, open the door to a well studied discipline. We don’t need to guess, we have math.
The math tells us that as utilization goes to 100% then wait times go through the roof. This fact tells us how to manage flow the process. Keep WIP low and don’t load things to 100%. Extra capacity must be available to account for the variation in the work. It also tells us that WIP is a leading indicator for flow, so if we track WIP, then we can predict the future.
Identifying too much WIP is an opportunity to go and see why. Is it that too much multi-tasking is creating defects, thus rework? How about unplanned work coming from production incidents? Perhaps it’s because conflicting priorities from management that don’t allow anything to finish? What about high context-switching caused by too many hand offs? Or what about that unknown dependency on a team that’s already underwater? These are a few examples of what you may uncover when studying high WIP scenarios.
Visualizing work and tracking WIP is central to managing flow. Often times creating WIP limits is a simple way to identify bottlenecks and ensure a continuous flow of work.
This is a wonderful time to point out the simple but not easy nature of the practice. If you’re just starting to think of flow, then your WIP is probably too high. The way out of this situation is freeze low priority work and allow high priority WIP to complete. Completing some work will free up capacity to complete the rest. Simple, but not easy to issue stop work orders on active projects. They all provide value…right?
One of my rules of thumb is that if you don’t know what your natural WIP limit is, then your current WIP off by 2x or 3x. In other words, if you’re not tracking WIP right now, then you need to cut whatever you’re doing at least by half. Simple, but not easy. Alright, back to kanban.
Let’s think big for a moment. Everything on your kanban board is just the left of your customer’s kanban board, and so on. This is how we begin to see the network of interconnected kanban boards. You may know this by another name: the value stream network.
Our organizations are systems of interconnected value streams. This may be difficult to visualize at first. Luckily, there is another well-studied discipline for this. It’s called value stream mapping or VSM.
VSM is a visualization of the flow of information and materials across interconnected processes along with metrics like percent-C-A and cycle time. This encapsulates the value stream at a moment in time.
Visualizing the entire process with the key stakeholders gives something each person can understand and point at. “Oh, this is where I fit”, or “Wow! I didn’t know so-and-so was dependent on me!”.
Once visualized, it’s easier to identify the queues and bottlenecks, then engage in problem-solving efforts to create and deploy countermeasures.
Wrap-up
The value stream map and nested kanban boards allows us to zoom in and out of the system. This is where we need a bit of systems thinking. The aim is optimize of flow across the entire value stream, not optimize individual components.
Thinking in terms of flow, pull-based work, and value streams give us the tools to achieve that aim.

All right that’s all for this batch. Head over to https://SmallBatches.fm/87 for links to recommended self-study and ways to support the show.
I hope to have you back again for next episode. So until then, happy shipping!