In the world of Agile, the statistics speak volumes. According to the Standish Group’s Chaos Report, small projects with fewer than 50 participants are 30% more likely to succeed when employing Agile practices. Even more striking, larger projects with over 50 people see a staggering 200% increase in their chances of success. This data underscores the transformative power of Agile methodologies, and today, I want to delve into the key differences that make this possible.
As a Professional Scrum Trainer with Scrum.org and a Professional Kanban Trainer with Pro Kanban, I’ve spent over 14 years as a Microsoft MVP in DevOps. My journey has taught me that understanding the nuances between traditional and empirical models is crucial for maximising project success. Let’s explore this through the lenses of visibility, change, operational risk, and realised value.
Visibility: The Light and Dark of Project Cycles
In a traditional model, visibility is high at the beginning and end of a product lifecycle. We start with extensive documentation and customer engagement, ensuring everyone is aligned on what’s to come. However, as we progress, we often go dark. Touchpoints may dwindle, and stakeholders are left in the dark about the project’s status until the final delivery. This can lead to misalignment and unmet expectations.
Conversely, in an empirical model, we maintain high visibility throughout. While we may experience low visibility during the development phases, we provide stakeholders with a usable working product at the end of every iteration. This regular cadence of delivery allows for ongoing feedback and adjustments, ensuring that the project remains aligned with customer needs.
Change: Embracing Flexibility
The ability to change is another critical factor. In traditional models, we start with a high capacity for change, but as we build, that capacity diminishes. Each new feature or piece of documentation adds complexity, making changes increasingly difficult. By the end of the project, our ability to adapt is severely limited.
In contrast, the empirical model allows for greater flexibility throughout the lifecycle. While our capacity to change does decrease as we build, it remains significantly higher than in traditional approaches. By delivering in vertical slices, we can pivot based on customer feedback without incurring massive costs or delays.
Operational Risk: A Gradual Alleviation
Operational risk is another area where the two models diverge. In a traditional approach, we start with high operational risk, which only drops to zero at the end of the project when we deliver the final product. This means that for much of the project, the customer is left with no alleviation of risk.
In an empirical model, we begin with high operational risk, but with each sprint, we deliver usable products that gradually reduce that risk. This continuous delivery not only alleviates risk but also builds trust with stakeholders, as they see tangible progress throughout the project.
Realised Value: Delivering Incrementally
Finally, let’s discuss realised value. In a traditional model, value is delivered only at the end of the project, often resulting in a situation where the customer finds that only a fraction of the features they requested are actually used. This can lead to disappointment and wasted resources.
With an empirical approach, we can deliver value incrementally. By providing usable products at the end of each sprint, we allow customers to start realising value much sooner. This not only enhances satisfaction but also enables us to pivot based on what the customer truly needs, rather than what they initially requested.
Conclusion: The Superpowers of Agile
The superpowers of Agile methodologies are evident, even within traditional organisations. By maximising visibility, embracing change, minimising operational risk, and delivering value incrementally, we can transform the way we approach projects.
If you’re interested in diving deeper into the principles of Agile, I highly recommend reading “The New New Product Development Game,” a classic article from the Harvard Business Review, and Stephen Denning’s “The Age of Agile.”
For those looking to enhance their Agile journey, I invite you to connect with me for a free 30-minute consultation. Together, we can explore how to make your projects more successful and aligned with the needs of your customers. Thank you for joining me on this exploration of Agile practices!
According to the chaos report from the Standish group small projects of under 50 participants are 30 percent more likely to be successful with agile practices and large projects of more than 50 people are over 200 percent more likely to be successful.
Hopefully this short video will help you identify the key differences that make this possible.
My name’s Martin Henshawott I’m a professional scrum trainer with scrum.org professional kanban trainer with Pro kanban and I’ve been a Microsoft MVP in devops for 14 years.
So we have the traditional model the empirical model and we’re going to look at that within the context of visibility right how much visibility do our stakeholders have we’re going to talk about change operational risk and realized value.
So let’s focus on visibility at the beginning of a product life cycle in a traditional model we’re going to have high visibility we’re creating that documentation we’re showing the customer liaising with the customer and what it is we’re going to create.
And then at the end of the product cycle we also have high visibility right the customer’s got a delivered usable working product that solves their business problem right that would be the expectation at the end of that time period but in between those two points we largely go dark right there might be touch points with the customer we’re going to show you the documentation uh we have little demos that we might do of different parts of the product in isolation but they don’t really get a holistic visibility about what’s going on where we are.
We’re just telling them so we tend to go fairly low visibility not to zero right but fairly low visibility and then at the end of the product cycle it jumps up as we deliver a usable working product.
However for visibility in an empirical model we’re actually going to start in exactly the same place and we’re going to end in exactly the same place right we have high visibility at the end because they’ve got a usable working product we’ve got high visibility at the start because we’ve got documentation potentially right but at the end of every single iteration we’re going to be providing the customer with a usable working product right that’s how we mitigate risk it’s the minimum bar for an empirical process a minimum bar for scrum is a usable working product at the end of every Sprint.
So in fact during each iteration we’ve got that low visibility but we jump back up on a regular cadence as we’re delivering usable working product to the customer so they get these many touch points where they’re able to make assertions change direction and have a different understanding of what’s going on.
Now let’s look at our ability to change our ability to change I would quantify that as our the implications and our ability to accept change into the system right we’re creating product so as we build more product we have less ability to change because each change has a bigger and bigger impact.
And in a traditional model our ability to change is very high at the start and at the end it’s very low right we have if we finish the product we’ve spent our 12 months working on it we’ve delivered the usable working product we’ve deployed it to production we know no longer and have an ability to to change it unless there’s more funding more budget.
But very quickly as we get started building the documentation the more documentation we build the more impact change has right a small change could have a massive impact on all the documentation we’ve created.
So our ability to change drops very quickly and then we start actually building product and perhaps we build the entire database first or we build the database and then the mid tier right and then the uh uh interface that customers are going to interact with and we’re building it constantly and we’ve kind of started everything so our ability to change drops again it never drops to zero right but throughout the life of the product it stays very low so it drops very quickly and then stays very low across the life of the product.
Our ability to change in the empirical model again starts in the same place and finishes in the same place right we’ve got a time limited uh product cycle but what happens during that product cycle is our ability to change remains higher right higher it’s still going to drop right because every time we deliver a usable working product the things that we’ve already built are harder to change than things we haven’t built yet but because we’re building in those vertical slices creating working usable product that the customer can deploy to production each of those vertical slices allows the other uh uh 90 right at the end of Sprint one the rest of the backlog the stuff we’ve not created yet can really can change anything they want with very little impact right because we haven’t built copious amounts of documentation we haven’t built copious amounts of product yet so they can change anything they want.
So the idea is that the ability to change is still going to drop Sprint on Sprint but it does remain much higher all the way through the life of the product and obviously ends in the same place.
Now let’s look at operational risk an operational risk in a traditional model we’re going to start high operational risk right because we’ve not delivered anything and then when we deliver our usable working product at the end of our product cycle 12 months we’re going to have a zero operational risk because we’ve deployed a working product for them.
I know there’s an assumption there but uh let’s let’s assume the best and then over the life of the product we’ve actually got very high operational risk if we’re six months into our product cycle what operational risk for the customer have we alleviated zero right no operational risk so it needs to remain high during the life of the product and then right at the end we deliver that working usable version of the product right so we alleviate all of their operational risk in one big chunk.
In an empirical process for operational risk again we start high and again we finish low but every Sprint we’re providing a usable working product so the operational risk gets a little bit less.
At the end of Sprint 2 it gets a little bit less again because we’ve delivered usable working product that solves their business problem and we end up with that straight line from top left to bottom right.
Right every Sprint we’re alleviating some of that operational risk now in reality we should alleviate it quicker if we as a team are focusing on delivering the most valuable things that that customer needs to know first.
So that operational risk might might be more of a curve but let’s assume it’s a it’s a straight line let’s take a pessimistic view that each Sprint we just alleviated that Sprint’s operational risk.
Finally let’s talk about realized value the delivery of value to the customer.
So in a traditional model and we have zero value at the start of the product cycle we deliver a working product to production at the end so we have our our usable uh working product that perhaps we delivered our 300 features that the customer asked for and and how do we how do we get there well we’re only delivering to production at the end right the customer can only use the product once it’s in production it only adds value once it’s in production so in fact we’re not delivering anything during the life of the project and then right at the end they get their usable working product obviously it always works with their 300 features in it that are exactly what they asked for and uh they’re they’re happy because they got that realized value at the end.
But maybe there’s a better way because what did we learn a little bit earlier in this discussion we learned that 35 of those features are used by the customer at the end of that product cycle only 35 percent right that’s like 90 100 110 of those 300 items are actually used at the end of the product cycle that’s not particularly great so what could we do instead.
Using an empirical process there’s actually two ways to draw this graph one is that we’re going to start at zero value just the same and we’re going to end at those 300 features.
So this assumes that we’re doing an empirical process inside of a traditional organization or working for a traditional customer the customer says here’s these 300 features we’ve added them to the contract right and then that’s what we’re going to build and we’re not going to very low variance of change right because we’re going to put barriers in their way like change request boards and uh cost you know having to do a business case to make a change all of those things we’re gonna we’re gonna just deliver those 300 features.
But at the end of every Sprint we’re actually able to deliver them some value right so at the end of each Sprint here is some value here’s a product that you can deploy to production that solves some of your business problem right not all of it but some of your business problem.
And every single old Sprint we’re delivering a working usable product along that line right so the customer is able to get value from it sooner so if you think about the realization of value at the end of Sprint three they’ve got three Sprints worth of value.
How much of their business problem is alleviated already and we’re not at the 12 month mark where one quarter of the way through the product cycle and we’ve alleviated one quarter of the business problem right they’re adding value as we go along so they’ve had the value for longer is what I mean it’s not sitting on a shelf because we’re able to deploy to production.
But there’s indeed a superpower there because only 35 percent of those 300 features are used so we actually don’t want to build those those 300 features we want to build a different 300 features right even if we just get to that 300 mark.
So what happens is at the end of Sprint one we remove things from the backlog that we no longer need perhaps the customer has realized that they asked for stuff they don’t need perhaps the market’s changed and they no longer need that perhaps a business decision has been made right there’s a branching decision this way was one set of 100 features this way was another set of 100 features so they added them all to the backlog but now they’ve made that decision and it’s this one so we can delete these hundreds right so we delete those things and we don’t build some of those things and we take it in a different direction right we add more value sooner in the product cycle as we go and perhaps we hit that mark of the same 35 percent of value much sooner perhaps we hit it in month five.
Right we could stop there and have delivered the same value that we would have delivered in a traditional model but at 5 12 of the price my math’s not good right 5 12 of the price.
But what often happens is in the product cycle we continue to build features different features based on the needs of the business based on collaborating with customers and stakeholders and we add way more value to the product.
That’s if we’re using an empirical process within an organization within a structure that is accepting of that level of change.
And that is what we want to get from an agile process so even using an agile process inside of a traditional organization we get value we maximize visibility we maximize our ability to respond to the changing needs of the customer we minimise their operational risk and we continually deliver value that that customer can amortise over time right.
Those are the superpowers of agile even within a traditional organization if we can change the organization as well we can get even more.
Well thanks very much for listening if you’re interested in uh uh reading a little bit more in depth into this story of agile um I really recommend the new new product development game it’s a harvest business review article from 1986 it’s available free online and I also recommend Stephen Dennings book the age of agile.
If you would like to get in touch with me please use this QR code right here uh to book a 30 minute free consultation with me and we can figure out how we can make your world a little bit better.
