MarkStringer.github.io

Stop Making Sense - The System as Imagined vs The System as Found

So this week I’ve been writing a bid proposal. And I find it very difficult to write bid proposals. Part of the reason is that it’s just impossible to tell it how it really is. If you told how it really was, it would scare the horses. And as a result, I’ve been reaching for the Scaled Agile Framework as a way of talking about what will happen.

I was reading a book while I was on holiday - Captivate by Vanessa Van Edwards. The author claims at one point that one of the things that causes conflict between people is that have a particular way in which he like to be rewarded and that this can be different for different people. For example, some people like to be given gifts. Some people like to be given attention, some people like to be given praise. Of course, when you read things like this, you ask yourself how you like to be rewarded.

I thought about it for a while, and I realised that the way that I would most like to be rewarded was by having the people around me make sense. In a way this reminds you of that joke.

Man [to Wife]: What do you want for your birthday? Wife: A divorce! Man: I wasn’t thinking about spending that kind of money.

Wanting the people around you (especially in a work environment) to make sense is a ridiculous request. Not so much that it’s too expensive, but it’s just very unlikely.

But then, as I was writing this bid this week, it also occurred to me that senior management, the people who are looking at bids, also want the world to make sense - but it’s their sense. And their sense is different from my sense. So from my point of view, I want to acknowledge that software development, or more broadly digital product development is an inherently uncertain business. It’s difficult (i.e. actually impossible) to know what it will cost. It’s difficult (impossible) to know how long it will take and it’s difficult (impossible) to know whether the products that are developed will be successful or not. There’s also a lot of evidence from previous projects that the goals of the project will change as the project progresses. So the way that you engineer to manage such a system is lots of feedback loops.

But from the point of view of senior management, I think what’s going on is that they want to hear that everything is going to be straight-forward. Certainly that’s what they want to read about in a bid. They want things to make sense from their point of view.

We have the idea. We have no doubt that the idea is a great idea that is technologically possible and there will be no delays, problems or complications. The idea can be broken down into discrete tasks that can then be divided up between teams. The teams will work steadily through the work. There will be no issues with technology not performing as advertised, there will be hardly any need to communicate between teams except to confirm that they have done what they promised. The idea when implemented will be universally loved.

What it made me think is that I need to talk to some people who’ve actually made Agile work at scale. I need to interview a bunch of them and then maybe come up with a grounded theory approach to Agile at Scale.

And thinking about all of this reminded me of this video where Richard Cook draws a distinction between systems as imagined vs systems as found. Remember that phrase.

Systems as imagined vs systems as found.

Here’s a still from that video of Richard Cook’s of a system as imagined.

And here’s a still from a the same video of a system as found.