Process is not your saviour
Sometimes there is that person in a meeting - the one whose Miro board is a web of arrows and sticky notes like a detective’s evidence board - who announces that the reason everything is on fire is because we are not following The Process™.
If you have ever been part of a development team you are probably familiar with the moment.
Everyone else is staring at the floor, wondering if now a good time is to fake a coughing fit or a heart attack, and this person is pointing earnestly at a burndown chart like it’s the missing map to the Ark of the Covenant and they are Indiana Jones.
According to them, all we need to do is follow the steps.
Stand-ups, retros, peer reviews, planning poker, Fibonacci fibbing, sprint planning, Kanban cleansing, whatever the ritual is.
Just follow The Process™ and all shall be well; the fires will be extinguished and software delivered on time.
It is adorable, honestly.
The part no one wants to admit
Want to know a secret?
The process barely matters.
I know, it’s heresy. Put the pitchforks away - at least for a moment.
Of course, a good process helps. It brings order to the chaos and avoids the need for late-night emergency “HOTFIX” commits on a broken build.
But a process only works when the people using it actually want to work together.
When the team cares about the problem. When they want to solve it, not just move tickets around like they’re playing a Scrum-themed shell game.
There is no process in the world that can fix a team that fundamentally does not want to be a team.
This is the part missed in many methodology books.
You won’t find it highlighted in the Agile Manifesto or any of the glossy product-management presentations that look like they were designed by a TED Talk intern.
Software is less a project with an end date and more a relationship that never really ends, no matter how much you want it to.
Software is a relationship Between humans. Who are famously terrible at aligning on anything.
Developers vs the real problem
In my experience developers love a good technical puzzle.
Give them a weird concurrency issue or an API that returns something that looks like JSON but smells like pain, and they’re happy for days.
But people problems? Holy shit.
You’d think you’d asked them to refactor their childhood trauma.
The minute the challenge becomes interpersonal instead of technical - misaligned expectations, unclear decisions, passive-aggressive Slack messages, that one product owner who schedules meetings at 4:30pm on a Friday - developers disengage.
They retreat back into the safe warm glow of their editor windows, where the only arguments are the ones in their own code.
This is also why I believe support and production work turns so many developers into functioning adults. It forces them to confront… people. Real ones. With feelings. And caps-lock keys.
Row, row, row your boat
Imagine your team is a rowing crew.
Now, imagine half the team is rowing, a quarter is arguing about whether rowing is technically the right process for going forward, one person is refactoring the oar because “the old one was inefficient”, and another person is scared of conflict, so they’ve quietly slid off the boat and are swimming beside it hoping no one notices.
And the process consultant - clipboard, sun-visor, the whole aesthetic - is yelling from the riverbank:
“You’re not following the process; your stroke is not in the correct sequence!”
Mate, the stroke sequence is the least of our problems.
We’re sinking. Some of us are literally in the water.
A rowing process only works when the crew wants to row in the same direction.
Software is no different.
Humans first, technique second, oars third, and maybe a boat if we’re lucky.
It’s never about the process
Yes, follow a process - it might help you sleep at night.
But don’t build a shrine to it.
Don’t pretend it’s going to rescue you from miscommunication, apathy, or that one teammate who reads Jira tickets with all the focus of a cat glancing at a vacuum cleaner: vaguely aware something is happening, but absolutely not engaging.
Software is hard because people are hard.
The tech is always the easy bit. Tech problems sit still and wait to be solved.
People problems multiply like well-fed gremlins after midnight. They’re renewable, persistent, and forever eager to ruin your day.
The teams that manage to get it right - or at least less wrong - are the ones who actually give a shit.
They want to build something together.
They treat collaboration as a team sport instead of an optional side quest.
They tolerate each other’s habits long enough to get the thing out the door.
Almost any process works to deliver software when the people care.
Not a single one works when they don’t.
If that sounds grumpy? Good.
If it sounds dismissive of The Process™? Also good.
Because if you are building software and trusting The Process™, you’re almost certainly doing it wrong - exactly on schedule.