December 10, 2005

...Learn TDD with Codemanship

Equilibrium & Organisational Death

In recent years, the study of complexity has led medical researchers to some interestingly counter-intuitive conclusions. In cardiology, for example, studies show that patients with greater variation in their heart rhythm are less likely to suffer a heart attack. The more orderly and consistent the heart beat, the more likely there is going to be a problem.

Complexity science has demonstrated time and again that states of equilibrium are what lead systems to die. The smaller the state space - the range of possible states of the system - the quicker it dies. Living systems must occupy a much wider set of possibilities in order to survive and thrive.

The popular term "stuck in their ways" informally describes organisations that have reached equilibrium. When new threats or opportunities emerge, they lack the range of possibilities to find creative solutions. Like giant pandas, when the bamboo runs out they quickly starve.

Adaptability, and therefore agility, require organisations to be nearer the "edge of chaos" that complexity researchers - along with thousands of laypeople and snake oil salesmen - often talk about. At the edge of chaos, many more possibilities exist. Here your organisation is liquid and constantly evolving.

The mistake of many agile coaches and consultants (myself included) is to attempt to help organisations in equilibrium to "go agile". This can be very painful - like trying to reshape hardened concrete. Before we go marching in with our agile planning workshops and test-driven development tutorials, we might like to prepare the ground first. Personal (bitter) experience has taught me the hard way that you have to help organisations become more liquid before you should even attempt to introduce new ways of working or thinking about how to develop software. When organisations aren't ready, the result of attempted coaching can be a bit of a train wreck.

Agile SPI works much more effectively on organisations that are nearer the edge of chaos. I've seen teams achieve amazing improvements in software quality and developer productivity in weeks. I've seen other teams achieve next to no improvement after 6-12 months. Without exception, the teams working in rigid management heirarchies, in IT organisations that have been slowly cooling down and hardening for decades, get the least out of Agile SPI (or any other kind of process improvement, come to that.)

There's a definite need for change before Agile SPI begins. Actually, let me put my business hat on for a moment: there's a definite need for Agile SPI to begin by addressing the liquidity of the organisation. How could this work?

The way to reduce the chances of a heart attack, along with clean living, is to do some gentle cardiovascular exercise. By gradually raising the heart rate, bit by bit, we can train it to occupy a wider state space - to be more irregular and chaotic, and to adapt more readily to rapidly changing demands for oxygen around the body. This is usually referred to as cardiovascular fitness - (at least, that's what I've been told)

Organisational fitness might be measured by how readily organisations adapt to rapidly changing demands from the business environment. We could probably test their fitness by applying a series of exercises designed to see just how rapidly they can adapt, and to gauge the variation in their performance. Exactly what shape these fitness tests might take, I don't know yet - but I suspect they might involve throwing little challenges at the teams and seeing how quickly they can meet them, and how quickly they can get back to a "resting heartbeat" afterwards. For example, how long should it take a fit organisation to put up a new whiteboard? I've seen teams sort that out in a day or two (they've got to buy one first!), and I've seen organisations take 3 months (and involve the IT director in the decision...) Or how about the time it takes to get a team of developers on a training course. Again, I've seen organisations that can organise internal training in days, and others that have to schedule training months in advance.

In his book called Slack, Tom DeMarco suggests that teams need extra capacity to meet unexpected challenges. If everybody's giving 100% all the time, and something comes along that requires an extra 10% for a day or two, where's it going to come from? This is equivalent to our resting heart rate. If our resting heart rate is 90 bpm, then there's less extra oxygen-carrying capacity should we suddenly need to run away from something big and nasty. If we can function at rest on just 60 bpm, then there's plenty more spare capacity.

Organisational fitness is a measure of how much spare capacity there is, how quickly it can be called upon if needed, and how quickly teams can go back to a comfortable pace again after the emergency is over. Teams that give 100%, week after week, are headed for a project coronary.


Posted 15 years, 1 month ago on December 10, 2005