Dave Snowden

Scaling: merge, match & masticate

RSS Feed

Scaling as a subject seems topical at the moment.   Cognitive Edge has been working with the UNDP on how do you scale success in the development sector and we recently ran a fascinating event in New York look at the science of how complex adaptive systems scale which is now moving into early experimental use.  At the same time in the Agile community we have the controversies over SAFe where scaling seems to mean ​how do I get senior IT management to adopt Agile practice rather than how do I scale success per se.  Now both of these are important areas, although in the latter case the question could be better asked as How do I engage the non-IT C level in what Agile can offer;  a very different question and a more relevant one.

I've used fish scales as the illustration for both this post and my last one both for the obvious reason, a visual metaphor and a scientific principle.  The visual metaphor is that the scales of a fish are all of a similar size and overlap each other to create the whole.  The size or granularity is key here, note they do not aggregate and the properties of the whole are not the same as the parts.  The scientific reason is that fish scales exhibit fractal and self-similar qualities.  A definition here (and wikipedia is good on this:

A fractal is a natural phenomenon or a mathematical set. What they have in common is a repeating pattern that displays at every scale. If the replication is exactly the same at every scale, it is called a self-similar pattern. Fractals can also be nearly the same at different levels.  Fractals also includes the idea of a detailed pattern that repeats itself.

Fractal understanding is important here and I'm going to be fairly constrained in how far I can take it in two posts.  So I am going to assume some basic familiarity with Cynefin and in particular dynamic moves between domains.  I'm going to move on to the first case of scaling success in tomorrow's post.  nbsp;Today I want to focus on the issue of scaling up in the sense of engagement/involvement.   I'll bias this a bit towards the Agile v SAFe issue (and it is an either/or) but it has more generic application.

Its important to remember that in Cynefin scaling (in terms of visibility and impact) happens when you can achieve a dynamic move from the complex to the complicated, from experiment to exploitation.  In IT Scrum (a part of Agile but not the whole of it) does this by controlled iterative experiments at a project level.  It still assumes a defined need at a level of granularity that will gain sufficient buy in to get resource allocation and with enough evidence of possible use to support that (reference here to the complex domain model)

So if we want to scale a technical capability or method (such as Agile) into another domain (such as management) we don't start in the complicated domain, instead we want to change the nature of interactions in the complex and at an earlier stage of formation that we normally see with prototypes of all types in all organisations.  That means we need to take an approach, like the fish scales, which allow us to overlap both capability and need at a small scale, the overlaps as they gain coherence then allow more stable needs to be constrained to the point where they become general practice.  There are various ways we can do this:

  1. Multiple small, safe to fail experiments at a much earlier stage of proof that is normal for prototypes.  Basically if there is some coherence to an idea of something that might work, we run a quick experiment to see if it is possible.  Ideally we do that as one of a series of such experiments which take place in parallel and have sufficient diversity to contradict each other.
  2. Those experiments need to engage people from different parts of the organisation using their real world issues, opportunities expressed in their own language.  So we can couple user micro-narratives with technology capabilities to see what new opportunities emerge from the interaction.  We don't assume that users can define needs in a traditional sense as they will have little knowledge of what technology can do until they have it.  But we do know that if we couple people with knowledge of both domains, early enough in the game that failure is a part of the process not something to be avoided, that novel or new possibilities will emerge.   I've talked about the use of exaptive databases here, most recently in Trieste and that is a level on, but still the same idea. 
  3. Engaging senior executives requires addressing the issues that keep them awake at night and avoiding the broad brush mission and objective setting stuff that too easily generates platitudes.  This is also a major issue with reductive approaches that try and define a wide problem, then start to break it down.  We need to shift to solving small problems and allowing them to combine and recombine in a evolutionary way so that large problems don't occur in the first place and large solutions are emergent properties of multiple interactions over time.   For the IT community Object Orientated architectures and design methods are a real gift here but rarely used in organisation although they underpin the value and resilience of the app marketplace. That can be done at low cost, almost beneath the radar and will scale faster.
  4. All of those are enabled by micro-narrative continuous capture, in particular journaling of day to day experiences.  Such approaches create an evidence based approach build on reality, not the the rarified air of a workshop or design experience.  One major issue here is that the whole design thinking movement is focused on product (by its examples) not service and the latter is more important in a changing world.

So to scale practice, we need to keep the granularity similar between need and capability then use enabling constraints to merge, match and masticate the two until novel and resilient matters emerge that can be sustained and scaled in more conventional ways.  Building large complicated models with lots of structure and accreditation courses may make money for the trainers, but it will not create a sustainable business.

More tomorrow and there will be a seminar covering all of this in Sydney this Friday – if you are on the Cognitive Edge mailing list you will get something later today (along with a big discount) or just watch my tweets.