Agile as a Corollary to Twyman’s Law

Only presumptuous fools plan. The wise man steers.

— Terry Pratchett

“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 paid to do, which is not to deal with such points in an efficacious manner. Most of us are paid to execute upfront plans faster, to speed up a train on set tracks. Once that roadmap gets handed down, our job is to shovel that coal. As I recently saw someone joke online:

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 cognitive dissonance. We’re being put through “Agile transformations” while getting paid to collectively hallucinate Agile is something other than what it is.

As I’ve been stressing, Agile never was about meeting your Waterfall numbers faster. Sutherland’s “twice the work in half the time” was Scrum jumping the shark. Klaus Leopold, author of Rethinking Agile, has pointed out that organizations attempting to “scale Scrum” to increase flow often end up let down. Better to start with cross-team Kanbans instead. He compares teams to clusters of keys on a keyboard. Getting each team to increase its velocity does not get the letters written any faster. That brings us to this whole issue of “increasing 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, period, not building the right thing slowly, not building the wrong thing slowly, just flat-out building non-value-adding crap. Why then is it just assumed the stuff flowing through the stream is in fact “value?” Often it’s not. And if a lot of it isn’t, then increasing its flow is silly — it just piles up unjustified complexity and debt and cost. Much of the literature on value streams assumes the “value” part is ensured by building what people 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 your chips on one bet. If most upfront plans are wrong, then it’s your ability to deviate from plan that saves the day. In other words, most of the time spent following a plan is time spent off course. This is reminiscent of Twyman’s Law. If most findings do not replicate, then any result you find interesting is most likely wrong. There is a corollary in the product world: If most upfront requirements are non-value adding, then learning your way forward is more important than executing a plan. That, by the way, is Agile in a nutshell.

Therapist Leslie Cameron-Bandler once distinguished between “Make It Come True” thinking vs. “Questing.” With Make It Come True, you know what you’re after and you focus on the steps to getting it. This is the traditional planning approach. It’s like Picard’s, “Make it so.” With Questing, you more have an outcome in mind but don’t know the path to it. This can’t be approached with a linear strategy.

This is more like Gandalf’s invitation to “share in an adventure.” In this way, product work can be compared to taking a hill. Leaders set the constraints. They tell you what outcome to achieve. They tell you what hill to take. To storm a hill, you want to create tactical advantages. You can want different approaches. You want multiple lines of “attack” you can pursue in parallel and/or quickly pivot between. This fits nicely with what Teresa Torres calls an “opportunity tree,” which is very similar to an approach John Cutler has been suggesting.

Notice how this approach even looks like “storming a hill.” At the top is impact, the business value you’re trying to create. Business value is created by getting people to engage in certain behaviors (outcomes), which can be treated as North Star Metrics. Opportunities are akin to discovering the best problems to solve (though not all outcomes are achieved by solving “problems,” hence “opportunities”). Interventions are like proposed ways to create each opportunity (or “solve the problem”). In other words, you’re exploring possible ways to intervene in the environment. Below each intervention could be stories, ideally in a user story map or Kanban board (and not a flat backlog).

This works well with Klaus Leopold’s notion of “Flight Levels,” which is how he proposes you solve the scaling issue. Flight Level 1 is a low-level flight path. These are the teams that type the letters. Flight Level 2 is a higher flight path, focusing on team coordination. This would be your portfolios of letters to type (here “interventions”). Flight Level 3 is strategy: What outcomes are you going to achieve and what opportunities are you going to go after to achieve them? At FL3, you’re flying higher and your focus is on which hills to take. If, as I’ve argued elsewhere, Design is predominately about making decisions in service of achieving outcomes, then Design should predominately be playing at FL3. (Yes, FL2 and FL1 entail Design decisions, but of lower impact.)

Cutler also nicely shows how the approach above translates to a scaled Kanban (a “hybrid board”), with UX and Ops working primarily at the level of interventions and opportunities. It’s well worth reading.

Until next time. To close, the product world needs less Picard and a lot more Gandalf.