Software Delivery in Small Batches

Adam answers a listener's request of advice on succeeding in high-level company or project environments with seven tips.

Want more?

🚀 New listener? Start with the introduction.
🎁 Enter the FREE giveaway for a copy of "Flow Engineering"
🧭 Get your FREE Guide to software delivery excellence
📘 Buy "Goldratt's Rules of Flow"
📘 Buy "Playing to Win" (my favorite book on strategy)
☕️ Small Batches #99: Wiring the Winning Organization
☕️ Small Batches #82: Leadership is Language

Chapters

(00:00) - Rules of Flow
(00:23) - Listener Request
(00:48) - May Giveaway: Flow Engineering
(01:30) - Rules of Flow
(04:15) - Goldratt's Rule of Flow
(04:52) - Tip One: Control WIP
(05:16) - Tip Two: Full-Kits
(06:02) - Tip Three: Set a Cadence
(06:51) - Tip Four: Right-Size
(07:42) - Tip Five: Buffers
(08:39) - Tip Six: Visual Management
(10:11) - Tip Seven: Language
(10:49) - Bonus Tip: Information Diet
(11:12) - Outro

★ Support this podcast on Patreon ★

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 excellence. In each episode, I share a small batch of the theory and practices along the path. Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.

A listener emailed asking for advice on the path to software delivery excellence. He asked what: what are the essential technical skills for excelling in high-level company or project environments?

This is a wonderful question because it demonstrates motivation to grow as a leader.

So in this episode I’ll answer this listener’s question.

But first, it’s a new month so there’s a new giveaway. This month I am giving away the latest book on ITRevolution Press: Flow Engineering by my friends Steve Pereira and Andrew Davis.

The book officially launches later this month. I was lucky enough to review an advanced copy. Great stuff in there, especially if you want to succeed in high-level company or project environments! Hopefully I get Andrew and Steve on the podcast this month to talk about their book.

Anyways, same rules as always. Go to SmallBatches.fm/108 for a link to enter the giveaway.

Now, onto the the listener’s question.

I’ll focus on the “high-level” part of the question. This implies a level higher than that of a single team.
The skills learned at the individual team level partially transfer to high-level. Here’s what I mean.
Consider the case of leading a small engineering team. Let’s assume the prerequisites are met for continuous deployment. You, as the team leader, are well positioned to achieve fast flow, fast feedback, and fast learning.

You’re leading the team so you can build the shared mental model around batch sizes, WIP limits, competing priorities, unknown dependencies, pull-based work, and unplanned work. Basically, all the necessary parts for lean software delivery.

A small team of a three to five engineers can likely manage flow reliably with WIP limits of one or two depending on size. People are able to pair. Knowledge is shared. The situation may be challenging but entirely manageable with focus on _heijunka_ or leveling the flow.

Learning to find flow in this environment is necessary but not sufficient to find flow at higher levels in the organization. Why? Because team structure and communication patterns change as you zoom out—or move up-the org.

The inflection point is shifting from leading a team of engineers, likely individual contributors, to leading a team-of-teams. Crossing this inflection point requires adapting your mental model.

You’ll face distinctly different challenges at this level than at the team level, both on the social and technical ends of the sociotechnical system.

On the social side, there will be a larger variety of stakeholder domains. Each of those stakeholders and their domains bringing their own mental model, assumptions, and aims.

On the technical side, there will far more competing priorities, conflicting priorities, team and technical boundary crossing, and sliding windows of deliverables and timelines.

You’ll be participating in the synthesis of business strategy and initiatives into tangible deliverables. Strategy is an entire topic on its own that I won’t get into now. There is much to say on that and how to do that well. I’ll drop links in the show notes.

Let’s focus on that tangible deliverables for now. Delivering on those requires a mental model for finding flow in a multi-project environment. This is why I said earlier that learning to find flow in a team is necessary but not sufficient to learning to find flow in a team-of-teams or multi-project environment.

Luckily for you there is book written on this exact topic. That book is _Goldratt’s Rules of Flow_.

The book is written by Dr. Elilyahu Goldratt’s daughter Efrat. The aim is applying the principles of _The Goal_ to multi-project environments. It’s written as a fictional story and a surprisingly fun read.

It tells the story of a struggling business overwhelmed by projects of questionable value. The main characters overcomes this challenge by triaging the project for business value, controlling WIP, and changing their internal processes.

Of course there is more to it than that. So let me distill the book’s key tips and mix in some of my own.

**Tip One.** Obviously control WIP across the teams _and_ at the level above or before it hits the teams.

