Set-Based Concurrent Engineering
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.
Something slowly changed in my brain around problem-solving. It’s changed how I think about the daily work of software engineering and problems outside work. Now, it’s an inescapable habit.
I realized this when someone asked me a question and I had an instant retort. It was worth remembering that I made a mental note that spawned this episode.
So where did this habit start?
Years ago I read the book “Decisive” by Chip and Dan Heath. It’s a book on decision making. One tactic in the book is avoiding binary framing. Their point was that we boxes ourselves into a choice about _this_ or _that_. Reasonable advice in my book.
Now fast forward through years of self-study on lean, target-condition problem-solving, and A3 thinking. Key words kept recurring: “viable”, “menu”, “options”, “alternatives”, and “problem-solving”. That formed a phrase that I keep going back to: “a menu of viable alternatives”. A ton of context is compressed in that phrase.
The menu points to variety. Menu also refers to something we’ve all experienced first hand: choosing something to eat off a menu. There are a variety of options with some similarities. There may be salads, seafood, or soups--perhaps with similar ingredients but different dishes entirely.
However, they all may not be viable. If you have dietary constraints, then some portion of the menu is simply not viable. Have a deathly peanut allergy? Guess you’re not having the fancy peanut butter and jelly sandwich. Focusing on the viable options narrows the field.
There’s value on the flip side too. One must understand what _makes_ something viable in context. Something viable for dinner but not for lunch. This is a forcing function to define the constraints, thus an even playing field for consideration.
If you cannot determine viability then the warning indicator turns on. That means one, two, or three things. Either you haven’t studied the options deeply enough or you haven’t studied the problem space well enough. Or, it could be both.
Lastly there is the word alternatives. There is a magic number of menu items. One is not a menu. Two is a coin flip. That’s the problematic binary thinking from earlier.
Magic begins to happen at three items. Now the variety and contrast begins to show. Four, five and six, indicate enough study has identified more possibilities. Usually we can come up with one or two options quite easily. Three may be more challenging. Push through it. You’ll uncover the divergent thinking needed for deeper understanding of the problem at hand.
This is where the “menu of viable alternatives” move into a core lean competency: Set-Based Concurrent Engineering or SBCE.
SBCE is an approach to design where developers consider sets of ideas rather than single ideas. This is somewhat an emergent process. Let me explain using the dinner menu concept.
The menu contains different sets of dishes: soups, sandwiches, salads, appetizers etc. Each of these sets has its own trade-off. Appetizers are not full meals, so they must be paired with something else. Hopefully, they’re a bit lower cost and a wide variety so someone could choose a few different appetizers.
Sandwiches are great because they can come sides but require bread--which could be an allergy problem.
Potential options in each set may be generated from available ingredients, aim of the menu itself such as high-brow, comfort food, or classic cuisine, and the expertise of the staff. This requires a bit of design targets: say a menu that only uses unique regional produce. Now, design soups to fit.
The potential options may be iterated and test on by the staff and potential customers. Perhaps the tests are positive on certain dishes, though they are costly to produce. That could be a problem, but that cannot be determined until the financial side of the business is cleared.
Each iteration on the ideas informs work on the other set of ideas. That experimentation leads to learning and a deeper understanding. The final design or decision is delayed until the team knows enough to make a good decision. This is the iterative, experimental, and empirical side of problem-solving.
This type of thinking is only possible with a menu of viable alternatives. Seeing many alternatives allows you to remix them into new options. Moreover, it helps discover other ways to identify better viable alternatives. This is how teams _converge_ on a decision. It’s a fundamental different process then selecting a design first then proceeding forward.
This is why creating a menu of alternatives is key to problem-solving. Without alternatives, there are no trade-offs, only consequences.
I’d rather choose my trade-offs then be handed consequences.
All right that’s all for this batch. Head over to https://SmallBatches.fm/88 for links to recommended self-study and ways to support the show.
I hope to have you back again for next episode. So until then, happy shipping!
Creators and Guests
