How quickly can you evolve?

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 Organisational Transformation programme an entire organisation’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 organisation 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 organisation’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.


  1. I’d replace “repeatable, predictable way to adapt to change” with “reliable way to survive and thrive in an environment that changes”

    1. That’s because you’ve watched the Blues Brothers too many times :)

  2. […] Dan North has a post about how agility is about coming up with a “repeatable, predictable way to adapt to change”. First of all, as we’ve discovered, “Agility” is about marketing, so in a sense, Dan is wrong. However, getting better at software development is about evolvibilty. Adapting to a changing context and working in a way that best suits ythat context is the path to better software development. […]

  3. Nicely said Dan! As a lot of talk, sometimes under the heading of “fragilist” has been taking place lately, I wonder if you see a conflict that I have been noticing. Many agile aficionados tell those resistant or unsuccessful at adopting agile techniques that you must adopt all of them and “do them right”, whatever that means, to be successful. I think reality is that organizations need to evolve as you point out here. So do leaders need to find a way to define success differently so they can see progress as they evolve toward agile methods?

    1. Definitely. Some practices work together to be greater than the sum of the parts, so for instance tracking is far more effective if you have a good definition of “done”, in the form of automated acceptance tests. But any tracking is better than no tracking, so you can start with the obvious stuff and introduce the more advanced techniques once the team gains trust in the process.

  4. Linus Torvalds weighs in on Agility, too (without his using the term)

    > The question is whether Linux can still be designed at
    > current scale.

    Trust me, it never was.

    And I will go further and claim that no major software project that has
    been successful in a general marketplace (as opposed to niches) has ever
    gone through those nice lifecycles they tell you about in CompSci classes.
    Have you ever heard of a project that actually started off with trying
    to figure out what it should do, a rigorous design phase, and a
    implementation phase?

    Dream on.

    Software evolves. It isn’t designed. The only question is how strictly you
    control the evolution, and how open you are to external sources of

    And too much control of the evolution will kill you. Inevitably, and
    without fail. Always. In biology, and in software.


    -Linus Torvalds (from

    1. George Rudolph · ·

      I have have heard of projects that started out trying to figure out what they should do, went through rigorous design phases and implementation phases and were quite successful–even as long as 2 years after I had left the project. I know, because
      I have led them, and been on them, and done those things.

      If, by major software project vs niche project you intend to say something about the size of the project, I think you ought to be more specific.

      And what is a “nice lifecycle”? We all know that lifecycle models are an abstraction, and that abstractions are inherently wrong, if you are expecting one to be correct at every level of detail.

      You are correct–software isn’t designed.
      GOOD software is designed, and redesigned, and redesigned…

  5. post-agilism…

    Recently more and more people are reporting unease at what appears to be the entrenched dogmatism of Agile (with a capital ‘a’)…

  6. evolvability…

    When an organisation needs to acquire adaptability, the best strategy is to evolve towards it…

  7. […] A blog post by Dan North has some great bits on agile software processes, using the analogy of evolution. the various flavours of agile development, such as XP, Crystal, Scrum, Lean and DSDM, are all trying to solve the same problem, … 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. […]

%d bloggers like this: