Software Delivery in Small Batches

Part four of a ten-part series on the 2009 book The High-Velocity Edge by Steven Spear. This episode introduces the two pillars of the first capability: design systems to reveal problems. The first pillar is Taiichi Ohno's "kanban", or pull-based, philosophy on system design. The second pillar is Sakichi Toyoda's "jidoka", or self-regulation, philosophy to identify problems when they happen.

The High-Velocity Edge on Small Batches
Links
★ 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.

[00:00:00] Hello and welcome. I'm your host, Adam Hawkins. In each episode I present a small batch, with theory and practices behind building a high velocity software organization. Topics include DevOps, lean software architecture, continuous delivery and conversations with industry leaders. Now let's begin today's episode.

[00:00:26] Welcome to part four of a series on Steven Spear’s 2009. Book the high velocity edge today. I'll discuss the philosophy behind the first capability, design and operate systems to reveal problems. When they occur the philosophy originates from two pivotal figures in manufacturing history. Sakichi Toyoda and Taiichi Ohno Sakichi Toyoda founded Toyota Taiichi Ohno transformed manufacturing, while working at Toyota.

[00:00:52] Taiichi Ohno set the vision for design Sakichi Toyoda set the vision for operation. These two men pioneered what we call lean manufacturing, which went on to become one pillar of the legendary Toyota production system. Much of the philosophy behind high performance software delivery is rooted in lean manufacturing.

[00:01:13] There's a straight line from building cars on an assembly line to software delivery practices like continuous integration and continuous delivery. The high velocity edge, contextualized ideas and practices in the DevOps handbook for me, It also connected pathways in my own mind, around my own goals and patterns.

[00:01:30] Again, this traces back to Toyota because–for whatever reason–Toyota figured how to do everything faster, better, and more profitable than everyone else. The high velocity edge is jam packed with examples from the daily work at Toyota, especially for demonstrating the four capabilities in.

[00:01:46] action. The next few episodes cover the most exciting and interesting chapters in the book. These are the episodes I'm the most excited to share with you. These chapters are why I consider the high velocity edge. One the most important books I've ever read, it gave me the framework to contextualize my work in service to a larger whole.

[00:02:05] I hope these episodes does the same for you. I say, in service to a larger whole, because the idea comes from the legendary Taiichi Ohno, Taiichi Ohno created the Kanban pull based system at Toyota. His objective was to ensure pieces of a larger whole harmoniously synchronized, rather than create discord.

[00:02:24] Ohno developed a simple rule for this. If someone—[i.e. the “customer”]—needed something, they had to ask for it. And the supplier was not allowed to produce and deliver something until asked this ensures all work is ultimately linked to the end customer and minimizes waste Spear described Ohno’s vision for Kanban as everything always in service to a unified whole.

[00:02:47] I’d never heard Kanban explained like this to me, Kanban was just “cards on a board moving from left to right. This description helped me internalize. One of Ohno’s profound insights only do work if asked here's my example. I work as an SRE, so my customers are other developers. My team had been building out features for our internal platform then pushing work on other teams.

[00:03:13] to adopt it. You may already be thinking this sounds off. it was, the result was work either went unused or shelved because our customers either didn't have the capacity to take on new work or weren't ready for them. In short, they never asked for it. Toyota has a term for this “muda”. Muda is anything that takes time and does not add value for your customer.

[00:03:37] Well, no wonder this wasn't working Most of the work was pure waste. Beyond that it was frustrating to see our work unused or scrapped. When I realized this I stopped any work that was not explicitly asked for by customers. I encouraged my teammates to do the same. The result was less work in progress and more capacity for pull based work.

[00:04:00] Now, the team only pulls from other teams. If there’s nothing to pull then we work on internal technical debt and maintenance that delivers value to us without pushing work onto our customers. Spear’s description of Kanban as always in service to a unified whole plus my real world experience clarified the meaning by “just-in-time”. I could do an entire series of episodes on Taiichi Ohno, Kanban, and the Toyota production system, but a single episode will have to do for now. Taiichi Ohno demonstrated how to design systems. We'll see how Sakichi Toyoda demonstrated how to operate them in the next episode. Until then I recommend you read the Wikipedia pages for Taiichi Ohno and the Toyota production system.

[00:04:43] They’re gifts that keep on giving. You've just finished another episode of small batches podcast on building a high performance software delivery organization for more information, and to subscribe to this podcast, go to smallbatches.fm. I hope to have you back again for the next episode. So until then happy shipping.

[00:05:06] Like the sound of small batches? This episode was produced by pods worth media. That's podsworth.com.