apm 8 2

Alright, so we've just debunked the myth that Agile is anti planning. Remember, we're just anti planning all at the start of the project. Instead we're focused on adaptive planning. But you might be wondering what are some of the ways to actually accomplish that? Now we often talk about the different layers of planning in what's called the planning. Onion. Onions. Onions. This layer analogy helps show us how high level strategic planning cascades down into the day to day execution. So here at the outer layer we have annual planning. This is where like high level vision is set with our customers. Our organizational goals are defined, our measures of success are established. And now you'll note this layer has the lowest frequency of change, but has the highest strategic importance and typically involves the highest levels of leadership. And sort of one layer down, there's the quarterly planning. Now here we would have things like creating a roadmap or a timeline of new features. We're looking maybe six to 12 months into the future and then that's broken down into monthly planning. This aligns current sprints to the upcoming release. And we're typically looking maybe two or three months ahead, maybe a quarter of a year at this point. At this level we're starting to see how the roadmap translates into actual product releases. And then we have bi weekly planning, maybe Sprint planning if you're doing Scrum. But here we cover short term plans, typically like two weeks out. We're defining what we'll be working on from the backlog. Maybe that's user stories or bug fixes or technical debt, but whatever it is, this is where we begin to see the rubber meet the road in terms of actual development work. And finally, at the most granular level, we're actually doing daily planning. You might have heard of the daily team Sync or the daily Scrum. We're literally making a plan for the day. We're talking about tasks aligned with user stories in the current Sprint and what we're going to get accomplished to meet our goals. So this is the most granular level and has the highest frequency of change and typically the highest involvement from the development team members. As we move from the outside in, notice how the planning becomes more frequent, more detailed. But you'll also notice the leadership involvement also shifts, with day to day execution being primarily managed by the development team. Now, conversely, as we move outward, we see decreasing change frequency. The product vision remains relatively stable, while daily tasks can change rapidly to meet immediate needs. This structure allows organizations to maintain a clear link between their long term strategic goals and their day to day operations. Each inner layer is informed and aligned with with the layers outside it. It ensures that even the most minute daily tasks are contributing to the overall product vision and organizational goals. Now let's take a look at some of the examples of the three outermost layers. The product vision, the roadmap and the release plan. A product vision defines why a product exists, who it serves and how it's different. It should be purposeful and clearly articulate why the product exists. It should be aspirational, like painting a picture of the future achievable, that is, it's grounded in reality and it's feasible to achieve. And the vision needs to be customer focused. It should be concise, conveying the message without any extra fluff. And of course, it needs to be understood by everyone on the team. In the book Switch authors Dan and Chip Heath liken this future vision to a destination postcard. I'll send you a postcard, like a postcard sent back to the team from the future. Consider this one from the Venus Project at Technova. Here we're casting the vision of what could be of something that's yet to come. It's a desired future state that we can all strive towards so you can present your vision in multiple ways. And Postcard from the Future is just one creative example. And from that vision we want to create a roadmap that helps us communicate when we might see these fantastic new features that will fulfill the vision. Now, a popular way to do this is with a quarterly roadmap looking at features. A roadmap is a useful sense making tool, if you will, for how we discuss with the project team and the customer around the scope that we're planning and any key milestones that we're tracking. It's a mid range plan that we're looking at once a quarter to help figure out what our priorities are. Now, real quick pro tip here from the field, roadmaps are forecasts, not commitments. Remember, we're talking about adaptive planning, so we just recognize things might change. So we're using roadmaps as a forecasting tool. All right, the next layer down from the roadmap is the release plan. Now here we're looking across multiple sprints or time boxes and we're showing things like dates and the sprint number, maybe capacity, even when we might release, release to production or deploy to the customer. Notice, we're getting much more granular with this type of plan compared to the feature roadmap. The highly visual nature of a plan like this makes it very clear what's being worked on and when you'll find that simple information. Radars like this make it easier to communicate what your plan is for the release. The planning onion metaphor links long term strategic goals with day to day operations. This approach enables teams to remain flexible and responsive throughout the project lifecycle, continuously refining their plans based on the most up to date information and insights gained during execution. Well, so there you have it. A few ways to do adaptive planning and how each layer interacts with each other. Adaptive planning is not about predicting the future perfectly. No, it's about creating a framework that allows you to respond to change efficiently and effectively, all while keeping your projects aligned with strategic goals, no matter what challenges arise.