malvasia bianca

I went to PSL last month; it was a great experience, and the only reason why I haven’t blogged about it here is that there was so much to think about that I haven’t managed to wrap my brain around it. (Well, that’s not the only reason: I’ve been distracted. But it’s the main reason!)

One bit I wanted to mention, though, was something that happened on the last full day of the workshop. That day, we were split into two groups, and each group was told to design a 60-minute delegation-based simulation for the other group to work through. And both groups got a lot from both designing their simulation and carrying out the other team’s simulation; but, from where I sat, it seemed like the other group accomplished both tasks more smoothly than our group. (In fact, our group didn’t manage to reach the desired end goal of the other team’s simulation at all!)

I’m sure there are a lot of factors that played into that, but listening to the other team report out how their design went and watching them carry out our simulation, it seemed like one important success factor for them was their use of set-based design. Our group went through a fairly traditional brainstorming and culling process; that led to us having a single choice earlier than the other group (in both halves: a choice of simulation topic and a choice of topic for our solution to their simulation), which sounds good. In contrast, their group picked three possible choices fairly early on, and dived into those; they then met again, showed all three preliminary solutions to the full team, rejected one and split that team’s members into the other two choices (with also some cross-pollination of ideas between the surviving choices), and dived into those. It wasn’t until close to the end (probably two-thirds of the allotted solution time in the situation I observed) that they’d decided what solution to go with.

But, by the time they’d decided on that solution, it had gone through a lot of refinement. They didn’t just have an agreement that it was the best idea to go with: they had a good feel for how it would work in practice, and knew where to focus their remaining time. So they could spend the remaining third of their time really focusing on refining the last issues. In contrast, the group that I was part of probably got to a consensus on the desired solution faster, but when we had that consensus, that was all we had: we didn’t have any sort of real feel for what the solution would concretely entail. So we had a lot of discovery to do; in fact, it could have been the case (though, fortunately, it wasn’t the case in our examples) that part of that discovery would have been a realization that the solution that we’d agreed to was unworkable in practice.

A very interesting experience. I’d run into set-based design in the lean literature several years ago, and I was willing to believe intellectually that it could lead to faster solutions than a single-threaded approach. But I’d never seen it put into action that way; I’ll certainly have to look for occasions to try it out in software projects.