When you look at a map of any complex environment, you have three domains - the uncharted, the industrialised and the in-between stage of transitional. The techniques you use for each are very different, for example in the uncharted space you cannot plan but as things evolve you can increasingly plan.
In figure 1, I show the changing characteristics and which methods are more applicable. In figure 2, I give an example of use applied to a map from 2005.
Figure 1 - Characteristics & Methods
Figure 2 - Map
Now whilst I've used multiple methods from small scale to huge scale endeavours for a decade, there is a major problem with it. Consultants and method priests hate it. The normal approach that is encouraged within corporations is one size fits all i.e. their method - let's be all agile! let's be all six sigma! etc. These are somewhat quasi religious wars where the believers demand their method is suitable everywhere.
Recently there have been attempts to create bipolar structures (ignoring the all important transition) as though creating two groups of quasi religious extremes will somehow magically solve the problem. Hmmm. Been there, bought the T-Shirt. You alas need (at least) three different methods, three different cultures, three different types of people to cope with any complex environment unless you're willing to give something up such as the creation of novel and new. This, by the way, is not new. I've been doing this for a decade and some of the original models date back to 1993.
In the uncharted space, you don't know where you're going and all you have are vague ideas. You need to explore, you need to discover. The one thing you know is you will need to change course rapidly as change is the one constant in such an environment. You cannot plan (other than set a time limit), you cannot write a specification and agile (which is a list of basic principles often best expressed through a technique like XP but not even needing this level of formality) combined with other tools such as hack days is what I've found to work best here. It requires multiple skills from both development and business but you have an unknown problem space and an unknown solution. You just don't know, you might pretend you do but you don't. You are the pioneers, exploring the uncharted waters and any metrics (not that these are much use) are based around how quickly you're discovering. Your goal is a working prototype. Something which might be of use. Of course that doesn't mean you're discovering everything for the first time. You don't have to build a ship from scratch when setting off to explore, that's already quite an evolved act. That's something you use.
At some point, you'll discover something i.e. Land Ahoy! Of course, your "path" is all over the place and in software this translates to a buggy, incomplete, half working, often overloaded with unnecessary features (artefacts of wrong paths taken) prototype. Don't feel bad about that, this is what exploration is all about. However, at least you have a "target". So, the mentality has to change. You have an identified problem space but you have a less than ideal solution. You're now into building a minimal viable product (i.e. something of use to others) and iterating quickly through this. Techniques like XP & Scrum work well but with added constructs (e.g. MVP, Value Stream Analysis, AARRR, Business Model Canvas) as your focus is now on reducing waste along with learning about a specific space as fast as possible and building something useful & viable. This is the transition and this is where Lean comes into play. The nautical equivalent would be building the first trade routes (i.e. how to get from A to B).
However, the act will continue to evolve, it'll become more complete, more well understood and defined. Eventually it becomes suitable for industrialisation. Here your focus changes again, as you know what is wanted (it's a known problem space) but you now need to build volume operations of good enough. Deviation is your opponent and techniques like six sigma will help stamp this out. You're building the empire of scale, the highly industrialised and automated trading routes where ship deliveries are timed to the week then the day then the hour then the minute.
The methods and types of people you need for all three domains are different. The mindsets are different. You have to embrace that.
Alas, the method priests always try to make their chosen method applicable everywhere. Ultimately they bolt on more and more to cope with the different characteristics and when it doesn't work they explain it's your fault for not using the right bits. Ultimately the method which was once suitable for a specific domain becomes less suitable as they take agile and turn it into something like lean or they take lean and turn it into something like ITIL. You can call it all "Lean [something]" if you wish but remember, there are three very different domains.
So embrace the difference. Vive le difference!
