Product teams are asked to plan in all kinds of ways and for all types of timeframes. We make individual sprint plans about how to hit our goals, and broad long-range plans about how to increase our penetration of existing client markets and grow into new markets we can serve. We have release plans that tie to our product roadmaps and we have plans for the best way to work with architects and database administrators to ensure our product fits well into the ecosystem of our platform. We have marketing plans on how to communicate about our new features and revenue plans as part of our OKRs (objectives and key results for those who always wondered what those letters meant).
All of these plans (hopefully) are made with the best of intentions and with access to the most accurate information available at the time. But the only thing we can count on about our plans is that something unexpected will happen or some new piece of information will force us to change those plans. In truth it’s not that simple. That fact – the reality that even the best plans will have to be adjusted along the way as the team learns and the world evolves – can make elaborate and drawn out planning processes feel like a costly waste of effort. Knowing this leads some people or teams to abandon planning altogether; instead they become reactive to each new piece of feedback. Indeed some outside the Agile development community complain that Agile as a framework discards or at least highly dismisses the value of planning and leaves teams endlessly iterating until work is “done done.”
Surely some level of planning is important; otherwise as Yogi Berra said, “If you don’t know where you are going you might wind up someplace else.” Finding the right balance between having a good plan and knowing when to shift with new information can be tricky, and the more time invested in the planning process the more painful this all feels. A few years back I wrote a series of blog posts about Agile planning that tries to address some of these issues and you can find the first one here. But having spent some time in January making plans for the year only to see some of them now sidelined as the world has changed, I want to suggest a more light-weight way of planning; instead of investing large amounts of team time making detailed plans meant to address months of future work, I’d like to propose that to make the most of your time you have to be a “fast” planner. Your planning discipline should be Focused, Adaptable, Strategic and Tactical.
Good plans are focused; rather than being overly broad and general they are explicit and detailed on both what their aims are and the timeframe with which they are concerned. In our company (and many others) we talk about having SMART goals that are specific, measurable, action-oriented, realistic, and time-boxed and that is what I am getting at when I talk about making focused plans. At the same time, good plans must also adaptable; they aren’t so tightly bound by specific circumstances and outcomes that they can’t adjust to the new things you will encounter on the path toward your goal. Just as good plans have to find a balance between being focused and being adaptable, so too they must balance the longer-term vision with the shorter-term objectives; in other words they have to be both strategic and tactical. Strategic plans exist in the wider context of company or product goals which (hopefully) don’t shift dramatically even as some circumstances change while tactical plans take manageable steps toward that overarching vision; good plans make reference to both strategic and tactical goals.
Though no plans are perfect and all plans must be frequently adapted to stay relevant in changing circumstances, there is still value in making and having plans so as to avoid being aimless or reactive. But because the world changes frequently and plans must change as well to stay meaningful, it is important that the planning process not be slow and cumbersome. FAST planning is one way to move toward that aim, but I know that in truth it’s not that simple.