Software Delivery in Small Batches

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.

I had friends come over on new years eve. We played one of those get-to-know-you type of games. People draw cards and choose someone to answer the question. Someone asked me: “What’s a word or phrase you’ve said the most last year?”

Two answers immediately came to mind. So, in this episode I’ll share my answers and how adopting them have shaped my daily work.

First, some house keeping. I’ve done a bunch of work on the Small Batches website. Now, you can find all the guests and their episodes on a single page. Shoutout to John Willis for being the most frequent guest.

Also, the most popular episodes have been updated with links to related episodes. Oh, there is a brand new design too! So check it out at SmallBatches.fm.

Second, my give-away for a free copy of _The Wiring Organization_ ends in two days! So if you’re listening to this before February 1st, then there’s still time to enter.

I’m giving away free books every month in 2024. Follow me on LinkedIn to keep updated on these giveaways. Next month I’m giving away a copy of _Deming’s Journey to Profound Knowledge_.

Alright, now onto my answers. I have two. First: viable. Second: go and see.

I’ve said “viable” countless times over the last year. I keep using it every day. This word changed my approach to problem-solving. Why is that?

Consider the dictionary definition. Viable, adjective, “Capable of success or continuing effectiveness; practicable”.

I picked up this word from my lean studies. There were two books in particular: _Managing to Learn_ and _Lean Product and Process Development_. Both books write about “identifying multiple viable options”.
Two key words there: multiple and viable.

Viable is crucial because it forces the speaker to consider the factors to succeed. Here’s an example I see play out every day.

There are two engineers deciding how to do something. One says: “I have a good solution. Let’s migrate the app from Kubernetes to Lambda”. The other says: “Ya, that sounds good. Let’s get started.”
The operative word in this exchange is “good”. How many times have people proposed “good” solutions that don’t actually address the core problem or challenge. Imagine the conversation going like this.
One engineer says: “I have a good solution. Let’s migrate the app from Kubernetes to Lambda.”. The other engineer responds: “Is that viable though? That sounds like a cost play. We have a scaling problem. Also, any idea on how long that would take?”. The first engineer pauses for a moment: “Hmm, you’re making me reconsider. I did not consider that. Plus, we’d have to carve out the time on the roadmap against other competing priorities. I don’t think is a viable option. What can you think of?”

The point here is disconnecting ideas from their fitness for a given problem or challenge. That greatly improves the bluework of coming up with ideas then _separately_ assessing their viability against relevant criteria.

Criteria may be cost, time, effort, bureaucracy, or whatever the trade-offs are. Thinking in viability terms puts the ideas and evaluation criteria on two different sides. From there, it’s easy to come up with a menu of ideas, then test them for viability. This is the best way to solve problems.
Let me give you another example. I have participated in multiple problem-solving exercises where I do not fully understand the core domain. This is fun for me because I suggest ideas _without_ knowing if they’re feasible, let alone viable. Bits and pieces of my ideas may be useful when combined with other ideas. That creates new options to check for viability.

One last example before moving on to the second phrase. I’m a position to assess business development opportunities. Determining viability requires multiple stakeholders, like turning two key to launch a missile. This is great for me because I use viability on one side to reduce the problem-space. For example, let’s say we have a six month time horizon. If a proposed business development deal takes one year, then that’s immediately not viable. There is no sense in investing engineering time into spikes or probing these opportunities because they’re not viable on the business side. The concept of viability allows me to goalie before it comes to my engineering teams.

I sincerely challenge you to bring the word “viable” into your daily problem-solving work. You’ll be surprised how different people define viability—thus making the implicit mental models explicit; plus encouraging everyone to come up with menu of viable options.

So what happens if you can’t determine if something is viable? Well, then you need to go and see.

There is much meaning in this short phrase. The TL;DR version is go to the _gemba_ and observe for yourself.

What’s “the gemba”? The gemba is the place where the actual work happens. The second part is _observe for yourself_. You, that’s you—the person with eyes, a mouth, ears, and a brain—collect the facts _yourself_.
“Go and see” cannot be delegated. Quite the opposite. It requires a deep commitment to learning and curiosity to go and see while comprehending what’s happening.

Here’s an example. One of my teammates pulls the andon cord, surfacing a problem on the website. I respond: “Thank you for identifying this problem. I need to go and see what the problem is. Can you show me on Zoom?”

This small interaction accomplishes several important things. First, it reinforces the value of identifying problems. This is a core lean tenant: the obstacle is the way, stop, and solve problems. Second, it demonstrates that I am interested in solving this problem by showing I want to understand the problem _for myself_. Third, it creates the opportunity for learning. My understanding of the problem—be it the cause or impact—may be completely different than my teammates. That’s the opportunity to reconcile our mental models, then propagate that refined mental model forward to others pulled into the problem-solving.

Here’s a different example. I’ve been in many meetings where people are talking about numbers, KPIs, or any type of time series data that I simply don’t understand or I want to know _how_ they came up with those numbers. So, I’ll say: “Time out for a minute. I don’t understand. Can we go and see how you got those numbers?” Then someone will open a spreadsheet or some biz ops dashboard to explain the background information. I have learned so much with this simple question.

The crucial trait is curiosity. For this I pull from one of the masters: Fujio Cho. He was chairman of Toyota Motor Corporation, and man behind “The Toyota Way”.

He explained: Go and see, ask why, show respect.

All right, that’s all for this batch. I challenge you to bring “viable” and “go and see” to your gemba.

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

There is only a single tier on Patreon to start. I will provide exclusive content for paid subscribers, though I am not sure what that is just yet.

So go to SmallBatches.fm/101 for links to my patreon and more resources on viability and go-and-see thinking.

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