Mike Lyons argues that delivering small slivers of work every two weeks beats waiting 12 months for feedback. Traditional projects spend months on requirements and design before anyone sees anything. Fast feedback loops, daily standups, and canary rollouts let you catch problems early and change course.
Another important aspect to managing systems is thinking about how we're optimizing for learning. If we're operating in this complex space where we know that the goalpost is sort of always moving, then we need feedback. I want only positive feedback, please. We need to be fast to learn in order to effectively deliver these agile projects. Take a look at this image. We've got two examples of learning loops here. On the top we've got the traditional phased delivery approach. So you see here requirements three months, those M's, those are for months. Design, two months, build four months, test two months, and then finally, all at once, deploy, one month. If I were to ask you, how long do we need to wait before we get real feedback on this traditional sequential approach, what might you say? Well, it's. It's 12 months, right? Meaning we have to go through requirements, design, build, test and deploy before we have a working solution that we could put in front of our customer. We won't have any real meaningful feedback on that for possibly a year when we move in this sequential fashion. And that means we're accumulating risk the entire time that we're working. We're assuming that the requirements that we discussed and documented and signed off on, you know, perhaps eight or nine months ago, that those are correct. But what if we get all the way into the testing phase and realize, nope, they weren't correct, they were wrong. Well, now we've got all this big liability on our hands. I've been on these projects and you get to the end and the customer's like, what the heck is this? We start to backpedal and pull up the signed request requirements documents and say, well, this is what you asked for. And the client says, maybe, but it's not what we need. You are wrong. We missed all of our learning loops. There's got to be a better way to deliver. The agile delivery approach that we see down below is to work through slivers of each of these phases rapidly. We're learning and adjusting as we go. You can see we're going to do a bit of requirements, a bit of design, a bit of build, a bit of test, a bit of deploy, but we're going to do it frequently. In this example, we're working through it every two weeks. We're doing a little bit of all of these things. We're delivering a unit of value, we're confirming that it can be deployed into our technical environments, and we're getting feedback from the customer. We're learning as we go. Are we on the right path? We're chipping away at the problem that they're looking for us to solve frequently when we're doing it this way. This system of fast feedback optimized for learning what's crucial when we think about managing a system and you need to construct policies and processes that allow us to get this fast feedback. So what are some ways you might do that? Well, here are some specific policies and practices that enable fast feedback in Agile projects. Short Iterations We've already seen the example of two week sprints. These short cycles that allow teams to frequently showcase their work and gather feedback. A quick daily team meeting to provide immediate feedback on progress and obstacles and allowing for rapid adjustments. Practicing canary rollouts where you roll out your product to just a specific user group or geography. Continuous integration and continuous deployment. By frequently integrating code changes and deploying to test environments, teams can get technical feedback quickly. Regular stakeholder demos, scheduling frequent demonstration with stakeholders, not just at the end of sprints, can provide valuable business feedback. These approaches, whether you use Scrum or not, help enable fast learning. Think about your most recent project. How often did you get real and meaningful feedback? Was it primarily at the end of the project or were there opportunities throughout? Consider the ways you learned during the project. Were there formal feedback mechanisms in place, or was learning more ad hoc? If you found yourself mainly getting feedback at the end, how might you incorporate some of these fast feedback practices in your next project? What benefits do you think you'd see? Remember, our goal is to create a system where learning is continuous, where risks are identified early, and course corrections can be made before it's too late. And by implementing these feedback practices, we can significantly improve our ability to deliver value in complex, ever changing environments.
