Software Delivery in Small Batches

A short introduction to the ideas and practice of lean applied to software delivery. A preview of the material in the Small Batches slack app.

Show Notes

Recommend Reading
Recommended Listening
★ 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. I’m your host Adam Hawkins. In each episode, I share a small batch of software delivery education aiming to help you find flow, feedback, and learning in own daily work. Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.
Consider this episode a “Lean Software Delivery 101” course. I’ve taken the material from one of the courses included in the Small Batches app and edited into a podcast episode. Give this episode to your management team. If you’re part of management then identify one thing to start doing tomorrow. Alright here we go.
Lean originated at Toyota after WWII. The company had low production volumes of high variety products. Finances were tight, so Toyota needed to skillfully use resources to turn a profit. Toyota developed “lean” over decades under these constraints.
The company eventually grew production volume by orders of magnitude, but we must always consider the initial constraints.
The lean ideal aims to provide a fast flow of value to the customer that is on-demand, defect free and without waste. Lean teams manage flow by making work visible, using pull-based work, and continually improving all activities using systems thinking and tuning.
There’s a direct connection between Toyota’s lean manufacturing and modern software delivery practices like DevOps and continuous delivery. Both optimize for flow, feedback, and learning across the entire organization. Achieving the lean ideal requires a new mental model of the system before understanding the practices.
The lean ideal optimizes for flow of value end-to-end across the organization back to the customer with zero waste. “Waste” is any activity that consumes resources but creates no value for the customer.
Pull-based work minimizes waste. If someone—(i.e. the “customer”)—needs something then they must ask for it. Suppliers are not allowed to produce and deliver something until asked. This rule ensures all work is ultimately linked back to the end customer, thus minimizing waste. We call this kanban.
Kanban creates a network of queues. Queuing theory describes how to improve flow by reducing Work-in-Progress (WIP) and dividing work into smaller batches. In other words, queues move faster when they’re shorter and easier to work through. But first, queues must be visualized.
What gets visualized gets managed. Visual is the strongest human sense. Representing the current state with a single visual is the easiest way to build shared understanding.
Work is visualized as cards moving left to right on a kanban board. Columns in the kanban board indicate steps in the process. This simple visualization instantly conveys how work is flowing or more importantly not flowing.
Stuck kanban cards indicate waiting work. Waiting is waste. In this way, kanban surfaces the problem but the solution is up to you. Each problem is an opportunity to move incrementally closer to the ideal. Don’t assume you know the problem. Always go and see before taking action.
Kanban shows work flowing across the organizations then down to teams. Teams need to act on that kanban to produce working software. Applying the lean ideal to software engineering yields DevOps.
DevOps teams achieve flow by creating deployment pipelines. The deployment pipeline acts as a visual control mechanism and standard process for deploying verified-as-good changes to production. Teams gain feedback comes from production telemetry, then steer themselves according to that telemetry. These two activities create the feedback loop for ongoing experimentation and learning.
Achieving this is no small task. This requires a holistic view of the system including the processes, management, organization structure, and technical architecture. The aim is to align them for organizational delivery, not teams or individuals. This is systems thinking.
This is the realm of management. Management’s aim is to structure the system for fast flow, feedback, and learning. Here’s some advice for management.
Repeat after me: What gets visualized gets managed. Visualize the work with kanban. Collect feedback by visualizing flow metrics on a dashboard. This improves visibility and understanding of the economics behind queues. Pair the visibility with practice and a mental model to create knowledge.
Manage queues by limiting WIP and coaching teams to iterate in small batches. Small batches reduces risk while at the same time accelerating feedback and learning.
Aggressively prioritize work using cost-of-delay. Create structures that minimize dependencies, conflicting priorities, and unplanned work. Aim for continuous single piece flow.
Finally, practice and coach others in the scientific thinking needed to continuously improve all these activities.
Management creates the system. Remember that a bad system always beats a good person.
All right, that’s all for this batch. Find links to recommended reading at SmallBatches.fm/73.
You can also find a link to my slack app that post courses of small batches of software delivery education. The app includes courses like the one you’ve just listened too. The app is currently free in beta so get it today and start learning as a team.
I hope to have you back again for the next episode. Until then, happy shipping.