Shake Up Your Software Processes: The Intermediate Disturbance Hypothesis
While your neighbor’s idea of the perfect lawn might be one type of grass, one type of flower, and one kind of tree, biologists think differently. To them, diversity is the ideal.
In the 1970s, Joseph Connell, an American ecologist, went to Australia to find out how some natural areas could be very biologically diverse, yet a quarter-mile away, there were other essentially identical areas that were not. One thing he consistently found in the diverse areas was evidence of a large change. A rain forest might have had a fire, which allowed the sun to peek through—and other species to compete, leading to a varied collection of flora.
Connell’s theory became known as the intermediate disturbance hypothesis. Its premise is that if an area has low or no disturbance, then a single dominant species will grow in each category of the food chain. Too much disturbance, however, and the weaker species would die off, leaving the dominant species to rule. The key to biodiversity is to get just enough disturbance to shake things up, but not too often.
You probably get the connection to software by now. Most of us realize that organizations that become static get left behind. But what I don’t often see is anyone admitting that too much change tends to create stress, which can lead to the change effort failing.
Every now and again I see a successful company proposing a multi-year conversion to a more agile way of working. Employees are subjected to a huge list of buzzwords: Kanban! Scrum! Continuous integration! Test-driven development! The poor audience gets the impression that if they just “agile all the things,” everything will be fine.
Yet trying to make everything agile at the same time is a prescription for failure, not success.
The lean startup movement popularized the idea of experiments tied to validating learning. Instead of building a product with feature A, we should build a sales page for A and one for B, see how many people sign up for each, and then create the more popular feature. For the software process, though, I don’t see experiments nearly enough.
Rather than designing methods to conclusively reduce uncertainty, I see a desire to simply declare certainty. But it’s hard to continually improve when you’re busy trying to do the same thing all the time.
Instead of premature standardization, I’d rather let teams conduct their own experiments. That gives them something to talk about and compare. It might put a little pressure on a few people to explain things to customers and create shared expectations, but it’s easy enough to standardize the communication protocol with customers and management while still allowing the internals to change.
Healthy teams try just enough new and different ways of doing things, just often enough, to keep experimentation exciting but not overwhelming. That way they know they gave other ideas the opportunity to compete so that the best one will flourish. The lesson here: On a scale of one to ten, go for five, not one or ten. In what direction should your team’s dial move next?
