What Are You Selling?
Agile Means “Flexible”
Breakfast is the most important meal of the day, says people who sell breakfast foods. The most effective way to lose weight is to eat diet foods, says people who sell diet foods. You need to impose some big framework to “scale” Agile…you get it. There are plenty of people who make their bread and butter selling what other companies have done, but is that Agile?
Consider orgs trying to copy the “Spotify model.” Here’s an example of a company that’s actually being Agile. Others watch a presentation they did, and instead of considering they should also be Agile they conclude, “Why don’t we do what Spotify did in this video?” The big picture has been missed.
We don’t need a new template with old thinking. We need new thinking. There is no “Spotify model,” and there never was. Spotify is just experimenting, discovering what works in their context, and adaptively and flexibly evolving and continuously improving. What they showed in their presentation (which was just part of a stack), they quickly evolved out of. It was a postcard from someone else’s past.
Apparently, this cannot be said enough: Agile does not mean “speed.” Merriam Webster defines agility as “nimbleness.” Even in sports, being “agile” has more to do with being light-footed. (And how to do you scale light-footedness? Focus there and continuously improve.)
Consider the gazelle. Gazelles are not as fast as cheetahs, but cheetahs can rarely catch them. Gazelles are better at pivoting. Agile is about responding to change over and above following a plan. Instead of treating requirements as some static thing, as Waterfall does, Agile stresses the criticality of pivots informed by fresh learnings.
Teams can only pivot if they have the degrees of freedom to do so. If they don’t, they can’t be Agile, period. As Agile expert Allen Holub notes, orgs love pushing stories to teams, telling their teams what to build, while at the same time complaining their teams suffer from “learned helplessness.” Do they not see the irony? The “helplessness” is imposed by the org. It’s a lack of degrees of freedom, an inability to meaningfully pivot, to be Agile, to self-organize. It’s the result of decision authority hoarding. If all the decisions have been made above you, then Agile is a moot point.
Velocity != Value Velocity
Now let’s talk about value. If you aren’t making discoveries as you go and revisiting the work that’s been done, you aren’t maximizing value. You’re maximizing output, which isn’t the same thing. As John Cutler has pointed out, if you aren’t monitoring value itself, focusing on discovery work, improving what’s already been built, and managing the complexity you’re continuously pumping into the environment, your ongoing work will decrease in both value and sustainability (image adapted from John Cutler).
As Cutler spotlights in this phenomenal video (watch it!), output velocity != value velocity. That’s the feature factory trap, what Melissa Perri calls “the build trap.” Value is not maximized by maximizing output. It just isn’t. If your sole focus is finishing a feature by some deadline so you can start the next one “on time,” you’re not being Agile, period.
If you’re building the wrong thing, how you prioritize the next five items is not going to magically create a great product. That’s output thinking. As Pavel Samsonov notes, however, this will never be realized in an output-based culture. As he points out, if you get rewarded for adding buttons but never for removing them, then things will only ever increase in bloat.
Value is maximized by getting better at discovering what will generate bidirectional value. This comes down to design decisions, research, and learning loops. Since your learnings are only as fresh as your learning loops are small, increasing velocity often does not make for quicker value-adding learning.
In the image below, Team A and Team B are working at the exact same speed. Team A’s batch size, however, is 2.5x larger than Team B’s. Because of this, in the same time span, Team A can only sense and respond four times compared to Team B’s 10. Their “building speed” is the same. Team B’s “learning speed” may be more than twice Team A’s.
Learning velocity has more to do with the velocity of informed decisions. Unless you’re managing a factory, anyone who still thinks of “waste” in terms of idle employees is living in the past. In most organizations, a “normal” flow efficiency is around five to 15%. If we take the middle value, what that means is that, from light bulb to go live, 90% of an item’s lead time is wait waste, time spent just sitting around. And how much of that lead time has anything to do with your Agile teams? Very little.
Your main constraint is not your Agile teams — it’s typically how decisions are made at the top of the org. If you want to improve value velocity, you need to distribute decision authority, speed discovery, and preserve degrees of freedom to enable decision making as close to the source of value as possible. The image below, by the way, shows exact proportions for a “normal” flow efficiency of 10%.
Even light bulb to go live, however, is obsolete thinking. That’s what I call the “fast food model of product work,” where IT is treated as interchangeable line cooks frying food for the business waiting mad at the drive thru window. Your teams are not “delivery” teams (unless you’re in the pizza business).
Value Velocity = Faster Validated Decisions
The real lead time is light bulb to value created, and the only real predictor you have any control over is whether users will proactively use what you provide in a way that creates value for the business. This means, however, that you actually need to focus on discovering user problems.
Create value for your users and they will create value for the business — bidirectional value-centered design. The more frequently you can make decisions derisked by validated learnings, the more value you will create. You don’t know what will create value; you’re placing bets on what will generate value in the future. As Cutler argues, lots of small bets adjusted as the race is run makes far more economic sense than larger bets planned out beforehand.
The currency of design is decisions made. Whoever makes decisions to intentionally solve problems and achieve outcomes is a designer. A developer is a designer who happens to write code. An org leader is a designer who happens to make big strategic design decisions.
Does that mean these decisions should ignore design technique, should not be derisked, should not be informed by guerilla research, small learning loops, and validated learnings? Far from it. Any leader who doesn’t realize she is a designer and that all decisions made in complex environments will have unintended consequences, only increases her own risk.
If you are on an Agile journey, please realize, Agile and design, properly understood, are not separate things. Increasing the velocity of value means increasing the velocity of informed design decisions. This requires focusing on how decisions are currently made, how decision authority is distributed, the extent to which teams are trusted, the extent to which POs are real POs and not POINOs (PO in name only).
If you are on an Agile journey, remember, transformation is the new norm. There is no “done” with continuous improvement…unless you want to fall off the map. So keep at it. If you’re doing Scrum, or SAFe, or LeSS, or whatever, remember the goal is to keep improving. It’s not to leave your training wheels on. Doing that is DANGEROUs, not SAFe (image adapted from Cutler’s video).