What an alien hive mind taught me about software delivery

I finished watching Pluribus on Apple TV recently and thought it was great. There’s a scene that’s been stuck in my head ever since. Carol needs a digger and within ten minutes, one is dropped into her garden by helicopter.

The thing that really struck me about this is that we have all the technology on earth, right now, to make this happen pretty much anywhere in the developed world.

We have the machines, we have the helicopters, pilots, comms, GPS.. but we just… don’t.

Not because we can’t but because we can’t agree.

Sadly for me, that made me think about how we build and deliver software. A lot of the processes we introduce in engineering teams isn’t actually about building software at all. It’s about managing the fact that a group of humans don’t naturally want, see, or understand the same thing at the same time.

Scrum. Kanban. Backlogs. Roadmaps. Tickets. Standups. Estimation. Retros. They ony exist to answer questions like:

• What are we actually trying to do?
• Who’s doing what?
• When will it be done?
• Are we still aligned?

If everyone already knew the answers to those questions, perfectly, all the time… you wouldn’t need any of it.

The best teams I’ve worked in didn’t feel like they were religiously “following a process”. There were no long debates about story points or whether something should be in this sprint or the next. No one was really talking about velocity, they just got stuff done.

But looking back, it wasn’t that there was no process. It’s that the process had become invisible.

Everyone understood the goal. Everyone had enough context and ownership to make decisions without asking permission. Feedback loops were tight enough that mistakes got corrected quickly. Trust was high enough that people didn’t second-guess each other.

So all the usual scaffolding like tickets, ceremonies, status updates etc could shrink or disappear.

That’s about as close as you get to the “no process” ideal.

Because the truth is that the ultimate software delivery process is no process at all.

If you had perfect alignment:

• No backlog grooming
• No sprint planning
• No estimation
• No standups
• No retros

Just a group of people building the right thing, immediately.

But of course, that’s not possible. Not at any meaningful scale, anyway.

Humans aren’t a hive mind. We have different goals, different incentives, different levels of context, different ways of thinking. So we invent process as a workaround: Standups to synchronise state. Tickets to record ideas and goals. Sprints to group decisions. Retros to patch where alignment broke down.

I think the goal should never be to implement Scrum “properly”. It’s not to have perfect Jira hygiene. It’s not to maximise velocity. In fact, the goal is to minimise the amount of process required to keep a team aligned. So the real work of engineering leadership isn’t choosing the right process. It’s increasing alignment so you can get away with less of it.

Clear goals. Shared context. Tight feedback loops. Trust.

Get those right, and the process starts to disappear, and you can deliver that digger.

Not because you’ve invented something new, but because you’ve removed everything that was getting in the way.