Lean tools: Set-Based Development

Agreement over a decision can be reached either via point-based proposals or via set-based ones; in this context, the decision can be a design-related one like which database to use, with a list of proposals from different people and teams that everyone must agree upon.

Doodle

Doodle is an example of application using set-based development to schedule meetings. It works in the following steps:

• the creator of a Doodle sets up a set of possible dates and times for the meeting.
• Every invited participant chooses a subset of these dates that will suit their constraints.
• A date can be finally selected where most (of all) of the involved people will be available.

The result is an agreement between N parties that fully utilizes the bandwidth of information exhanges: instead of a conversation where everyone proposes a single date and vetos or agree over the current one multiple times, we get everyone to only view the Doodle once.

Latency

The advantage of thinking in sets instead of points is to keep options open as long as possible: there is no reason to commit early to a decision when there are actually many options available that could suit other people better if only they could be selected in a further optimization phase.

Moreover, agreement between N parties always involve a relevant set of communications to be set up; set-based development tries to maximize the amount of information extracted by each party by making him specify his best 10 choices instead of just the best one.

As in the Doodle example, when every interaction has some latency (like the time to respond to an email or to have a physical meeting), the time spent to reach a decision is reduced from this interactions:

• A: I prefer solution 1
• B: I prefer solution 1 too
• C: I can't work with solution 1
• A: I prefer solution 2
• B: I can't work with solution 2
• A: I prefer solution 3
• B: I prefer solution 3 too
• C: I prefer solution 3 too

to the following:

• A: I prefer solutions 1, 2 and 3
• B: I prefer solutions 1 and 3
• C: I prefer solutions 2 and 3

to reach the same agreement on 3 (the date of the meeting in our example). If you have never seen a discussion following the first pattern, raise your hand.

In fact, while it is still possible to schedule a meeting between two or three people via email, the approach does not scale to more participants and Doodle solves the problem via Set-Based development by minimizing the total latencies that an agreement has to wait.

Multiple options

Producing a single design does not guarantee it to be the best, both in programming and at an higher level of abstraction while deciding how a story should be implemented. In each stage of development we should be able to produce some options before making a decision: Set-Based Development tries to make everyone communicate its constraints so that the only possible decisions amerge from the total set of available ones. It originated from tangible object design, where sets of possible esthetic decision must not clash with sets of possible engineering or manufacturing ones: you shouldn't draw a chassis which reveals itself to be fragile in accidents or too costly to solder.

Even in an iterative model, which can rework design decisions late in development, set-based approaches drastically reduce the number of iterations needed to reach convergence to a decision that satisfy all constraints.

Here are some other examples of set-based approaches in computing:

• a database abstraction layer let you work on multiple database at any time, multiplying your options and making only the necessary constraints (on functionality supported only by some vendors) emerge.
• Mark Needham reports an example of concurrent tryouts of different types of dependency injection techniques in a particular container.
• A/B testing is based on develop multiple solutions and propose them to disjunct user samples to measure their effectiveness. This approach is taken to the extreme in Lean modern companies where each feature has to be A/B tested before going into the trunk.

Conclusion

We will see more about options in the next articles of this series, which will explore the Lean philosophy of the last responsible moment. For now, we are happy with trying to find multiple solutions to each design problem to augment our options; then, we will try to gain not only an advantage in variability but also in time commitments.