One day I realized that software projects are complex adaptive systems, just like brains, beehives, biological cells, birthday parties, and the tiny ecosystems under my armpits on a hot sunny day. Of course, I wasn't the first with that notion. Ken Schwaber and Jim Highsmith referred to complex adaptive systems in their books on agile project management, and these guys are just a few out of many. But the references have always been casual, addressing concepts like emergence and self-organization, and little else. So, in order to have a much deeper understanding of software projects, and the seemingly never-ending discussions that we face in our business every day, I decided that I first needed to understand the theory.
So, what the hell is a complex adaptive system anyway?
I had acquired knowledge of complexity theory, and I wanted to translate that to problems and discussions in software development. But how? There is so much to tell people about nonlinearity, feedback loops, phase transitions, power laws, self-organized criticality, reductionism, performance systems, fitness landscapes, and the edge of chaos… But where do I start? And even more important… Do people care?
I have been pondering on this issue for six months.
It was while reading the fantastic book Presentation Zen that I realized how to proceed. I should not be telling people how interesting complexity theory is, and what we might learn from it. (This would probably just get me arrested for death by boredom.) What I should do is to try and find some Laws of Software Projects… the things that are always true, or should always be made true. These laws should be presented as a clear and concise message, one that directs people in solving their day-to-day problems, and guiding them in their discussions. Sure, I will need to refer to complexity science. But the theory needs to be presented as a supporting background. Not as an intimidating close-up.
As the target audience I aim for people who need to manage software development activities, either directly or indirectly. This will include project managers, but I also hope to spark some interest among development managers. And as every employee knows: the further up the chain, the simpler a message needs to be. Some of my readers might even be VP's or CIO's, which means that each message should almost be elevator-pitch-sized (and accompanied with fancy pictures, buzz words and bar charts).
Practical management with complexity theory is what I'm after. And if you're interested then there's just one thing I ask you to do… Keep reading!
Note: This post is published automatically while I'm sipping on a cocktail on a beach in Cuba. I will respond to any replies and comments, but it might take a while.