In the world of Agile, there’s a common misconception that agility equals speed. However, this idea is as much of an oxymoron as the concept of an “agile project manager.” The truth is, Agile isn’t about rushing through tasks or speeding up processes; it’s about spending your time wisely on valuable endeavors. Let’s dive deeper into what agility truly means and why it’s not about doing things faster, but doing the right things.
Agility is About Spending Time Wisely
One of the most important aspects of agility is the efficient use of time. The goal isn’t to do everything faster, but to ensure that the time you spend is on the right tasks—the ones that bring the most value. Here’s how:
Focus on Value: Agility is about focusing on the most valuable endeavors. We want to spend less time on the wrong things and more time on the right things.
Trial and Error: To find the right thing, you often need to try multiple things—sometimes even 10—before you find the three that work. This is a crucial part of Agile that separates it from the notion of speed.
Iterative Process: You might need to test and refine multiple ideas, which can take time. For instance, if each experiment takes two weeks, and you test 10 ideas, that’s 20 weeks of work just to find the one approach that truly delivers value.
So, the notion that agility equals speed is a complete fallacy. Agile allows for experimentation, learning, and adaptation, which might seem slower but ensures you’re building the right thing.
The Danger of Building the Wrong Product
One of the biggest risks in any project is building the wrong product—something that doesn’t fit the market or meet customer needs. Here’s why this happens and how Agile helps mitigate this risk:
Assumptions Can Lead to Failure: Many organizations fail because they assume they know what the customer wants. They think they’re building the right product, but in reality, they’re not.
Market Fit: Even if you build a product quickly, it doesn’t guarantee market fit. You need to constantly validate your assumptions and be prepared to pivot if necessary.
Example: Zoom.ai and the Shift to CalendarHero
Let’s take a real-world example. I was an avid user of a product called Zoom.ai, which started as a bot-based calendaring tool. It allowed users to interact with a bot to schedule meetings, but most customers, including myself, found it easier to simply send a link for people to book a slot. Over time, Zoom.ai pivoted and rebranded as CalendarHero, focusing more on traditional calendaring functions rather than their initial AI-driven approach.
This shift highlights the importance of market fit. Despite having an innovative product, Zoom.ai had to adapt to the actual needs of its users, which ultimately led them to completely change their business focus.
How Bureaucracy and Rigid Processes Hinder Agility
Bureaucracy and rigid processes can be significant obstacles to agility and innovation. Here’s why:
Slower Response to Market Changes: Organizations with a lot of bureaucracy often struggle to respond quickly to market changes. They become like rusty machines, slow and inefficient.
Local Optimizations: Focusing on optimizing small parts of the organization can lead to a loss of agility. Instead of improving the whole system, companies get stuck in local optimizations that don’t contribute to overall agility.
The Myth of Speed in Agile
Agility isn’t about speed. If you think adopting Agile will make your organization move faster, you’re mistaken. Here’s the reality:
Workload Remains the Same: Whether you use Agile or Waterfall, the number of tasks remains the same. If you have 300 things to do, it will take 300 tasks worth of time to complete them, regardless of the methodology.
Efficiency Through Elimination: Agile may seem faster because it often reveals that you don’t need to do all 300 tasks. Perhaps only 100 tasks are necessary, and you can focus on those.
Case Study: The Sentinel Project
A famous example of Agile in action is the Sentinel project, the FBI’s records-keeping system. Here’s a breakdown:
Initial Failure: In 1995, the FBI delivered a new system that was obsolete the moment it shipped. They spent $400 million and four years on a product that didn’t work.
Another Attempt: They then spent another five years and $300 million, only to have another failed product.
Agile Transformation: In 2012, the FBI decided to switch to Agile. They reduced the team from 400 to 40 people, set up Scrum teams, and delivered a working product to production within a year.
Was Agile faster? Not really. What changed was the focus—they stopped trying to build the entire system at once and instead focused on delivering the first piece, the part that would provide immediate value.
Reframing the Concept of Speed in Agile
The best way to understand Agile is not by how fast you can get things done, but by how you prioritize and deliver value within the same time frame. Here’s how:
Budgeting for Value: Imagine you have $100,000 for a project, allowing for 10 Sprints. Instead of deciding upfront what to build, Agile allows you to figure out as you go which features or tasks bring the most value.
Delivering the Right 50 Things: By the end of the project, you might not have built the 50 things you initially thought were important, but you will have built the 50 things that matter most to your customers.
Final Thoughts: Agile is About Delivering Value, Not Speed
Agile is often misunderstood as a methodology for doing things faster. In reality, Agile is about ensuring that the time you spend is on the most valuable tasks—the ones that will truly benefit your customers and your business. By focusing on market fit, eliminating unnecessary bureaucracy, and embracing an iterative process, Agile helps organizations deliver better products, not just faster products. So, the next time you hear someone equating agility with speed, remember: it’s not about rushing to the finish line; it’s about making sure that what you deliver is worth the journey. 🚀
There’s an idea out there: the agility equals speed. I think this is in the same category as agile project manager, right? It’s an oxymoron; it doesn’t exist. It’s not a thing. That’s not what agility is about. Agility is about spending your time well. That’s probably a bit… I think that’s a good way to describe it. Probably spending your time well. The time we do spend is on valuable endeavours. We spend less time doing the wrong thing and more time doing the right thing. That’s the idea that we’re trying to achieve. But in order to find the right thing, we’ve got to try ten things to find the three things that work, right?
So the idea that agility is about speed is a complete fallacy because we might have to do nine things before we find the one thing that works. So if each of those things took two weeks, that’s twenty weeks. And we did one thing. Well, why don’t we just decide what those ten things are up front, look at them, and go, “Let’s do that one. Let’s do number five and just do that one thing, and then we’re done. We’ve built a product.”
Well, is that the right product? Does it have market fit? Are people going to buy it? Is it even the right feature? Does it actually provide value to the customers? We don’t know any of those things. We could have just built the wrong thing. Lots of organisations fail because of assumptions. They fail because they think they’re building the thing that they want, but they’re not. They’re not building the thing that the customer wants.
My favourite example was… I use this one a lot. Sorry, that they’ve been bought, so now the product sucks. But I was an average user of a product called Zoom AI, right? So this was an awesome product, and what it allowed you to do was multiple things. It was basically a calendaring tool, right? One of those calendaring tools, but its unique focus was on a kind of bot-based calendaring tool. So you could have a bot. I use Teams, so I had a bot in Teams that I could just go message and say, “I want to meet with Simon at four on Friday. Go organise that.”
And it would email Simon and say, “Simon, Mar wants to meet at four Fridays. Does this work for you? Yes or no? Would you like to pick some times that you and Martin have available?” Okay, pick some times, and then it comes back. And that was that story. So it was a bot-based interactive. It was maybe a bit early, right? Probably the versions coming now with AI are going to make this a lot more effective, but it worked.
And almost all of the other customers found that they didn’t really use it that way. What they used it was as a calendaring tool: send people a link. “Here’s how… here’s my free time. Go book a slot,” because it was just easier, right? You didn’t even have to write a message to someone; you just sent them the link.
So while they were Zoom AI and this AI story, they actually very much ended up just changing the whole company ethos and focus from that to Calendar Hero. And they were just another calendaring tool, but a very good one. They’ve been bought by somebody else now, and everything has gone crap. But, you know, you’re really good; somebody comes and buys you, and then they absorb you and eat you, and now you’re no longer good.
But that idea of completely changing not only your business, your focus, your company name is around why is your market fit? And what a lot of big organisations fail to realise is that their market changes. It’s not that they fail to realise it; it’s that they don’t understand how to take advantage of it because they build up rust, right, in all of the bureaucracy that builds up around the organisation. We shouldn’t have a lot of bureaucracy. If you have a lot of bureaucracy in your organisation, you’re doing it wrong, right? That’s all. You’re not able to respond to market changes quickly enough if you have a lot of bureaucracy.
Local optimisations, right? So this comes back to that idea of agility is not equal to speed. The purpose of agility is not to go faster. If you think you’re going to do Agile to make you go faster, you’re wrong. It’s not going to work that way. If you have three hundred things to do, it’s going to take three hundred things’ worth of time to do, whether you do Agile, waterfall, whatever. You’ve got three hundred things to do.
The way Agile makes it seem like you’re going faster is maybe you don’t need three hundred things; maybe you only need one hundred things. That’s how it might seem like it’s faster because we do one hundred things, and we’re done, right? Think of the Sentinel project, right? That’s the big famous one. That was the US FBI records-keeping system. In 1995, a brand new system was delivered. It was green screen with terminals, right? We all had Windows 95 at that point, and they realised it was obsolete the moment they shipped it.
So they started working on the new version, Project Sentinel, right? And they had money from Congress—so $400 million. And I can’t remember the company; it might have been Lockheed Martin that was building it. And they spent four years, $400 million, and at the end of that, they didn’t have a working product. No working product. So they had to go to Congress, get more money—$300 million, five years spent, $300 million, another five years, no working product, right? Not very fast.
Got to, I don’t know, 2012. They’d been going for nearly ten years. This project had been going for nearly ten years, maybe 2005. Anyway, nearly ten years, and they decided to quit the whole thing. They took the best people out of the group that they had building it. They hired them. The FBI physically hired the people, set up scrum teams in the basement of the Hoover building. So they had about forty people, went from four hundred people to forty people, and they delivered to production within a year.
So you could say that they went faster, but they didn’t go faster. They just didn’t try and build the whole thing. They just built the first piece, right? They got to production within a year. That’s the speed that we’re talking about. We’re not actually talking about delivering what you thought you were going to get faster. You’re going to get a better product in the same amount of time.
So the best way to think about it is if we have a… let’s say it costs $10,000 per sprint. We’ve got $100,000; we can do ten sprints. We can do five things per sprint. Do we just do these fifty things we decide up front, or do we figure out as we go which fifty things are the best fifty things to build? We’ve still spent exactly the same amount of time, but we have a better fifty things that we’ve delivered. We’ve got fifty of the right things than just the fifty things we thought we needed at the start. And that’s why Agile is not about speed.
