Subscribe
Share
Share
Embed
Adam discusses three (new-ish) ideas from time on a new gemba.
Want more?
Want more?
- 🚀 New listener? Start with the introduction.
- 🎁 Enter the FREE giveaway for a copy of "Modern Software Engineering"
- 🧭 Get the Small Batches Way guide to software delivery excellence
- 🥋 Software Kaizen: My One-on-One System for Engineering Leadership
- 📘 Flight Levels by Klaus Leopold
Chapters
★ Support this podcast on Patreon ★
Creators & Guests
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. 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 have something different for this episode. I’m going to share three ideas going around my head. These not fully thought out unlike most of the stuff on the show.
They come from my time on a new gemba. This gemba is managing flow across multiple teams. This gemba encourages me to think and act differently than before.
## Sequencing over Prioritization
The first isn’t really an idea. It’s a new behavior to replace an old one.
I have banished the word “priority” and its other forms from my lexicon. I no longer say the word. I no longer write the word. I actively shift my mental model away from it. Here’s why.
First, “Priority” correlates with high WIP environments. This shows up in “prioritizing” long lists of projects. When manageable WIP is one or two, having a list of fifteen projects is a joke. The “prioritization” is just flow theater. More like competing priorities if you ask me.
Second, “Priority” is typically a proxy for something else. The question “Can this be prioritized?” makes me grimace. Yes, I can drop an arbitrary number on a ticket or in a spreadsheet, but what’s the point? Often times the question aims to understand “When can this start?” or “can your team do this now?”. Reasonable questions but “priority” provides no answers.
Here’s how I shifted my mental model.
Before: “How can we prioritize the work?”. After: “How do we sequence the work?”.
Before: “What do we prioritize next?. After: “What do sequence next?”.
The behavior is shifting to _sequencing_ work. Bonus points for moving from “What do we _do_ next?” To “What do we finish next?”.
Thinking in sequencing shifts thinking towards the order work should _finish_ in. Then, plans can work backwards. Thinking in sequencing also gives a better sense of what is possible now and what’s off in the distance. This naturally follows into now, next, and later work buckets. Work inside those buckets can be sorted though not necessary to pull.
Thinking in sequencing also makes multi-tasking explicit in a way that “priorities” do not. Typically work doesn’t have the same priority. One will be higher or lower than the other, even though they will be worked in parallel. Sequencing makes this explicit because work may be explicitly sequenced in parallel.
I could waffle on about this for longer so here is a bit of a tl;dr. Thinking in sequencing, and shifting the conversations to sequencing, has been better mental model for structuring work for flow. This focuses conversations on the order to finish work _instead_ of how to “prioritize” work to _start_.
Try it for yourself.
This leads me into my next idea.
This one is alpha level. I have more study in this area, so I’m giving you the rough cut of this one. It’s flight level’s concept.
This is not my idea. There is an entire book on the topic. That’s linked in the show notes. I’ve found the idea useful in connecting company vision, strategy execution, and delivery into a unified mental model.
The flight levels model uses three feedback loops with different time horizons and levels of granularity.
Flight level three is strategy. It has the longer time horizon. This is the synthesis of vision, mission, and strategy by top-management. It’s the company’s direction and focus.
Flight level two is coordination, between levels and across teams.
Flight level one is operation. It’s where the work gets delivered, the product made and customers helped.
My gemba has shifted up from flight level one to flight level two. My new gemba is coordination across teams and between levels, like a helicopter that can easily move horizontally and vertically.
Visual management is a core concept in flight levels. It’s kanban boards all the way down, with clear connections up and down. Conversations around flow, sequencing, and trade-offs become much easier Once the work is visualized.
Flight levels helped me identify and explain gaps in my organization. I am reading the book on Flight Levels right now, so expected deeper thoughts soon.
Now, onto the last thought bumping around my head.
Let’s do a thought experiment on flight level one. That’s where the work gets delivered, code get shipped, and products get made. Practically speaking this is some form of agile team.
Now let’s assume an idealized team, flow, technical architecture, org structure, and all the rest.
Here’s the thought experiment: What would happen if anything requested by product or business that could be delivered in three days or less was predictably and accurately delivered?
Say a request comes in Monday. Teams says it will take a day. Working software in the customer’s hands on Wednesday morning.
Say a request comes in on Tuesday. Teams says it will take three days. Working software in the customer’s hands late Friday.
Say a request comes in Wednesday. Team says it will take short time. Working software in the customer hand’s later that that day.
What do you think will happen in this world? Here’s what I think.
First, the requests are strongly incentivized to be right-sized down to three days or less. Larger bodies of work must be sliced and remixed to provide value in a smaller sequence of deliveries. This is a positive reinforcing feedback loop.
Second, the feedback will come faster and with higher quality. The cycle times will fast enough to learn and practice true experimental product development. This type of learning is simply not possible on weeks to months cycle times.
One critical piece to this thought experiment is the ability to right-size work. Without it, teams will not find predictable flow.
Alright, that’s all for this batch.
Credit to my friend Jocko as the source of all these ideas. I hope to have him on the show soon. In fact, I’m lining up more guests to explore all these ideas. So stay tuned. More great Small Batches coming your way.
I’ve also have another posts for Software Kaizen in the works on my local shell and development environment toolchain.
Anyways, go to SmallBatches.fm/112 for a link to the flight levels book and my patreon.
I hope to have you back again for the next episode. Until then, happy shipping.