Mike Lyons explains why Agile teams build a skateboard before a car. Iterative delivery gets working software to users fast, catches problems early, and lets you pivot without wasting months on features nobody needs.
Chapters
Well, so how'd you do on that exercise? Did you find it hard to sort of pick which ones to deliver first and second? You know, there's a lot of common ways that we see this exercise delivered and answered. And I want to just share with you the two most frequent sort of solutions, but then tie them back to the Agile Manifesto and the 12 principles of the Agile Manifesto. So let's sort of look at the two different methods of, of delivery, sort of first and common. We might see the traditional approach to delivery where we deliver first the wheel and then we deliver the wheels on a chassis. From there, we then deliver the body of the car. We then put the, you know, windshield and steering wheel in the car and then finally put the roof on, and then we're delivering the thing all at the end. Sort of big bang delivery all at the end. The other way is what we might call a more agile approach or iterative approach is where we deliver a thing that works, a skateboard. We deliver the skateboard first, and then from there we then deliver again something else that works but maybe is better. The scooter, followed by the bicycle, and then the motorcycle and then the car. Now, two different approaches to delivery and two different methods. And so let's sort of unpack those at each step along the way. Again, sort of in our first iteration then, and we'll focus on the Agile approach, our first iteration, then we deliver the skateboard. Now, you might call this a minimally viable product. What is that? Well, an MVP minimally viable product is this idea that we're delivering a viable solution early and we haven't invested a lot in it, but it does work. And our goal is to gather feedback and get information about that mvp. And we're really ticking the box on a few of the Agile Manifesto principles. Let's think about this. Remember, Agile Manifesto principle number one, our highest priority is to satisfy the customer through early and continuous delivery of valuable software. We sort of invite Kayla to take a look at the skateboard and we're delivering this thing of value. We're gathering her feedback. We're also looking at a couple other principles in the manifesto. Take a look at number seven, for example. Working software is the primary measure of progress. We're delivering something working to Kayla so that we can understand where we're at in the process and measure our progress. How about agile principle number 10? Simplicity, the art of maximizing the amount of work not done is essential. Minimally viable products allow us to maximize the amount of work not done, meaning we don't want to build out something, invest in something and spend a lot of time building something without knowing if the customer actually wants it. So we're really aligning this sort of method back to our principles. Now the traditional method, we deliver the wheel. The wheel isn't really something we can demo. We can't really get a lot of feedback. It doesn't answer the request from Kayla. She can't use it to get from her house to work. So we're still just sort of following a plan and delivering horizontally and traditional. Let's take a look at step number two. Well, here we are at the second iteration and we've learned from the last demo with Kayla and so we bring, we work with her and we bring the scooter forward. We've made improvements upon the first deliverable that we had for her. It's maybe easier to steer, easier to control, learn how to use. For Kayla, we're learning what is important for our customer. We're delivering a thing of value. Let's take a look at one of the Agile manifesto principles here as well. Principle number three, deliver working software frequently. Now, the waterfall path, essentially we're sort of moving along the implementation plan and delivering the wheels on a chassis. But Kayla still can't use that. It's still not viable. She can't use that product where we're horizontally delivering in the iteration, the sprint, and not able to put that product to work. Now at step three, let's take a look at that third step here in the agile delivery method, we've taken the information from the scooter and we've delivered a bicycle to Kayla. It's really at stage three, we begin to truly see the power of this agile approach. We're gaining knowledge and learning and delivering products that make sense and are of value to our user. To Kayla, in this case, the traditional path is sort of diligently following the plan and delivering the now body of the vehicle as it works down the, you know, project plan. Still again, not able to provide value. Kayla can't use it to, to meet her needs. Yet, you know, when we think about the value of these approaches, the value of feedback and the idea of fast feedback and learning and building better products, it becomes clear pretty quick that the delivery method of the agile approach is going to be faster. You're going to have better products when you're getting that feedback and delivering to Kayla. Now consider this, and this happens not infrequently on projects and maybe this has happened to you. What if the project runs out of funding at like the third step in what is our user left with? Well, in the traditional path they're sort of left with these wheels and like a, you know, the car body that she can't do anything with. But at least in the agile path, she's left with something she can use and continue to use. And she has that. Well that happens in software development projects all the time. Or you know, I mean the pace of change is relentless. The technology landscape may shift under our feet, New technologies may emerge that we can take advantage of. Well, if we're just working a plan and we don't have this sort of agile approach, it's very difficult to pivot and take advantage of new technologies. Here's the key takeaway. How does this apply to software development? Well because traditionally in software development we don't deliver a skateboard. You know, in classic waterfall we build like infrastructure, we spend a bunch of time layering infrastructure and then, and then we'll build up like the database layer and then we'll do a little business logic logic and then finally we'll put the UI on and we haven't delivered anything yet. Look, your customers don't care about the database. Like they just don't. They need one and it's important, but it in and of itself doesn't release value by the time you get the UI on it and slap all your business logic and get a full cut through the layers. Now you're talking right now I can, I can see like a like old timey hello world type app that like a real functioning thing, it doesn't even have to be pretty, it just has to be good enough to use to get feedback. That's the agile mindset. That's the difference. That's the difference. We're delivering full slices of value delivery quickly. And maybe you're wondering, okay, that's great for software. What else could you do that way? Well, okay, if you're writing training manual, wouldn't you like to get the first chapter out and ready for review or even the first lesson? What if you're doing like an online learning program? If you start just planning the learning and gathering the information and start writing, but you haven't stood up the system and got it out for someone to test, you're really waiting till the very end to deliver and that's just not a great place to be. Remember Agile Mindset of Agile says we're going to get fast feedback in iterative development from a prioritized list of work and full stacks of delivery. A skateboard and and so I'll ask teams, how fast could we get a skateboard out the door to see if that would work? Which means I have to have the UI and the business logic and the database layer and the infrastructure. I have to have all of it, and then we build on top of it. Very different approach. This is why we say it's a mindset.
