Selectivism
From GTwM
Selectivism (as a Project Approach) that echoes Charles Darwins theory of evolution with a project's survival echoing the survival of a species.
Selectivism is normally employed where project environments have high levels of uncertainty and are technically complicated. It aims to reduce associated project risk by avoiding committing to a specific solution too early in the process. Rather, it advocates eliminating the paths you don’t want to go and retaining those that have yet to fail. This lets several groups work at the same time, as they converge on a solution.
Two of the best known examples of selectivism are Set Based Concurrent Engineering as used at Toyota and the Lean Startups approach described by Eric Ries.
Selectivism is at the very core of most Venture Captial approaches.
Contents |
Set Based Concurrent Engineering
Instead of fixing a design and then iteratively improving it Toyota engineers start with a range of design alternatives, a set of designs. They don't choose one over the others, rather they maintain the whole set for as long as possible delaying any weeding out process. This reduces the number of design decisions that need to be made. In fact there is no decision. It's all exploration for a long time. Designs which are clearly flawed or unimplementable are eliminated without much discussion and there is actually an elegant process for doing this (described later).
Selectivism & Software Development
So how can Selectivism be applied to software? An Agile & Iterative approach can force hill-climbing as the pre-Agile design phase is too short to consider multiple design solutions.
A simple selectivist approach seems to be to accept the need to develop multiple designs at the same time. However, given this could lead to a mess and seems like a recipe for a combinatorial explosion, it might be useful to keep alive a representative of each broad family of designs and kill the others. This retains the Darwinian flavor.
Possible Approaches
- Spend some time perhaps a month coming up with feasible designs for solving a software problem. Narrow the set down to say 5. Implement all 5 each iteration and after a few months narrow this down to 3 and then to 1.
- Adopt the following principle
- Do not make decisions unless they are obvious.
- Defer all other decisions until they become obvious.
- Don't worry about the combinatorial explosion. It might never happen.
- Narrow the solution space using these narrowing concepts:
- Your capabilities: Whatever you cannot implement can be rejected.
- Market research: If you cannot define a market for it, or based on preliminary market research there is no potential market for the product, you can reject it.
- For user interface decisions and for other design issues, if you have no obvious way of making decisions, then don't. Allow the same program to display in different modes using compile time configuration parameters. E.g. use #define to turn features ON and OFF.
Game: Find Your Ideal Partner
Given many people are heavily invested in one of the four major project approaches it is sometimes useful to illustrate the three different project approaches via a tongue in cheek game called "Find Your Ideal Partner".
In this game you split a group into three and ask them to imagine a scenario based on FInding An Ideal Partner using the generic project approach they have been allocated.
The Waterfall approach might plausibly leads to a story that involves writing down what you like and then finding a mechanism such as an internet dating site to find a perfect match to this requirement.
The Agile approach might lead to a story that describes a more believable but somewhat erratic journey to a still "idealised" partner. Tall, dark and handsome might be fleshed out overtime with new requirements such as "must be able to use a dishwasher", however I think most people can see this approach will probably turn out to be unsatisfactory.
The SBCE approach story might well seem the most realistic in that it most resembles how people do go about finding a partner, ie. by eliminating groups over a period of time but keepig an open mind outside of this. For instance "must not be a racist sexist pig" might reduce the numbers substantially but....
Why might we want to take the set-based approach?
Because it lets us:
- defer decisions until the "last responsible moment" when we have the best information
- explore many possible designs at the same time
- converge designs more quickly
