Software Delivery in Small Batches

Adam presents mental model behind lean and agile. The mental model accepts we don't know the path forward, thus we must optimize for learning it.

Are you just beginning your path to excellence? Then start here.

Already on the path? Continue your self-study with any of these:
★ 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. In each episode, I share a small batch of the theory and practices behind software delivery excellency.

Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.

I recently attended a round table discussion with Dave Farley on continuous delivery. Dave discussed how his “mental model” had been refined over the years.

The phrase “Mental model” immediately triggers “The Fifth Discipline” flag for me. Explicitly stating and communicating one’s “Mental Model” is one of the five disciplines.

Mental models are deeply ingrained assumptions, generalizations, or even pictures or images that influence how we understand the world and how we take action.

They enable us to align with our collaborators. More importantly, We change or adopt a new mental model in changing conditions.

So in this episode, I will discuss when to apply the lean mental model.

Let’s begin by partitioning the problem space into two. This is a simplification, but enough to make the point.

On one side, you know how and what to do. On the other side you do not know what to do or how to do it. You must navigate each condition differently.

If you already know what and how, then focusing on standardizing operating procedures is the path forward. Following standard operating procedures will produce the same quality work each time. In this scenario, there are few unknowns unknowns, and the remaining unknowns are easily handled through experience. In this scenario, you move confidently like the pizza chef making the 10,000th pizza; adroitly measuring toppings to taste and adjusting oven temperature and bake time. The aim is predicability, repeatability, and consistency.

Software developers spend little of their time in these conditions. In my experience, we spend much more of time in the other set conditions: we don’t know what to or how to do it.

These conditions call for a different mental model. The aim is optimize for learning.

In these conditions the goal is quickly and cheaply acquiring information. I say quickly because we want as many iterations, attempts, at-bats, experiments—whatever you want them, as possible, focused on the thing we must learn. I say cheaply because there is no guarantee that we continue down the path as we learn. We may abandon or abort at any point.

This is were the umbrella of lean, and thus agile, practices enter the frame. Let’s apply this mental model to a common scenario in software development.

Your product manager tells you they want to try a new marketing partnership aimed at increasing signups.
The engineering brain inside of you may thinking “oh, we can try out the new technology”, or “what a great chance to greenfield something entirely new”.

Time out. Those are unlikely related to the core learning and will only expand the batch size and create more work in progress.

Try a different line of thinking. Ask yourself: “How quickly can we go and see if this partnership does increase signups?”

Now a different side of the engineering brain activates. “Hmm, what if we build it into this part of the system?”, “What if we tried to feature flag it?”, or “How about with a simple landing page?”
Who knows, maybe you quickly go and see that, wow this new integration is KILLING it! Then maybe the team decides to bet more on it, thus changing the product and technical requirements. Conversely, you may quickly go and see that there’s no value there, so abandon that and throw away the small code change. You could also learn that continuing the parnetship use is financially prohibitive, so regardless of the technical solution the business will not pursue it.

When you apply this mental model, then certain practices are non-negotiable. Yes, we must model our work in hypothesis because that highlights the learning. Yes, we must work in small batches because those after faster ways to go and see if we are right are wrong. Yes, we must work in continuous delivery because that’s the only way to match the required velocity of learning.

If we continue working in this mental model, then you will discover how and what to do. The operative word is discover. You may not know how or what to do at the start, though I am confident you can learn what and how.

Practicing this mental model is a skill. You can learn how learn. Recognizing when to apply this mental model if the first step. Then the DevOps principles like flow, feedback, and learning come naturally. The practices like continuous deployment and kanban come next.

You will learn these practices and the other four disciplines along with mental models in my Small Batches way study guide. The study guide covers these topics in more depth than I can on the podcast. I guarantee the study guide will transform your own mental model, and thus how you work. I’ve witnessed it happen to myself and others. Get it for free at TheSmallBatchesWay.com.

Two more points to round out this episode.

First, continued application of this mental model may produce work that fits the other mental model. In other words, you may learn that the path forward is to deploy a proven approach with standard operating procedures. This is not a bad thing. It’s a good thing because it was discovered from experience on the gemba.

Second, all organizations are facing opened-end problems. They’re all trying to find new ways to succeed in the market. Your organization will succeed by continually out learning the competition. This is how the Japanese car companies demolished American car companies in the 70’s, 80’s, and 90’s. Complacency is not an option.

I practice this mental by asking: “how quickly can we go and see?”. Dave Farley does it differently. Here’s a wonderful quote from this latest book:

The best way to start is to assume that what you know is wrong, and what you think, is probably wrong and then figure out how you could find out how wrong it is.

All right, that’s all for this batch. Visit https://SmallBatches.fm/95 for links on studying mental models, and ways to support the show.

I hope to have you back again for next episode. So until then, happy shipping!