Scale

So what's the picture that we've built up of sofware development projects?

Software projects are about delivering value to an organisation and value to its customers. But in most projects, initially, the precise nature of the value, and the precise nature of the connection isn't know.

In the development of projects that use software, the value stream doesn't exist, it has to be discovered and irrigated. This is an iterative and exploratory process.

The whole process is littered with paradoxes and contradictions.

The kind of ideas that get funded tend to talk about "all" and "exciter." Everything the old system did, but better. Like facebook, but for dogs. The kind of things that can be built to deliver value, tend to be partial and particular. They connect particular value, they discover value.

Successful projects won't necessarily deliver an idea, success software projects will deliver something along the vector of the idea, or discover an neighbouring vector which is more valuable.

What does that mean for scaling?

Do you know? I'm not entirely sure, not completely sure, but there are some things that I know.

Let's say that you're in charge of a programme of work.

If you're agreeing a programme of work across multiple teams, you need a feedback channel that can continually modify what's been agreed.

If you're agreeing a programme of work across multiple teams, you should be very interested in anything that comes out of those feedback channels that is talking about bricks without straw problems.

Very often, bricks without straw problems are infrastructural. And if you're working with a big programme, infrastructural problems should be the kind of problems that you concern yourself with.

Office space, office furniture, security clearance, internet connectivity: if you want to make your programme of work succeed you should be very intersted in these boring, embarrassing problems.

Similarly, if you're responsible for a programme of work, you should be interesting in a class of problems which I realised I haven't called out before: "Monty Python foot problems."

Monty Python foot problems are at the other end of a project from bricks without straw problems. Bricks without straw problems stop a project from properly getting started, Monty Python foot problems stop it from finishing.

Non-functional requirements, legal approval, PR approval. It's not a complete list because the Monty python foot that decends and stops a project from delivering is probably something that you don't know about. But once one team gets flatted by an unexpected non-functional requirement, or release of a first prototype gets delayed by a couple of months because approval is required from a person who hasn't yet been appointed.

Some other things. You need to be able to shut projects down. Some projects just aren't a good idea. The bricks without straw problems can't be overcome.

Another kind of problem that all projects suffer from: tree problems.

What's a tree problem? It's when the decision or approval of something that's required for a project is stuck outside of the project.

Another thing to bear in mind is that if you've collected together a group of projects, you've also collected together a group of local optimisation problems.

The instinct of the product owners on those projects will be to try to avoid each other, and steal each others resources.