Agile is fundamentally about shortening the time it takes to deliver products to users and learning from that process. As I reflect on my journey as a professional Scrum trainer with Scrum.org and a Kanban trainer with Pro Kanban, I can’t help but notice how traditional management practices, which were born during the Industrial Revolution, no longer fit the modern landscape of work.
Understanding the Shift from Complicated to Complex
In the past, we operated in a world where a largely uneducated workforce was managed by a hierarchy of knowledgeable leaders. This model worked well for producing goods quickly, but it was designed for a different type of work—complicated work that could be simplified through standard operating procedures.
However, the reality we face today is that the work we do is complex. Complexity generates surprises, and no amount of standardisation can turn complex work into something simple. This shift means that the flow of information within organisations has become heavier and slower, making it increasingly difficult to respond to market changes.
The Need for Agile Practices
Traditional project management frameworks like PMI and Prince2 were developed for a complicated world. They rely on the assumption that we can predict outcomes based on established processes. But in our current environment, where change is constant and unpredictable, we need a different approach. Agile emerged as a response to this complexity, offering a way to adapt and thrive in a rapidly changing landscape.
The Importance of Predictability
When I categorise the elements of product development—requirements, technology, and people—it’s clear that predictability is a significant challenge:
Requirements: The Standish Group’s Chaos Report reveals that 35% of requirements change over the life of a product, and 65% of what we build is rarely used. This highlights the waste in our processes. Customers often don’t know what they need until they see it, making upfront requirements gathering a flawed approach.
Technology: While technology can be somewhat predictable, it is still subject to change. The tools and processes we use evolve, and we must be prepared to adapt our practices accordingly.
People: Perhaps the least predictable element, human behaviour varies daily. Factors such as personal circumstances and team dynamics can significantly impact performance.
Embracing Agile for Risk Mitigation
In the agile space, we tackle unpredictability by delivering working products on a regular cadence. This approach allows us to gather feedback and make informed decisions, reducing risk and waste. Instead of waiting until the end of a lengthy project to deliver value, we can provide usable increments throughout the development process.
Imagine a traditional project where you deliver a product only at the end of a 12-month cycle. Visibility is low during the project, and the risk to the customer remains high until the final delivery. In contrast, with agile practices, we maintain high visibility and the ability to adapt throughout the project. Each month, we deliver a working product, allowing for continuous feedback and adjustments.
Realising Value in Agile
Realised value is crucial. In a traditional organisation, value is often only recognised at the end of a project. However, in an agile environment, we can deliver value incrementally. Each working product we release provides the customer with something tangible to evaluate, ensuring that we are aligned with their needs.
This fluidity in requirements allows us to pivot based on customer feedback, minimising the risk of building features that are ultimately unnecessary. The goal is to create a product that truly meets the customer’s needs, rather than one that simply ticks boxes on a requirements list.
Conclusion: The Path Forward
As I continue to work with teams and organisations, I emphasise the importance of embracing agile practices. The capabilities to deliver working products regularly are within reach for all organisations, regardless of size or complexity. The only barriers are the existing expectations and systems in place.
If you’re interested in exploring how these concepts can be applied in your organisation, I invite you to connect with me for a free consultation. Additionally, I highly recommend reading “The New New Product Development Game” and Stephen Denning’s “At the Age of Agile” for further insights into agile practices.
Thank you for joining me on this journey of understanding agility in our complex world. Let’s work together to create a more responsive and effective approach to product development.
Agile is fundamentally about shortening the time it takes to deliver your products to users and to learn from it. Traditional management practices were developed during the Industrial Revolution to manage the work of largely uneducated workforce. While we can still be somewhat successful when using these traditional management practices, they no longer fit the type of work that we are doing in modern organizations.
My name is Martin Hincherwood. I’m a professional Scrum trainer with Scrum.org, a professional Kanban trainer with Pro Kanban, and I’ve been a Microsoft MVP in DevOps for the last 14 years.
I want to create an understanding of the two different worlds that we’re talking about here. So during the Industrial Revolution, with a largely uneducated workforce, we needed to make lots of goods really quickly. So we created a model in our organizations where we had the highly knowledgeable people at the top of the organization who were steering and giving direction to all of the rest of the people in the organization that were largely uneducated.
But the type of work that we were doing, the type of work we were physically doing was complicated. This complicated work had a particular characteristic. We could apply more knowledge to it and it became simple. This work became simple. So by applying more knowledge to this problem, we made it simple. We created standard operating procedures, built out common ways that things work, and optimised, identified the patterns and optimised for them. We pushed people into ability-based groups inside of our organization. So we ended up not only with the hierarchy of our organization but also the departmental model within our organization as well, where we had the CEO at the top giving direction. They had the absolute knowledge of the entire business and how everything functioned, and they gave direction to perhaps the sales team or the marketing team. They had a head who then farmed out that work to individual people down the totem.
Work was done, and that works great in a world where the CEO can give instructions, give instructions, and we follow them, and things are successful. But the problem is the market is at the bottom. In our new world, the market is changing a lot more frequently than the CEO is taking a test on what’s going on. So knowledge would have to flow back up this chain, and it’s too slow. If your organization is unable to respond to change as quickly as your competitors, you’re going to fail. Because the markets have changed, this complicated work no longer really exists. We can’t turn it into simple, so every single thing we do becomes custom, which means that that flow of information is becoming heavier and heavier and heavier up and down the chain in order to get things done, and it’s just not being successful.
That’s because we’re not operating in this complicated space anymore. Things have changed; things have become complex. No amount of standard operating procedures or processes or practices or ways of doing things can turn complicated work into simple. It never becomes simple. What complex work does do is it generates copious amounts of surprise. That’s those markets changing. So we need to be able to adapt to it much more quickly than we were doing before.
So that’s the different world. Traditional management and project management practices were developed to work in this space. You have things like PMI, Prince2. More recently, we have things like SAFe, the Scaled Agile Framework, and they are all developed to work in this space where the work is just merely complicated, and we can turn it simple by documenting a process. But in actual fact, most of the work we do today, most of the way our organizations need to operate today, is we operate in a complex world: complex markets, complex work, delivering all this complex creative things. Agile was a response to that difference.
Agile’s been around a very long time. The Agile Manifesto was signed in 2001, which is 22 years ago. Scrum was developed in this space and has been around for 25 years. 2019 was the first rendition of Scrum, but even before that, way back in the New New Product Development Game article, a Harvard Business Review article, I have a definition at the end, was 1986, I think. These ideas have been around for an incredibly long time.
If we exist in this complex space, we need processes and practices that were developed for this complex space, and we need something a little bit different. Because in our world of complexity, things are very unpredictable. There’s a great lack of predictability in those species. Here I’ve categorised the types of things that we would do in product development into three key areas: requirements, technology, and people.
It’s a very broad category, I do understand that. But let’s think about the predictability of each of those items and where it would sit. Well, we’re no longer taking orders. We’re not having orders coming from above in the organization, and we just follow it. The customer might say, “Yes, I want this,” but the reality is that the chances of this being what they actually need are very different. In fact, there’s some good data around that. The Standish Group in Boston created the Chaos Report, and they’ve added a few things. One of them is that 35 percent of our requirements change over the life of our product. Not only that, but 65 percent of the things that we build are used little, if ever.
Think about the waste. For every dollar of investment that we have, we’re losing 65 cents on the dollar just to building stuff that our customers don’t actually use. So why do we build things that our customers don’t actually use? Surely they asked for them, so they need them. But the reality is that they ask for things they don’t need, and the reason they ask for things they don’t need is because we ask them an unreasonable question. We say, “What are you going to need in a year’s time, in 12 months, when we’ve built your product for you? What do you need?” The reality is they don’t know. They don’t know what business decisions are going to happen over the next 12 months. They don’t know what market changes are going to happen over the next 12 months. They don’t know what other unpredictable world events are going to happen over the next 12 months.
So their knowledge of what might maybe happen includes a whole bunch of things that they won’t need once the decision has been made or if a particular event happens. We need these hundred features. If it doesn’t happen, we need these other hundred features. If we’re asking them up front, they’re going to give us the full 200 features, so there’s half of those things we don’t need.
So requirements, while we like to think that our requirements, once we’ve signed off on them, are fairly high predictability, the reality is they’re probably closer to that 30 percent predictable. So we need to figure out how do we adapt more quickly to be able to take that into account.
The next thing is technology. Technology could be our software technology; it could be a product technology; it could be processes, ways of doing things, technology. Probably Scrum sits in that space; Kanban sits in that space. These are technologies that were developed in order to help us do things. Traditional project management practices, PMI and Prince2, are technologies, ways of doing things. But the reality is that even during the life of a product, the technologies that we need are going to change.
Some of those technologies might be, would you run a product in exactly the same way when you’re building something new versus you’re supporting something that exists versus something happened in the market that you need to adapt around? Making a change to what’s going on? No, we’re going to use different processes and practices. Even in the software technology, Windows and Visual Studio are on daily builds. These products, the products that we rely on, that we use as part of our process, are constantly changing.
Now technology is probably a little bit more predictable than requirements. I’ll put this in the 50; it might be a little bit higher, but it’s still fairly low. And then our last predictability is people. I don’t know about you, but I don’t come into work every day and operate at exactly the same level. People are not machines. No matter how much we want to say that people should just come into work and be professional every day, that’s not how human beings operate. People take vacation; people take sick days; people have kids; people have arguments; people have disagreements. If I have to work with somebody I don’t like, I’m not going to perform as well as I would if I was working with somebody I did like. We’re going to collaborate more.
What is that impact on the world? I would suggest that people are probably the least predictable element here. If you average this across each of these different ideas, these different topics, we get a kind of picture of very low predictability, definitely less than 50 percent.
Now imagine that you’ve created our project plan for the next 12 months. We’ve created our bunch of mitigating actions. We’ve got a bunch of risks that might happen. We’ve got maybe 200 risks that might happen over the life of the product, and we have a whole bunch of mitigating actions that we’ve created. If this happens, we’ll do this. What if 60 percent of all of that is going to change over the life of the product and change constantly? What is that impact on the body of work that we’ve created and our look forward into the future? There’s a lot of waste in there. Things that we couldn’t protect, those surprises are going to happen, so we really want to tackle it in a different way.
In this agile space, we deal with this predictability, this lack of predictability. We deal with it by having working product on a regular cadence. So perhaps we have a regular cadence of once a month. We’re going to deliver working usable product. Instead of just having that single delivery at the end in our traditional model, we have continuous delivery of new working product that our customer can use, can work with in production, can give us feedback on that, will help inform the next piece of work. This gives us a whole bunch of capabilities, and I’m going to talk about that in a moment, but this is the superpower. This is the thing that allows us to mitigate risk.
It’s the only thing that allows us to mitigate risk in this complex world where everything’s changing so much. We can’t plan our way out of the risk like we would in a traditional model when the variance is very small. When the variance is high, we need to create these working usable products because then when something happens, let’s say a market change happens, we can maybe do another release very quickly after. We can do more releases than we have here. Perhaps there’s a world event that happens, and we need to do a bunch of small releases in order to get the competitors’ new features into market very quickly.
These are the tools that we use to mitigate risk. So let’s look at what that looks like. I’m going to go through this first quickly with a traditional mindset. In a traditional mindset, let’s say we take that pure traditional mindset where we don’t actually give the customer, we don’t deploy to production until the end. You’ve got a 12-month project, let’s say it’s going to cost 12 million of whatever monies you like, dollars, euros, or pounds, and we’re going to deliver on a monthly basis.
In a traditional model, we’re going to deliver at the end of the 12 months. So what’s the visibility during the life of the product? Well, visibility normally starts high, right? It’s going to start high because we’re writing the documentation, we’re communicating what’s going on. But then right at the end, we’ve got high visibility because we’ve delivered them working products. But in between, how much visibility does the customer actually have? What can they actually see? What can they use in the product? What do they really know apart from, you know, we tell them things are going great?
We’re 80 there and all of those things. So while visibility is not zero, it is fairly low throughout the life of the project and goes low fairly quickly. Couple that because visibility is not high, our ability to change also over the life of the project drops fairly quickly. So our ability to change at the end is very low. We’ve built a bunch of stuff, right? So we have a low ability to change. It’s more expensive to change things, but we drop very quickly after we start work in a traditional model because we start everything.
We’re not creating those vertical slices. This is why things like Spiral came into existence to help with those stories. But this idea is that change drops off very quickly. We maintain it for some time, but it drops off fairly quickly. Our customers’ operational risk always starts at 100 percent. What is the risk to the customer? What’s the customer’s risk? They’re looking at us going, “What’s my risk on whether these folks will deliver what I think they’re going to deliver?” So it starts very high, and then it’s obviously zero at the end because we deliver our working usable product at the end of every project.
That happens every project. But operational risk during the life of the project remains very high. It maybe drops a little bit as they see some of the things we’ve created. Maybe there’s a little dip there at the end as we go into UAT, but the reality is we get to the end, and their risk drops to zero only once we’ve delivered a working usable product for them, once we’ve solved their business problem.
If we look at realised value, how much value does the customer have? Well, it starts at zero. They’ve got no value, and at the end of the product cycle, at the end of the 12 months, they have full value. But during, how often do you actually deliver value to the customer? I very specifically use realised value. UAT does not count as realised value. UAT does not actually solve the customer’s problem. It’s still a pending problem, so we don’t have that value realised until the end of the product cycle.
Hopefully, you agree or mostly agree with the way I shape these lines. You may have little caveats, but I think it’s not going to be that much different from what I’ve drawn. Let’s take another look and look at agile. You might call it empirical; it doesn’t really matter what word you use. Agile’s been agile since 2001. Before that, it was just empiricism, an empirical process.
What we’re going to do is at least every month, at least every 30 days, we’re going to have working product, and it’s going to be in production. So where does visibility sit? Well, visibility sits fairly high throughout the life of the project. It starts high, and then every month we’re going to have, I’m probably not going to put 12 of these little stars in there, but every month they’re going to have that same level of visibility. Here are all the things we created over the last month. Please validate that it is what we’ve created.
During those sessions, you’re going to have these little dips where we’re not doing anything. I guess I could make that, I guess that could go all the way down here, right? Maybe that kind of makes sense, you know, bring it in line with the idea of not being able to see anything. But we have all of these touchpoints. We have 12 touchpoints throughout the life of the product where the customer is given the ability to change potentially.
Also, our ability to change over the life of the product is very different as well. We’re going to start with high ability to change. In both cases, we’ve built nothing, and in the end, we’re going to potentially have a low ability to change. In both cases, we’ve built a product, right? So now it’s difficult to change because a whole product exists—10, 12 months’ worth of work versus no work.
But the model is very different because at the end, because we’re working in usable working increments at the end of each month, when we ship the product, the customer has the option to change anything we’ve not started, and it has zero impact on our ability to deliver. It has zero impact on the product, and there’s potentially zero waste. It’s close to zero; it’s never zero, right? But we have much lower waste when they maintain that ability to change anything we’ve not started.
So what you end up with is you’re still going to drop because you’re building product, but it’s going to be on a different trajectory. We’re reducing our ability to change as we go through the product, but everything we’ve not built yet still has the ability to change. We even have the ability to change existing stuff just like we did in our traditional process.
But we’re adding that to the ability to change everything we’ve not started. If at the end of Sprint four, month four, the customer wants to delete our entire product backlog and build a new one, and that’s what we work on, that’s cool. We can do that because everything we have done so far is usable and works. It’s production-ready. That’s that superpower that we need in order to get there.
How does that look for operational risk? Well, we’re going to start in the same place and end in the same place. That’s that normal model. We’re going to start in the same place and end in the same place. But in fact, at the end of the first month, we’ve alleviated some of the risk. They have some working product. Hopefully, we’ve solved the most valuable problem we can in the first 30 days.
What could we do in 30 days? That’s what I do with teams. I get them in a room and I say, “Here’s what the customer wants. What is the most valuable thing we could do in this space in the next 30 days? Let’s build that.” At the end of the 30 days, you’ve got that. You give it to the customer and say, “Are we going in the right direction? Are we building something that’s valuable? Do you want to change your mind?” It gives them that visibility.
They can potentially, we can potentially ship it to production, and they can use it in production. There are all sorts of things we have to do to allow that to happen. But what you end up with is this direct trajectory from top left to bottom right. Every single time we create a usable working product, we alleviate the customer’s operational risk. We also alleviate their fiscal risk. Their money is no longer at risk because they have a working product.
You might have sprints where something bad happens, and we have a little plateau. That’s entirely possible. But mostly, you’re hopefully going to be delivering at the end of every sprint a usable working product that shows progress.
We have two things we need to talk about for realised value. We need to talk about if we are in a traditional organisation, so a hierarchical departmental model, top-down organisation, and we’re using agile practices in our team. What does that look like for the realisation of value? Realised value is value I have. So if you’re creating value for me, I don’t have something that you’ve documented. I don’t have something that you’ve built but not tested. I don’t have it yet. It’s not value yet. It’s potential value, right? That’s correct, but it’s not value for me yet as the customer.
Right at the beginning, we start at the bottom, we go to the top, and then we have every month we’re going to deliver usable working products. So every one of these notches is a delivery of value. It’s a delivery of something that we can use, that we can get in front of our customer, that we can have them kick the tires on, that they can tell us that we were wrong or we were right, and they’ll be able to use it.
That’s one option if we’re in that traditional organisation where we’re handed, “Here’s 300 requirements that you want us to build, and we’re going to build it.” In both of these models, maybe a little bit less in the agile model, we’re still under that constraint of, “So here we asked for, we were asked for 300 things, and we delivered 300 things in both models.” But remember we talked about the 65 percent that are used little, if ever. That’s included in those 300 things.
So what could we do differently? Well, what would be great is if at the end of the first month, the customer gets the product, and they tell us about all of the things that have changed. They get to look at the product and decide they want something different. They get to tell us about the way their business has changed in the last 30 days. Perhaps there are a bunch of features up here that they don’t need anymore. They made a business decision, and the world has changed, so they don’t need those.
Instead, they replace that with something else, and we build something else of value. That’s probably too steep. Let’s do something else of value. At the end of the next month, we build something else of value because they decide they don’t need this piece, and then we build something else of value.
Perhaps at this point, we’re almost at that same value level as we created over here. They decide we’re done. We were able to deliver early. We were able to finish the product. This is only possible if we’re able to change the requirements, if the requirements are fluid. In fact, you don’t want the full requirements up front, but we want those fluid requirements so we can make changes constantly.
Hopefully, we get somewhere up here where we have this much higher value product. If we continue to build it, it’s much more in keeping with what it is that the customer wants, and we’ve minimised that 65 percent of features not used. We’re still going to build stuff that’s not used, and we end up in that space.
All of these things are predisposed on having a working usable product at the end of every iteration, including the first. That is not out with the bounds of every single organisation on the planet. It is something that, for example, the Windows team do on a weekly basis. They create a working usable product on a weekly basis with four and a half thousand software engineers working on a product that is just enormous. If they can do it, we can all do it. The only excuses we have are the existing state of our system, the existing expectation of quality and capability in our teams and in our organisations.
We need to work on those, and we can all get these capabilities, and we can all be a little bit more agile.
Thanks for listening to my little rant. If you are interested in having a further chat with me, please use that QR code in the top right there to book a free 30 minutes with me. If you want our free consultation, that’s cool. If you want to just have a chat about some of the things I’ve talked about and how it might be applied in your organisation, others are waiting to book a coffee on there as well. Just book a coffee.
Two books that I really recommend that you read are one is The New New Product Development Game. That’s the 1986 Harvard Business Review article, and also Stephen Denning’s book, At the Age of Agile. Those are both great works. Thank you for listening.
