Roadmaps were invented by Boeing as a way of keeping track of the countless moving parts in getting airplanes built in time and on budget. Software projects are often trickier to plan and track, since the end-state is less clearly defined.
It seems to me that any given software project take on a bell curve of complexity. Starting out with a clean slate, there will always be a grace period where one individual programmer controls the whole code base, usually sticking to a certain framework or a school of thought.
Then inevitably complexity starts creeping in. More people are added to the team, new technologies are tried out, the need for documentation quickly grows. This is the price of success, you wouldn’t get entropy without active users. So it’s a good thing really, but it also becomes challenging both from engineering and a management point of view. Because when you’re in the thick of it, right at the top of the complexity bell curve, is usually when you *really* need to take control of the product roadmap.
This is the ‘scale-up phase’ and if you made it this far it’s likely that you’ve attracted attention from the investment community. That can be flattering, but money comes with a price tag. There’s now an expectation that you’ll be able to accelerate while at the same time also getting a better grip of the product roadmap.
So the rules of the game are changing. You can no longer focus exclusively on developing a product that people will love, but have to spend a large part of your efforts at fighting complexity, so that you’ll come out at the other side of the bell curve with an architecture that allows enough freedom of movement to actually, again, be able to execute on credible roadmaps.
So where do you turn to if you can’t make sense of your product architecture and its’ hard to see beyond the next OKR-period (or even the next sprint)?
Well, there’s a book for that.
As always in design methodology gurus fight for attention and one who got his fair share is Donald G. Reinertsen, author of Managing the design factory as well as The principles of product design flow (I stumbled upon him by reading his foreword to Dean Liffingwell’s book Agile Software Requirements, which is also worth mentioning in this context).
Reinertsen is an anti-roadmap evangelists. With his background in the US marines, he’s making the case that software teams should free up enough capacity to be able to act on “the commanders’s intent”. This is a concept coming out of the leadership doctrine called mission command. Interestingly, itself a sort of reaction to the failure of the military equivalence of roadmaps – which makes sense if you’re invading France, but are inefficient for directing small task forces operating behind enemy lines. In those cases, you want the people on the ground to make the strategic decisions.
Transferring from life in the actual trenches to leading software teams, Reinertsen started thinking that the whole problem boiled down to one word: queues.
Queues are the Viet Cong of software engineering; the asymmetrical threat you can’t predict, except that it’ll always find a way to bite you.
If the concept seems vague, try using the word backlog instead, the bane of any product manager’s existence. Why exactly is it so?
Because its length and breadth are leading indicators of complexity. The surest way to know you’re in the messy middle of the bell curve is that your backlog has spun our of control. Product managers will remain oblivious of this for a while, but product owners see it first hand.
No matter how clearly they try to communicate their “commander’s intent” to the team at sprint planning meetings, they manage to get fewer and fewer user stories through the door. Instead the team commits to “tech stories”, ranging from orchestrating the new server cluster and automating deployment pipelines, to setting up an environment for new developers joining the team, documenting the new api-resources or cleaning up dependencies… Anyone who’s been there will know that sinking feeling.
This is why Reinertsen is yelling from the top of his lungs that:
“The dominant paradigm for managing product development is wrong. Not just a little wrong but wrong to its very core.”
He claims we got us into the fix by pursuing the wrong goals. We try to maximise efficiency and minimise variability, and then we wonder why innovation slowly dissipates while cycle-times bloat.
Reinertsen argues that the only way to solve the problem of growing backlogs, is to let development teams get to finish each job on their own terms. If done consistently, this will lead to freeing up enough capacity for the team to figure out how to work the kind of magic that will fulfil the commander’s intent.
It seems to me that Reinertsen is quite inspired by Eliyahu M. Goldratt’s management classic The Goal : A Process Of Ongoing Improvement.
That book has nothing to do with software. In fact it’s not even really a business book in the classic sense, but a novel (also converted to the silver screen) about Alex Rogo, the manager of an ailing factory where despite shiny new robots, stellar workers and solid demand for the products, everything seems to go wrong.
Rogo happens to run into his old physics teacher Jonah, who has just started his second career as management consultant, an occupation that didn’t exist / have a name at the time (The Goal was published in 1986).
With the help of Jonah’s thinking around queue-theory, Rogo eventually manages to turn the company around. As if by magic productivity seems to go up as people get less busy. Rogo himself frees up enough spare time to start working on saving his marriage, which has been suffering as a side effect of him being eaten alive by work.
The key to making Alex Rogo act on Jonah’s theories, is when he volunteers to lead his son on a scouting expedition in the mountains and sees first hand how the group is only as fast as the slowest kid in the line and that it’s worth it for the rest of the group to make any investment to help speeding him up. It’s a good read this book, and one the earliest to start exploring the concept of Lean.