The Success of the Agile Memeplex

I was writing this text right after Christmas, one of the most successful examples of mass delusion of all time. It is a time of the year I always look forward to, and not only because of the food. I admit that I enjoy participating in the silly behavior of putting up a Christmas tree, lighting candles, buying presents, watching movies, and singing Christmas songs, as much as anybody else.

Ideas, concepts, beliefs, theories, ideologies, fads, and fashions are often called memes. People copy these units of information from each other through mimicry, interaction, correlation, teaching, and learning. Santa Clause is a meme; the Christmas tree is a meme; putting presents in stockings (or in shoes as we do here in Holland) is a meme; Rudolf the Red-Nosed Reindeer is a meme; the birth of Jesus Christ is a meme; and angels and elves are all memes.

It is the same with rules, procedures, and practices for software development. They are ideas, concepts and beliefs that people copy from each other through mimicry, interaction, and learning. Stand-up meetings are a meme; pair programming is a meme; refactoring is a meme; iterative development is a meme; and user stories are a meme. Memetics is the study of evolutionary models of information transfer, often in a cultural context.

We refer to a collection of interdependent memes as a memeplex. Christmas is a typical memeplex. And so is agile software development. Universal Darwinism shows us that memes group together in a memeplex because they will copy themselves more successfully when they are “teamed up.” (Genes do the same thing, in which case they are called gene complexes.) Christmas is a successful memeplex in that all the different memes, despite having many different origins, now reinforce each other, rendering them virtually indestructible. Rudolph the Red-Nosed Reindeer probably wouldn’t have survived on his own. But the meme has, quite literally, teamed up with Santa Claus, and now seems to have reached an immortal status.

The Christmas memeplex

Likewise, the memes in agile software development also tend to reinforce each other. Refactoring suggests test-driven development, weekly iterations suggest working with user stories, and stand-up meetings work better with a task board. Most of the agile practices already existed long before agile software development, an argument often heard from agile skeptics. But that’s beside the point. The important thing is that the rise of the Agile memeplex has catalyzed a copying frenzy of the many agile practices, to a level that they never would have reached on their own.

The fact that an agile memeplex is much stronger than the individual memes is something I have been able to experience myself. My early attempts at introducing timeboxes and high-level requirements were total failures, because I selected individual practices that (I thought) would be beneficial for our organization. They failed to catch on, and not because of lack of effort on my part. It was like trying to get everyone to sing to the tune of Rudolph the Red-Nosed Reindeer, in the summer. It just didn’t work. The memes by themselves weren’t strong enough. However, at some point I realized that it was better just to try Scrum. By the book. Scrum was more specific, more extensive, and far more successful than any of my own attempts at process improvement. Scrum is a memeplex. The memes reinforce and help each other to be copied around in the minds of the people. This makes it easier to implement Scrum-by-the-book than it is to implement only timeboxes and high-level requirements.

There are a few interesting observations we can make when looking at agile practices as memes:

1. It can be easier to get people to adopt multiple ideas, concepts or practices simultaneously, then it is to have them adopt just one. (For example: teaching them to apply Extreme Programming instead of only unit testing);
2. In a memeplex not all ideas, concepts and practices need to be beneficial. In fact, some of them can be harmful. But because they are all part of the same memeplex, the bad ideas help the good ideas to be copied around as well, which neutralizes the bad effects. (An example which might be on dangerous ground: I have seen no conclusive evidence of the value of collective code ownership, but this practice seems to reinforce the other agile practices, so it won’t hurt copying it along as well);
3. Removal of individual memes from the memeplex may weaken, or even destroy, the strength of the memeplex. (Example: removal of collective code ownership might lead to an agile adoption breaking down completely);
4. There may exist multiple competing memeplexes that reinforce and need each other because their competition draws attention away from alternatives. (Example: competition between XP, Scrum, and Kanban within the Agile world draws attention to the agile brands in general);
5. Memes may have different origins, and can even be exchanged and shared across multiple memeplexes. (Example: user stories started as a meme within XP, but are now firmly locked into the Scrum paradigm as well).

I think it is useful to think of agile brands and methodologies as memeplexes. Their sole purpose and value is to catalyze the copying of the individual agile practices. Anyone claiming that Agile didn’t bring much to the software development profession that wasn’t already there, completely misses the point from an evolutionary perspective. The moment when self-replicating molecules started teaming up in gene complexes, to help each other being copied around, was pivotal for evolutionary biology. Similarly, from the perspective of cultural anthropology there wouldn’t have been cultures, religions, and sciences, when humans had not invented the concept of grouping ideas and copying them under one name.

I therefore believe that we will look back at the rise of the agile brands, being nothing more and nothing less than named collections of good practices, as a crucial step in the evolution of software development.

(picture by 1Happysnapper)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter –  Subscribe – Newsletter – LinkedIn – SlideShare