The Cost of What We Do Now

Series Intro: Software Delivery from First Principles

For years we have worked on delivering software. Legacy projects. Greenfield projects. Small, on-site teams. Large, remote teams. 2-week sprints. 4-week sprints. No sprints. No matter the specifics, software delivery was always complex and hard.

We can't change the hard part but we aim to make it simple. (See Rich Hickey's “Simple Made Easy”)
By rethinking software delivery from first principles.

The players of the delivery game

First, let's define the players of the game. These are the devs, the dev leads, and the project managers. Each player has their role, but as in any game, players interact with each other. What are the rules that dictate these interactions?

The rules of the game

There are clear rules the players need to follow. These are the written rules. Rules like sprints, daily standups, retros, progress update meetings, etc.

But it is the unwritten rules that add complexity:

• Where do responsibilities begin and end? How accountable should each role be for delivery?
• How do we resolve blockers? Often, a team is stuck, blocked by another team. What if these teams have conflicting priorities?
• Who has the authority to make a grey area decision? Think of a decision that is half-product half-technical.

And it's not only that the game is complicated. It does not even reward the good players.

An unfair game

Devs cannot easily connect their work's impact to the outcome of the project. And if they can't do it, neither will the ones deciding their bonuses.

PMs get a tap on the back for on-time delivery. Their critical (or not) impact cannot be measured in quantifiable ways.

What about the dev leads? They must be the ones rewarded, right? Yes, but it is exhausting. Because it is a game where it's easy to lose.

Everyone is playing in hard mode

Leads have to stand guard. Guarding their teams against scope changes, late designs, or other teams' delays. They might even need to keep a full history to prove it. From hands-on leads, they are turned into hands-off managers.

PMs do not have the authority to handle the coordination that is expected of them. They chase around people without much power over the outcome. And if the project fails, they will hear about it too.

So, instead of focusing on the actual game, the players are stuck playing mini-games - soul-draining games like the blame game or the power game.

• How will I protect myself? Can I shift the blame to someone else?
• Who do I need to network with to move the ball forward?

These seem like playing in hard mode but there's more. Imagine playing a game where you can't keep track of the score.

Progress status tracking is hard and vague. PMs only track what they can measure or what their tools allow them to measure. Having a real-time picture of all projects with their blockers, scope, and ad-hoc changes requires superhuman effort. It is almost impossible.

How can you adjust your tactic to win if you don't know you are losing?

The cost of what we do now

But then again maybe this is too dramatic. After all, most companies do get their job done. If that's how you feel, here are some questions to ponder.

Do you have true control over the running projects?

If you do, at what cost? What is the psychological burden on your people? Should delivery managers chase people around? Should your dev leads spend 50% of their time managing projects?

Can your process scale?

• Can it scale across multiple projects running in parallel?
• Can it scale across people? Or does it depend on a couple superhero leads and PMs to keep things together? What will happen if they leave or if you need to promote new people?