11: You can’t reduce or aggregate a complex system and trying is wrong a priori
Reductionism in human thinking goes back to the early atomism of the Greeks and in a real sense we have never really shaken it off! The idea is that you solve a problem by breaking it down into smaller parts, solving the small problems then putting it all back together again. Workshop techniques do the same sort of thing; breaking things up, sending people to separate rooms then aggregating the results from multiple sets of butcher paper.
Aggregation is the corollary of reductionism and it is the common approach to both scaling and integration. Putting things together in wider constructs based on defined interfaces or formal links. All of this harks back to my earlier concerns in this series about categorisation, putting things into boxes and then fitting them together like a jigsaw. Often the jigsaw pieces are simply forced together in the manner of a five year old who has not yet acquired the spacial awareness to do anything more subtle. One example of this is SAFe which claims to scale Agile by simply fitting together anything with a popular name regardless in the main of its nature or utility. SAFe creates a big picture by simply putting things together to create a safe (in all the wrong senses of the word) narrative for senior IT management to say they are being Agile. I’ve seen similar stupidity in mergers and acquisitions where things are simply slammed together or integrated based on partial or incomplete understanding. Often this is driven by the need for survival (understandable), status (understandable but less excusable) or simply to make money from training and ‘accreditation’. If you want evidence of this in SAFe by the way simply look at the way they allow people to run training after attending a course based on a simplistic assessment. In effect you buy the right to make money. My favourite Magpie adopts the same approach, cobbling together bright shiny things to create a fun environment. Money appears is the objective not meaning.
Now the real problem with all of this is that aggregation and reduction is fine if you have a highly constrained system. However if we shift to a complex one then the properties of the system as a whole is not the sum of the parts but are unique to the system as a whole. So if we want to scale capabilities we can’t just add them together. I’ve already written on scaling in a series of posts (final one here) so I won’t repeat that. However there are some key stages we need to go through if we are integrating different or even similar things:
Now this is a modification of standard Cynefin and one I will be elaborating in Zurich at the end of this month. The point is that you cannot predefine the nature of what will happen when you bring things together, but you can enable its emergence.
Otherwise when we have a complex problem we experiment in parallel, we do not reduce into parts. Now all of this is true a priori in a complex adaptive system. So things like SAFe are simply wrong of themselves because their approach can only word for an ordered system. Mind you its order their masters really want so that is no surprise. SAFe is not exceptional by the way, its simply following in the same path as balanced score cards, KPIs, Mergers based on structure not people etc. etc. The automation and mechanisation of the engineering metaphor has dominated thinking for the last few decades and it is predicated on aggregation and reduction. Things like SAFe and Sick Sigma are simply the last attempts to get a tired and inappropriate philosophy to work but doing things that have failed with more intensity in the hope that this time they will work.