There are a lot of frameworks coming up every day. I see new versions, so we've ended up with everything from Agile, Kanban, Scrum, Scrum@Scale, SAFe, Design Thinking—you name it. We've got new and new frameworks. There's also a lot of practices.
One picture I love is from a guy, Christopher Webb, at Deloitte. What he's done is taken all of the Agile practices and matched them to what I found out at the time when I was speaking at a keynote in Japan—the Tokyo subway map. Apparently, where we were talking was down around test-driven development. Now, if you look at that for a moment, the first thing that sprung to my mind is, what happened along the way? Agile was meant to be simple, but like anything, it evolves and grows. That's not a bad thing; it just means that we end up with more complicated ways of working.
There's also a lot of pressure, and over time, I feel like that hasn't really changed. We've gone from measuring things like function points, lines of code, and milestones being hit. Then, when we moved to Agile, new terms emerged—story points instead of function points, velocity, features delivered. This has put a lot of pressure on us.
Whenever I have people wanting to know about velocity and how many features we're getting out, I ask them if they'll invest in my fantastic startup idea. My idea is that, you know how printers sell for not too much money, but the companies make money off peripherals like printer toner and paper? Well, my idea is to start with a very simple remote control, but people pay for extra buttons. And to date, I haven't had any takers on my fantastic idea. The reason? I don't know anyone who wants more buttons on their television remote control. In fact, it's the complete opposite.
The next picture I found is of a guy who went to his grandmother’s place. He noticed that she kept getting up to change the channel on the television and adjust the volume. After a while, he asked her why she didn’t use the remote control that was directly in front of her. She said it was simply too difficult to use. So her son, obviously a user experience guru, fixed the problem. To me, what this guy has done is remove the inessential so the essential could speak. He figured out what the most important things were that we need to get to, and then either hid or removed all the unnecessary features.
I feel like most of my work over the years, from the early days of Agile, has been about this. Leadership often brings in Agile because they want more features faster—the idea that more is good. But as we can see, it actually causes a lot of problems.
You've heard a few people mention this term this morning already: "build the right thing." Design Thinking and the idea of understanding the customer experience is heavy on what people really need. Agile, on the other hand, is focused on building the thing right. The left-loop thinkers do deep discovery. They’re very good at figuring out what’s going on, but there’s a tendency to sometimes get stuck in analysis. They try to get the research so right that it takes too long to get anything done.
With the right-loop thinkers, the agilists, there's a tendency to deliver features rapidly. But if you don’t know what you’re building, you could just be building the wrong thing faster. It’s like driving to your destination—if you set the wrong place in your GPS, it doesn’t matter how fast you’re going. You might fail faster, which is better than failing slowly, but you’re still failing. So what we need is this idea of balance.
Mobius is a navigator. I don’t use the word "framework" much because I think we have a lot of those. What we need is a way to navigate from building the right thing to building the thing right.
Early on, I worked with one of the first companies in San Francisco that scaled up and went public. That company was incredibly outcome-driven. This was back in 2003. Then I went to Yahoo, where we scaled up to 250 Agile teams globally. It was a big success, but I was always very worried that we were so focused on doing Agile and getting Agile right that we were missing the right thing to build—the outcomes.
Later, I worked a lot in the contract space, specifically legal contracts. Out of that work, I co-authored a book with Susan Atkinson. We initially wrote a very big book, almost like a waterfall book project. The epiphany was realizing that it wasn’t about Agile contracts. It was about solving problems and coming up with the right outcomes.
Nowadays, people talk a lot about outcomes, OKRs, and objectives and key results. It’s one of the most popular new kids on the block. But what I’m finding is that it’s still not being done well because people haven’t done the deep discovery to truly understand the problems at the start.
What that means is we need a way to help people achieve outcomes. What I’m going to show you is what we call "training wheels." When you get deeper into Mobius, you’ll notice that you can start anywhere in the loop and move around at will. However, when we start, people need enough structure—what we call "structure yet freedom." This adaptive structure always asks the key question: "Why are we doing this?" We have to capture the problem.
Often, I hear people say things like, "We’re going to build a new CRM." That’s great, but why? "Well, we need one." But what are the problems? If we don’t understand those problems, we might automate something but just automate the problems along with it.
We go through discovery—gathering data, understanding our customers, and seeing them firsthand. I’m a big proponent of guerrilla research—getting Agile teams out into the world to see firsthand what’s going on. Then we create our target outcomes. Even the word "target" is an interesting one. We want to set a direction, but what we’re really trying to do is set a direction of improvement. It’s not a hard stop; it’s something that will continuously evolve.
We generate ideas, use techniques like "How Might We" and hypothesis testing, and then go through a decision-making process. We prioritize based on impact versus cost and complexity. We refine our ideas and want to launch them rapidly, balancing research and execution.
This approach is being used widely—from tech companies like Google Cloud and Red Hat Innovation Labs to social enterprises using Mobius in impoverished areas like Pakistan and even war zones like Yemen. It’s a way to easily customize our own innovation process.
Finally, I want to end with a story. Aleister Parvin, an architect, was hired to redesign an old Victorian school in the UK. The school had a major problem: when the bell rang, students flooded the hallways, causing congestion, delays, and even fights. The initial estimate to solve this was £20 million—to extend the corridors and redesign the layout.
Instead, Aleister and his team observed the situation and tried a simple experiment. They bought individual bells and placed them in each classroom. Instead of one big bell ringing at the same time, teachers rang their classroom bells when they finished their lessons. The result? Students exited at different times, completely eliminating the congestion and bullying problem—for less than £500 instead of £20 million.
That’s the benefit of focusing on outcomes. It’s not about getting caught up in processes but creating a common language around outcomes and giving people the autonomy to experiment and adapt. Structure, yet freedom—that’s the key.