At LPPDE Europe 2018 (Paris) I joined the workshop of Penny Cloft and Michael Kennedy. The workshop was on set-based engineering (SBE). If you are like me, then you know that set-based engineering is one of those things any lean product development novice learns it is part of applying lean to product development, but, at the same time, requires a conceptual understanding that makes you walk around it for a while first.
In my case this "little while" took more than seven years, until I came off the role of "lean PD coach" and onto the role of project manager in the front-end of produt development. At that point, I noticed looking backwards, the three things that (apparently) are required were in place:
- I owned the problem,
- the problem required set-based thinking,
- and I did understand roughly what set-based thinking is and why it is important.
Anyway, I was in this workshop with Penny and Michael at the same time I was owning the problem. (You call that just-in-time, I reckon? ;) ). The workshop Penny and Michael delivererd was featuring the bake of a brisket. A brisket is a kind of cow meat made in a Big Green Egg, that you normally cook about 24 hours. Michael must have made dozens of briskets to get to a neat set of trade-off curves, enabling him to lower cooking time to 11 hours without loss of quality of the end result. Michael captured this knowledge in a set of trade-off curves, so that he easily can reuse the knowledge to optimize moisture, tenderness or taste. In the workshop, participants were asked to first use not-set-based type of "knowledge" (or should I call it "data"? - it was what many teams tend to call knowledge, there were different graphs and tables that summarized information gathered, you would say that already a lot of knowledge was created. Do you also recognize that from your real-life projects?) to define a cooking strategy. After that, the set-based knowledge was shared and you could extract the sweet-spot of perfect cooking strategy right away.
In the Thalys (high-speed train that connects Paris and Amsterdam) back home I figured I needed to understand how I could create this type of knowledge. I didn't yet feel confident to use it directly at my problem at work. I decided to set-up a similar experiment as Michael did for the brisket, to save lots of time I used a product that I liked a lot and takes only roughly 15 minutes to bake: sand cookies.
In the weekend that followed I did many experiments, baked cookies (the funny thing is: I could write "baked many cookies, but they were much less as you might expect if you wanted to figure out the sweet spot of a recipe, baking time and temperature - well over five parameters to vary) and figured out the sweet spot for our favorite family sand cookie: soft and brittle.
After that, of course, I took the knowledge to my workplace and started to apply the set-based paradigm more and more. First, it was basically about thinking in curves rather than in points, after, we added the smarter ways of making curves (thinking about: what are the trade-offs in this case?) and gradually also focus at getting different type of data in the first place. This is of course a longer path, that continues until now, discovering better ways going forward. I experienced that the old paradigm of product development (diverge, then converge quickly to find the best options) is not only strong in my organization, but also more embedded in my own thinking than I would want to - I really need the Hansei moments (moments of self-reflection: as a project manager I realized that the ability to switch back and forth between "see the details" and "see the whole" is one of the most important, yet difficult things to do to be a successful project manager in front-end development) to see the opportunities to approach the problem as a set-based problem.
I wrote a summary of my cookie experiment that you can retrieve here (will open in a new tab). I hope it inspires you to also conduct a learning experiment to get your head around set-based engineering. It is worth it!
Suzanne, great article. I am glad to see our workshop resonated with you. The challenge is to get people who live by cost and schedule metrics to see that point based solutions aren't helping them. Taking some time up front to understand knowledge gaps and trade-offs is counterintuitive to their metrics, but in reality will cost less and reduce schedule misses. These trade-off curves and closed knowledge gaps will help them to do even better in they're next product development project.
Understanding the problem and finding the solutions is one of the most complex issues in projects.
Nice to see that Suzanne is working in a structured way to tackle the issues.
And there are many to solve still even in a business like coffee. When you dig deep you will find a lot of black spots.
Unfortunately the link to the cookies experiment did nott work Suzanne.
Hope to get the right link sometime.
Thanks Pieter for your kind words and for your notification on the link. It should work now!