Remember that you cannot see WIP at all levels as you zoom out. In order words, the exec teams sees less WIP than front-line teams do. It’s queues all the way down.

**Tip Two.** Build _jidoka_ into the process by using “full-kits”. The full-kit is the checklist of everything you need to actually start. Here’s an example.

Say you’re making a pizza. You’ll check that you have what you need to make the dough, sauce, the cheese, and whatever other toppings you want to add. You check that you have these _before_ making the pizza because having to stop mid-pizzing-making would suck. It would be highly interruptive plus require rework and context switching.

The point is only start if the conditions for completion are met. This acts as a WIP control and a process percent complete/accurate mechanism.

**Tip Three.** Create a synchronization cadence across working groups. This is straight out of _Principles of Product Development Flow_ and _Goldratt’s Rule of Flow_.

Standing meetings with open agendas are best way to achieve this. Participants are free to add topics to the agenda. If there are topics on the agenda, then there is pull to meet.

Scheduling a standing meeting removes the bespoke collaboration. Scheduling the meeting also avoids the pesky DM’s and daily interruptions. Let the questions and challenges accumulate as they often work themselves out naturally.

Schedule the meeting at faster cadence than delivery. So if the team is working in two week sprints, keep the standing once a week. This allows the synchronization to capture changes in the work.

**Tip Four.** Right-size the work at all levels.

You will encounter work of varying size and shape. The aim is to refine the incoming ideas, initiatives, projects, etc into consistent chunks that fit the level. Right-sizing does two things. First, it acts a WIP control. Two, it helps level the flow. Here’s a quick example.

Say you have three teams. Giving each team project that takes three months at 100% focus will likely overload the team-of-teams. Identifying the size of the work helps match the true capacity of the team.
Here’s another aspect of this tip. Consider one of those three months projects. Then break it down into approximately weekly chunks.

This unlocks the next tip.

**Tip Five.** Create buffers around deadlines and deliverables.

Here’s a rule of thumb. Take one third of the estimated time as a buffer. Unexpected things will come up. The buffer creates the space to deal with these. If projects start to go off track, then the buffer can be used from other projects with more left.

See chapter 24 on “Buffer Management” of _Goldratt’s Rules of Flow_ for a deeper explanation of this tip.
Adopting the buffer changes the approach to success. Instead of tracking the deadline, track the completion of the work relative to the remaining buffer. This creates a health indicator for the project or on aggregate if you group all the buffers.

This leads me to the next tip.

**Tip Six**: Make the work visual. What gets visualized get’s managed.

Your Jira boards are necessary to the team, but not intelligible to external stakeholders. Allow me to explain with an example.

You take your car to the mechanic for a major engine repair. You care about dropping the car off and when to pick it up. You likely do not care about the hundred of steps the mechanics will do between all that. Move the car to the lift, disconnect the battery, drain the oil, remove the timing belt, dissemble the cylinder head, and on and on it goes. All that middle junk. That’s the jira board. The mechanics in the shop really care about that because there’s where they do the work. But you don’t need this level of detail. Just call me when the car is done k thanks.

The point is the Jira boards are for the “production” side of delivery. Find ways to the visualize the status at more zoomed out levels.

The status will be lossy and that’s OK. Not everyone needs deep details. Using buffers allows you visualize the health on a project fever chart. The chart shows red/yellow/green, or blue/yellow/black depending on your style.

Just take a step back from the implementation and visualize. Then, standardize visual management across the team-of-teams thus creating a ubiquitous visual language.

**Tip Seven.** Adapt your language to the audience. You may want to say WIP, but perhaps people are better suited to understand “multi-tasking”. You may want to say “batch size”, but perhaps people are better suited to understand “scope”.

Communication and people **are** the hard problem. Prepare yourself to meet different groups of people where they are to collaborate effectively. Be an open and curious collaborator. Remember the words of Fujio Cho: Go and see, ask why, show respect.

**Bonus Tip Eight.** Shift your information diet. Watch what senior management is watching. Read the books senior management reads. Attend different conferences. Find new podcasts. Talk to new people. Shift your information diet towards where you want to go, not where you are now.

Alright, that’s all for this batch.

I need your support to keep this podcast viable. I’ve setup a patreon to support this podcast and its cousin, the Software Kaizen substack. Your support ensures I can continue producing Small Batches episodes like this one and long-form written content on Software Kaizen.

Go to SmallBatches.fm/108 to a link to my patreon, the free May giveaway, and a bunch of links to succeed in organizations.

I hope to have you back again for the next episode. Until then, happy shipping.