It’s time for a rant on the weirdness of “roadmaps”.
“Time is money.” (And more time is more money.)
“Most of what’s built is seldom or never used.”
“Most requirements have negative actual value.”
We hear stuff like this a lot.
We nod in agreement and then get back to what we’re actually paid to do, which is to ignore such points.
Most of us are paid to execute upfront plans faster, to take the crystal gazer seriously, to speed up that train while ignoring that the tracks don’t move. Once that roadmap gets handed down, our job is to shovel that coal.
Sure, the Agile Manifesto stresses, “Responding to change over following a plan.”
Again, we nod in agreement…and then get back to our day jobs.
Many of us are in an odd position, one that should generate some cognitive dissonance. We are daily preached to about the critically of agility while getting paid to collectively pretend that Agile is something wholly other than what it is.
Real Agile was never about meeting your Waterfall numbers faster.
It is time we admit that Sutherland’s “twice the work in half the time” was Scrum jumping the shark.
As Klaus Leopold has long pointed out, organizations that attempt to “scale Scrum” to increase flow typically end up being let down. Leopold compares teams to clusters of keys on a keyboard. Getting each cluster to increase its respective velocity does not mean you can type faster.
That brings us to “flow”. We call it a “value stream” as though we’re in manufacturing—but we’re not. In software, the greatest source of waste is building the wrong thing, not building the right thing slowly, which is what we collectively pretend.
Taking a page from Tom Kerwin, if speed of building isn’t ultimately in service of pivot triggers, then we’re often just taking on debt faster. Think of it as irresponsible spending. As I’ve long argued, building faster than we can learn is waste.
The reality is, however, that if we’re paid to pretend the stuff flowing through our streams is “value”, that’s exactly what we’re going to do. And that is what most of us are paid to do. We’re not paid to achieve outcomes. We’re paid to meet delivery quotas that enable higher-ups to claim success.
But all too often what flows through the stream isn’t value-adding. (And what do you call a stream of waste?) Much of the literature on value streams assumes the “value” part is ensured by building what “customers” ask for. That’s quite a risky assumption. The reality is that discovery—something orgs tend to ignore—is just as important as flow.
A “plan”, as in a traditional roadmap, is like placing all our chips on one bet. When you think about it, a roadmap is a rather odd metaphor. It assumes there are already roads built and maintained and that the route is known, which, frankly, would be more like a cognitive walkthrough of an existing solution.
Notice that then when upfront plans are wrong, when it is sensible to doubt the efficacy of the crystal gazer, then it’s actually the ability to deviate from plan that saves the day.
Unless the crystal gazer is truly psychic, most of the time spent following a plan will ultimately be time spent off course. This is reminiscent of Twyman’s Law, which states that if most findings do not replicate, then any result that stands out as interesting is most likely wrong.
Applying this here, if most upfront requirements are wrong, then unless it is in service of learning, most of the time spent following plan is also time spent off course. Stated another way, learning our way forward is more important than executing a plan.
That, by the way, is Agile in a nutshell. We can in fact progress toward an outcome while being off course the majority of the journey, but only because of the pivots.
Therapist Leslie Cameron-Bandler once distinguished between “Make It Come True” thinking and “Questing”.
With “Make It Come True”, we know what we’re after and focus on the steps to getting it. This is the traditional planning approach. It’s like Picard’s “make it so”.
If we go on a quest, on the other hand, we more have an outcome in mind but don’t really know the path. This is more like Gandalf’s invitation to “share in an adventure”.
This can’t be approached with a linear strategy, or what Wylie, in Military Strategy, dubbed a “sequential” approach.
He contrasted this with what he called a “cumulative” approach, wherein multiple paths are simultaneously advanced to together nudge the needle on desired outcomes. As discussed here, in a layered strategy this shows up as branching.
We are essentially “stacking frames”, a concept I learned from UN facilitator Allan Parker. In this approach, as we journey from the present state to the desired state, we can specify the purpose, we can specify desired outcomes, but everything else must be explored.
Stated another way, to achieve a specific outcome in the complex domain, the output must be left free to vary. (It’s a quest after all, remember?) If we ignore this and lock down our output, it’s the result that will be unknown.
Yes, we still need planning to build big things, but this does not negate the criticality of pivot triggers.
“Sticking to plan” in light of later, better information is akin to refusing to switch doors in the famous Monty Hall Problem. In both cases that means in the long run we lose money.
To the extent our approach to planning requires we honor sunk cost, it will also rob us of the possibility of genuine Agile.
As stated here, the requirement that “success” be framed in terms of delivering something specified in the past, and not discovered on the journey, is likely the single greatest hurdle to creating more value.
It dooms us to forever spending decision degrees of freedom in states of greater uncertainty.
To close, the product world needs less Picard and a lot more Gandalf.
Charles Lambdin 
One thought on “Roadmaps and Twyman’s Law”