Thread by @swardley

X : Any thoughts on Agile?
Me : Hmmm ... I assume you mean XP (as in @KentBeck). It's excellent, a really good method in the right context.
X : So you would always recommend using it?
Me : In the right context, yes.
X : What's the wrong context?
Me : When it's not suitable.

X : How do you know if it's not suitable?
Me : Use a map.
X : How does that help?
Me : Do you understand how things evolve?
X : You mean like better products?
Me : Hmmmm ...

Me : Let us take a "Thing". It could be anything, for the sake of this example let us pretend it is the introduction of teleportation. Now obviously, teleportation will be something very novel and new which we will barely understand but we will marvel at its wonder.

... now, if you introduce teleportation then others will copy. Before you know it, we will have competing forms, competition run amok until it becomes so widespread and commonplace it's more of a commodity. Teleportation will evolve through different material instances.

... I use the words different material instances because the characteristics will be different. In early stages, the thing (i.e. teleportation) is in an uncharted space and all unknown. As it evolves (through hundreds of diffusion curves) it becomes more defined, more understood.

So, what you have are different material instance of the thing but they all share the same meaning (i.e. teleportation). At this point, go read some Elizabeth Shove and Social Practice Theory.

Now it's not just things that evolve but practices. So, for example, XP (i.e. Agile) has evolved to become very good at dealing with that uncharted space where change is a constant, a desirable. It's very competent at this.

But there are other competencies i.e. lean and six sigma which are very good (i.e. competent) at different material instances i.e. six sigma is great for utility and volume operations where deviation is undesirable. Of course, these techniques themselves have evolved.

Now, despite them being very different competencies (agile is not six sigma) they share a common meaning e.g. project development.

Each competency is suited for a particular material instance because they cope with different characteristics. Unfortunately people always want to create the "magic one size fits all method" - it never works, never will.

What you need to realise is something which I've been banging on about for now 15 years ... 15 bloody years ... christ ... you need to use appropriate methods.

In order to do so, you first need to map your environment i.e. start with user needs and deconstruct the environment into components ...

... then you can apply multiple methods to it. What you discover is almost all large systems require multiple methods i.e. all that outsource everything, agile everything, neoliberal everything, centrally plan everything is just bullshit from the hard of thinking.

What you discover is you can't do any of this stuff based on stories and I'm a grumbly sod having to repeat this again.

This was solved 15 years ago. Outsourced a project and it led to massive cost overruns or Agile didn't deliver? Chances are, you're just an effing idiot.

X : That's harsh.
Me : I have no time for those looking for a magic one size fits all. Map your landscape, apply some thought to it.

If you want a more forgiving version then talk to kind people like @kda, @HiredThought, @CatSwetel, @lunivore, @Rachel0404, @GoAgileGov etc etc.

... there's an entire community online around Mapping. @jhngrant does a wonderful job of keeping an awesome list together - github.com/wardley-maps-c…

Get involved, ask people for help.

X : What do you think about SAFe?
Me : Seriously? Is this poke the bear until it chews your arm off day? It has a context in which it works but it is trying to become the magic one size all encompassing method.

Go Wagileleansigmafall that project!

X : Isn't mapping a one size fits all?
Me : Mapping doesn't tell you what to do, it just helps you create a common understanding of a landscape and challenge the choices that you are making. To decide what you need to do, you take a map and apply thought / experience to it ...

... others can then challenge until you get to an agreement. This should be a quick process and what mapping has taught me, is there are no size fits all methods to project management, finance, HR, operations, purchasing etc etc etc. You need to use multiple.

My form of mapping is however a very imperfect one size fits all method to creating a map ... it does this one thing. Fortunately, there are slowly other forms of maps appearing,

X : Like mind maps?
Me : That's not a map, it's a graph. Most things we call maps in business aren't actually maps.
X : What's the difference?
Me : In a map, space has meaning.

X : How do you maps fit in with @snowded Cynefin?
Me : Cynefin is an excellent decision making framework, it helps you decide what to do / how to respond. Understanding your landscape can assist in that. They are complimentary and have a common basis.

X : Aren't your evolutionary stages ...
Me : No. Let us take the map of culture (slightly different axis). You have some fairly obvious concepts (1), some more novel to emerging concepts (2), you have complex behaviour through feedback loops (3) and the map is complicated (4) ...

... now, let us look at where I started. This is my first map of culture.

So to begin with, it's all chaos, I have nothing to base anything upon. The map itself emerged out of interrogation, investigation and experimentation.

... this doesn't mean culture didn't exist before, it certainly doesn't mean that my map of culture is right but the nature of my decisions, what I do to refine my view changes as I gain more understanding of the space.

As a guide to helping you make those choices, those decisions ... I can't think of anything better than Cynefin.

X : How do you got about ensuring a team and their methodology are a good fit for each other (and the culture, the context, etc)
Me : Ok ... well ...

... first you start by identifying the users involved in a space. There can be many i.e. public consumers, government, the business etc. Let us keep this simple with one group called "users" ...

... then you need to find out what they need, and what components are involved in meeting those needs. You have to know the details. Then map this all over evolution. It's quicker than most realise. No more than a few hours.

Then you allow others to challenge, to point out missing components and help create a common understanding of the space.

