Inspect and Adapt: An Introduction to Agile Planning

Don’t make the hardest decisions at the dumbest point (ie. the beginning) in your Agile planning process. When we first start on a project, we rarely have a complete idea of what it takes to create a truly great product. There is always unexpected feedback or requirements that enter the picture.

In Agile, we plan and forecast for our projects like you would in traditional project planning. The difference is Agile Planning encourages us to inspect and adapt to feedback in order to create the best products for our users.

Familiarize yourself with the basics of Agile Planning with this quick video from David Hawks, and learn how to adapt as you encounter charges during product development.

Learn more about Agile Planning by reading our article on the subject: Don’t Lock in Tough Decisions Early.

Video Transcription (has been slightly edited for brevity and clarity):

Traditional Planning

Hi, I’m David Hawks with Agile Velocity. Today, I’d like to talk to you about Agile Planning and how that compares to traditional planning. When we do a traditional project, what I would typically do, pre-Agile, is I would have my starting point and then I would need to create a plan to hit some target out in the future. The way I would do that is I would go get estimates from all of what I used to call resources, and I now call people, I would get estimates from everybody and then start to build out the plan.

The plan would something like this–I need 2.2 days of one person’s time and 3.8 days of somebody else’s time. Meanwhile, one of my other resources would be working on this for a week. It was kinda fun, solving this puzzle of figuring out how to load-balance everybody. What’s the critical path? How do I get everything done? How am I am going to get everything done by the date? Now, I’d get to the end and I’d have a eureka moment where I had solved the puzzle. I had figured how we could get all this stuff done and I’d show it to senior leadership and they’d be like “Wow, you guys really know what you’re doing over there. You know what everybody is going to be doing every single day for the next six months. Because look at the plan, the plan shows what everyone should be working on. Every day mapped out for the next six months.”

Now, let me ask you this: when we created this plan, at the beginning of this project, is this our smartest point of the project? NO. This is actually our dumbest point. But we tend to make the hardest decisions and lock them in. These plans, which I now call Mythical Certainty: the level of precision of this plan doesn’t match the level of accuracy of our understanding of the requirements at the beginning. We have these very precise plans with a very imprecise understanding of the requirements, which leads to this illusion of certainty. The plan makes everybody feel good because once we have a plan, everyone says we have a plan, we have it all figured out. But the reality is, the plan is not perfect because the requirements are not perfect.

Agile Planning

So what do we do? What do we do in Agile? We could what we call hippie Agile: you have your developers, they come to senior leadership and say “Hey man, we’re agile. You’ll get it when you get it, man.” And I know a lot of developers that try to pull that off. But that doesn’t really work for businesses. We can’t just say, “We have no idea.” We do actually have an idea. We can forecast and actually in Agile, we plan and forecast a lot. We’re just responsive to change.

So what we want to do in Agile is acknowledge we’re at our dumbest point. Based on the information we have, we know we need to set out in the direction of the red target, but we’re going to apply empirical process control. And along the way, we’re going to constantly inspect and adapt based on the new information we get. And when we get a couple weeks in, we’re going to decide if we should keep heading in the direction of the red target, or based on what we have learned, and what new requirements have potentially come up, or new things that we need to do, we can decide to adapt our plan.  And almost always, something will come up that we want to adapt to. And then we’ll head off in a different direction. We’ll apply a time-box and usually, in Scrum, it’s two weeks. And we’ll come back, and say, okay, based on that, do we want to keep going in that direction, or make another correction? We continually make these little inspections and adapt cycles along the path.

Now, is our goal to get back to the red target? Is our purpose to actually hit the red target? It isn’t. Our goal is not to hit the red target because the target was defined when we were at our dumbest point. We’re not trying to hit our red target, we’re trying to find a way to deliver the most value. The red target doesn’t guarantee that. So we’re typically going to continue to adapt until our time box is used up, or what our release schedule was set for, and we’re then going to find this new target. This new target allows us to maximize the most value possible over this period of time.

So, the fallacy in the red scenario is that we know everything up front and we just need to manage to the plan, manage to the red line to get to delivering the value that we set out to do. But, the reality is we have imperfect information so our goal is actually to accelerate learning throughout the cycle and get smarter about the problem and get smarter about potential solutions so we can deliver as much value as possible over this period of time to get to and find this new target. It’s somewhere around the red target but it’s not exactly where the red target is. And that’s what we’re trying to do from an agile planning perspective, it’s a change of mindset, not just a way of managing a project.