When Darwin’s “On the Origin of Species” was published, evolution was already a well-established idea. Darwin’s insight was that evolution—through the process of natural selection—led to the introduction and extinction of entire species. This of course upset the established church, and to this day there are still religious groups who reject the idea, in the face of overwhelming scientific evidence.
The early twentieth century saw the rise of “neo-Darwinism”, which finally provided a mechanism for natural selection. It wasn’t happening at the level of creatures but at the microscopic level of genes. Natural selection is simply the playing out of a long-running stastistical game based on shuffling genes, and more disturbingly the creatures themselves (and ourselves) are just a very sophisticated form of temporary accomodation for those genes!
Richard Dawkins, the acclaimed scientist and author of “The Selfish Gene”, goes a stage further. He suggests that a species’ ability to adapt or evolve may itself change over time. In other words, evolvability is a trait that can evolve, just like a tail or gills.
Agility is another word for Evolvability#
So what does this have to do with the world of software development? Well the various flavours of agile development, such as XP, Crystal, Scrum, Lean and DSDM, are all trying to solve the same problem, namely coming up with a repeatable, predictable way to adapt to change. In other words, they are trying to make software delivery evolvable. This ensures that delivery isn’t wrong-footed by a change in the project’s ecosystem or environment.
As an agile process coach, my job is to increase a team’s—or in the case of an Organizational Transformation programme an entire organization’s—ability to evolve. Taking a cue from Mother Nature, you can’t expect this to occur overnight. The weight of evidence shows that macro-mutations in the process are almost always going to be detrimental. Instead you need to evolve the organization towards evolvability, or agility, through a series of small steps that are easy and intuitive to grasp.
You can’t just walk in and announce that “this is how we do things now”. You need to take the time to understand and appreciate the existing ecosystem, and present the change process as a simple and natural way to improve delivery. At a getting-things-done level this is usually pretty straightforward: tested code tends to break less than untested code, and paired code tends to be better designed than solo code, so the incremental changes are intuitively a Good Thing.
At a project management or governance level the messages are more subtle. It’s not about how quickly or accurately you can deliver. You can put a bunch of bright people in a room with a big enough incentive (be it carrot or stick) and software will come out. Instead it’s about how resilient the process is to some sort of disruption.
Delivery Assurance addresses exactly this, and agile delivery is the most effective way I know of managing this risk. By pair programming you reduce the impact of a single person becoming unavailable or leaving the team. By applying the principles of test-driven (or behaviour-driven) development, you eliminate the risk of introducing regression defects into the codebase. Adaptive planning and tracking—and their resultant incremental steering and project funding—leverage this to provide programme-level adaptability. The requirements can change, the political environment can change, the goalposts can move, and you are still in with a chance of delivering something useful.
The more you can evolve an organization’s evolvability, the more resilient you make it to change, and the better it can adapt to changes, both internally and in the external market. As Kent Beck famously said, embrace change. It is inevitable, and your chances of survival are directly linked to your ability to evolve.
ps. Thanks are due to Mats Helander for the casual comment that inspired this article.
