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:
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.