Skip to main content

Evolution and the culture of an adaptive organisation

One of the books that has most influenced my thinking about agile methods recently is The Origin of Wealth by Eric Beinhocker (Random House 2007, McKinsey & Company Inc. 2005). It's a book about economics rather than software products or development processes, so it's perhaps unsurprising it's less well known in agile circles than it ought to be. However it contains some key ideas vital to understanding the context of agile methods, specifically how products and processes evolve. Significantly it points the way for agile methods to focus on the evolution of process rather than simply the evolution of products - an insight Kanban has brought sharply into focus in recent times (not without controversy it has to be said!).

The mechanisms of evolution are the same whether the subject of evolution is a life form or the elements of an economy. These mechanisms - copy; differentiate; select; and amplify; repeated over many iterations - occur in all instances of evolution. Beinhocker demonstrates that the process by which "Physical Technology" and "Social Technology" have developed in the history of human economic activity is evolution. It's not just like evolution, it actually is evolution, with similar characteristics advantages and drawbacks that arise from it.

Furthermore its success is absolutely remarkable in both the scope of economic growth and its accelerating speed. Physical Technology refers to the artifacts of human activity from pottery and stone axes to razor blades, mobile phones, insurance policies and car washes - "product" is perhaps a simpler term. Social Technology refers to the means by which humans organise themselves and the mechanisms they use to produce the products of the economy - again I prefer a simpler term, "process". Products and processes have been evolving in an accelerating manner over millennia. At this point in history it is essential to economic survival, not only to understand these mechanisms, but also to actively participate in them. As others have said: "change - like survival - is optional!"

One of the most relevant sections of what is after all a fairly dense 600+ pages, occurs at the end of the book. Beinhocker turns his attention to how businesses need to behave within the very rapid cycle of innovation that now characterises the economy. Evolution is taking place outside organisations whatever organisations do. Whether it happens within an organisation however, and thereby enables the products and processes of the organisation to evolve sufficiently to survive and thrive in the new context, depends on the culture of the organisation - whether it is an "adaptive organisation". Rigid hierarchical organisations can survive if their context (market) is either controlled by the organisation itself or changing only very slowly. When enough change occurs to allow new organisations to compete, such rigid organisations disappear. In fast moving markets only "fit" organisations can survive in the long term.

Here is Beinhocker's summary of the characteristics of adaptive organisations that can survive in today's markets:
  • Performance norms
    • Performance orientation – people go the extra mile, continuous improvement expected
    • Honesty – people are honest, transparent and face reality
    • Meritocracy – rewards are set on the basis of merit
  • Cooperating norms
    • Mutual trust – trusting and trustworthy
    • Reciprocity – the golden rule
    • Shared purpose – common goals above personal
  • Innovating norms
    • Non-hierarchical – quality of the idea over status of proposer
    • Openness – curious, outside thinking, experiment, seek the best
    • Fact-based – facts rather than opinions ultimately count
    • Challenge – competitive urgency, race with no finish line
These are the characteristics that allow evolution to occur within an organisation - not just by its death and replacement. Are you struck, as I was, how closely this mirrors the goals and norms of agile teams?

It is no coincidence that agile values match those of adaptive organisations. Agile methods recognise evolution as the key mechanism at work in improving products and improving processes. Kanban as defined in +David Anderson's Blue Book explicitly calls out evolution as the mechanism of change in its principles. Furthermore it has made the key leap beyond earlier agile methods that proposed a static Social Technology to implement evolving Physical Technologies (i.e. the use of a pre-defined process). Kanban applies evolution to the Social Technology itself. Kanban in that sense is a meta-process, a means to keep organisations in Beinhocker's "fit" state by evolving the processes it uses. In my view this makes it important for all agile teams to understand, whatever label they apply to their own current process.

The way you yourself change is at least as important as the way you change the things you are producing.
Post a Comment

Popular posts from this blog

Does your Definition of Done allow known defects?

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy. 

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

"Plan of Intent" and "Plan of Record"

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…

Understanding Cost of Delay and its Use in Kanban

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…