At which point you share your maps more widely with other groups and hopefully take out any duplication (you'd be amazed at how much duplication goes on) and any inherent bias in the group by comparing maps. This is all part of a pre-mortem, questioning and challenging the space.

Now you break the map into small contracts. Try not to minimise crossing the stages of evolution in a contract ... the characteristics are different and so different methods / purchasing mechanisms and contracts are required.

Now you can apply appropriate methods to those "contracts", you know the interfaces with other systems, you can define outcomes where possible (or a fitness function for the team), you can determine what should be outsourced or insourced and at least have sensible discussions.

Of course, with an understanding of the space, appropriate methods, interfaces, needs and outcomes ... then we may as well use small teams to build or manage the space. Those teams will require many aptitudes i.e. skillsets - finance, engineering, marketing etc.

At this point you realise that not all aptitudes are the same i.e. engineering in the novel and new is not the same as engineering in the more commodity. So, you realise you have attitudes as well - pioneer, settler, town planners - al of which are important.

At which point you realise that all the components are evolving due to competition, so your structure is going to have to mimic this evolution. That which is novel will flow and become commodity at some point.

So your choice is either create some sort of team that can cope with the evolution of technology despite different attitudes being needed ... or create some sort of structure that allows for evolution ...

So, you go look at your structure, like I did in 2003. Whoops, I've built it all around aptitude (skillsets) and small cells containing mixes of aptitude. Not a hint of evolution anywhere. What a plonker I was ...

... so the first thing I did was to restructure around attitude (pioneers, settlers, town planners) with different "guilds" of aptitude (finance, engineering) running across ...

... then add on cells with the same attitude (but different aptitude) and allow cells to steal / invade each other (the system of theft). Town planners steal from setters who steal from pioneers etc ...

... now we can write up those characteristics and realise we're not just hiring engineers or marketers but different attitudes of each - pioneering engineers and town planning engineers - all of which are important.

So rather than trying to fit people to your process i.e. take a pioneer and send them on a three month six sigma course or a town planner on three months of agile ... we appreciate the difference and value each attitude along with each aptitude (finance, engineering) ...

... brings. They're all important

Here ends the lesson, circa 2006.

X : I think you mean "try to minimise" the crossing the boundaries of evolution with any contract.
Me : Whoops. You're spot on.I did. Typos and no edit function ... oh well. At least others are thinking.

X : Big projects always tend to fail, it's a consequence of size. It's why you should split projects into small parts.
Me : Whilst I don't disagree with splitting into small parts, that's not quite the whole picture.
X : Explain.

Let us take a project, shown in the diagram (nb this is not a map). Have a look and take five minutes to ask - which bits should we outsource, what do we build in-house, how to manage the component?

Now, for that simple diagram there are 300M+ possible permutations to the question of what to outsource, what to buy with off the shelf product, what to build in-house. Let us say, to keep our lives easy we outsource the lot.

How would you break this into contracts?

Ok, let us group things into contracts (and we will break this into four things i.e. smaller is better!) ... contract 1 is more engineering process, contract 2 is more customer focused, contract 3 is more business, contract 4 is infrastructure. Take a look.

Spend a few minutes having a look at the diagram above. Now we haven't started the project yet but can you see which contracts will spectacularly fail causing massive cost overruns?

I can but then I've cheated. I also have a map.

This is the map, which was created by the people running the project ... it took a few hours. Have a look. You might disagree on components position, you might not even understand every component ... that's ok.

Let us overlay our "contract" structure onto the map ... can you see the problems now?

Contract 2 and 4 aren't too bad ... hey I've seen much worse. But contract 1 and 3 are shockers. They might seem sensible in diagram form but a map sends up red flags. Why?

It all goes back to using methods where appropriate. Contract 2 and 4 were mostly commodity components we outsourced. Not bad. But 1 and 3 contains lots of uncertain components which we're trying to specify in a contract ... bad move.

Take contract 1. Even within this contract there are components which can be outsourced, specified and treat like components. They will work well ... but ...

... there's a load of components that we are uncertain about. These will change leading to cost overruns through change control. The problem is ... we tried to specify what couldn't be specified because it's uncertain.

Now for vendors, contract 1 is gold dust because you can guarantee massive additional fees and get to tell the client it was all their fault because they didn't specify it correctly ... just don't mention to the client they could never have specified it ...

... what your client should have done is first map the problem, then add appropriate methods and then ...

... break the space into contracts based upon appropriate methods. The smaller the contracts, the better obviously. I know people grumble about managing interfaces but it isn't that hard.

In my experience, most massive projects fail not because "they're big" (though smaller is better) but because the contract structure is so flawed it would inevitably fail. It's why I can often sit down, map a project and point out where the contract fail before we've started.

X : So, people then change the contract structure?
Me : Not often. Mostly they continue with what they've already decided, mess up royally and then look a bit sheepish next time they see me. This stuff really is easy but you'd be amazed ...

... it's also not in the interest of many vendors / consultancies to stop their clients messing up royally. Those massive change control cost overruns are someones bonus payments.

Here ends another lesson on #Wardleymaps

X : There are more?
Me : Oh gosh ... how many months have you got? I thought, once a day for a week or two that I'd just extend this thread with some basics. It's an easy format.