Software Delivery in Small Batches

Adam presents the "five time thieves" described in Dominica DeGrandis' book Making Work Visible. The thieves are: too much WIP (work-in-progress), unknown dependencies, conflicting priorities, neglected work, and (the most annoying of the bunch) interrupts.

Learn More
★ 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 everybody. Adam here with another episode of Small Batches, the podcast on software delivery education. This is episode 58.

This episode continues a thread I’ve been pulling on over the last month or so. The thread relates to two books. The first is Principles of Product Development Flow by Donald Reinersten. The second is Making Work Visible by Dominica DeGrandis. Both books focus on improving flow.

Principles of Product Development Flow is a large, deep, and technical work. Making Work Visible focuses on a smaller part of the same topic. I think you can read Making Work Visible and get 80% of what’s in Principles of Product Development Flow with 20% of the effort. In fact, Making Work Visible references Principles of Product Development Flow multiple times.

Principles of Product Development Flow has a chapter on applying WIP (or work-in-progress) constraints. Making Work Visible expands on this by introducing four other reasons why work queues slow down.
Both books connect their recommendations back to lean theory using kanban and queueing theory. I cover queueing theory in the previous episode. I recommend listening to that episode after this one. Understanding WIP will provide more context into why queueing theory is so important.

Find links to both these books and queueing theory episode at smallbatches.fm/59. Oh, and Dominica DeGrandis just appeared on John Willis’ Profound podcast last week where she talks about the five time thieves and her connection to Dr. Deming. I add that link too, if you want even more background on Making Work Visible.

Alright, now the background is out of the way. There’s one more thing for you before we begin today’s episode.

I’m launching a Small Batches slack app to teach teams software delivery. Each day the app posts a small batch of software delivery education. There’s already an entire YEAR’s worth of content waiting for you, and I’m adding more day by day.

So, if you find value in the topics covered on this podcast and would like to share them with your team, then go to smallbatches.io and join the waitlist. I’m onboarding beta users right now.

OK, lets begin today’s episode on the five time thieves.

Making Work Visible introduces five time thieves. The thieves are taxes on your team. They make it more difficult to establish flow and complete work. If we can name these troublemakers, then we can find them, and establish countermeasures for them. They cannot be eradicated, only mitigated.

The first thief is too much work-in-progress (or WIP). Too much WIP leads the merry band of thieves. If too much WIP is present then the other thieves will follow. On the other hand, if the other thieves hang around long enough, the leader will appear.

Holding too much WIP is like running a computer with too many programs and too little RAM. Things may work, but they slow down significantly, sometimes even ending in the spinning beachball of death. This happens because the computer is constantly context switching between programs. Hopefully there’s enough RAM to prevent hitting swap.

You know this feeling. It’s the line of sticky notes stuck to your monitor. It’s the endless parade of meetings. It’s the status report you’re writing between builds. It’s your ten open pull requests to a few different repos. It’s the support ticket waiting for vendor response. It’s all the things you’re doing but not yet complete.

It’s that quick and easy ticket that stalled because you didn’t see a massive unknown dependency. Next thing you know, you’re neck deep into meetings with other teams about updating their service. Of course they weren’t expecting this work so they can’t get to it for few weeks–like that will happen right? Now you’ve met the second thief: unknown dependencies. So what do you do now? Well unfortunately you need to wait.

Move that ticket into "blocked" and try to find something else to work on. Perhaps one of those sticky notes stuck to your monitor.

Then, you see it, so wonderfully yellow and rectangular. The text so largely and clearly written in black sharpie. It’s right there, sitting like a present under the Christmas tree. It’s the holy grail of tickets: the small isolated task
.
Oh hell yeah, it’s on! Time to ship. You queue up the flow state music and it’s nirvana. You’ve hit that sweet point of information absorption where everything is clicking and code is flowing with each masterful and purposeful keystroke.

And….it’s gone! The pager goes off. Severity one issue in prod. Well that’s that. The cops have arrived and pulled the plug on this party. Time to context switch as gracefully as possible into fire fighting mode. Luckily the issue can be resolved shortly, but then comes writing incident reports, postmortem meetings, and important countermeasure work to prevent future problems.

You just met the most annoying member of the gang. This is unplanned work. It’s the interrupts. It’s the pages and the slack messages. The support tickets. The unexpected "oh, you’re needed in a meeting". It’s the high urgency request DM’d to you from one level up in management. You never know when it’s coming but rest assured it’s always higher urgency and higher priority than whatever you’re doing at the moment.
Well after all that, it’s finally time to check back on the other team working on updating their service to support that ticket from earlier. The engineering lead reports they made progress but had to change course because of new priorities. It’s unclear when they can start again. Unfortunately, this is par for the course.

This completes your introduction to the remaining two gang members. I’d like to introduce to thief neglected work and thief conflicting priorities.

Neglected work is like an incomplete bridge: all the work with none of the value. Who wants an incomplete bridge? No one does. It’s just a waste of time and materials. More over, it’s all WIP until it’s complete.
These neglected projects may act like black holes. They can pull in more time, resources, and people—making it more difficult to complete other work. If they survive long enough they may even become a zombie project that lumbers unwieldy through the organization.

Conflicting priorities is another facet of the same problem. Why can’t the bridge get finished? Some people think it should finish, some don’t care either way, and some have other priorities. These conflicting priorities indicate that there is no clear goal. Everyone is striving toward their own ends to the detriment of the entire system.

There are ways to thwart these thieves. The best way is limit WIP. This frees up capacity for inevitable unplanned work. Work in small batches to reduce the scope. Reducing the batch size mitigates against unknown dependencies and makes it easier to actually complete work. This is a natural countermeasure to neglected work. The work doesn’t have time to age.

Finally, make the work visible by putting everything on a kanban board. The kanban board quickly communicates all the work, what’s in what place in the flow, and what’s ready for more work.

If you’d like more information on thwarting these thieves from stealing your time, then pick up a copy of Making Work Visible by Dominica DeGrandis. It’s a fun and entertaining read with plenty of applications to your daily work. Find a link at smallbatches.fm.