A very common, and very dangerous misconception about Agile development — whether you’re using Kanban, Scrum, XP, DevOps, or any other flavor of the week — is that it “requires” or “expects” that you can operate quickly, efficiently, and effectively without necessarily having an overall strategic plan.
There certainly are teams and companies who waste their valuable time and energy moving forward through iteration after iteration without following a long-term plan. And some of these teams can be successful in delivering in-the-moment, valuable solutions to customer problems. And these teams can sometimes continue to be successful at this for a short time, until they realize that an entire organization has grown up around the product, and there are impacts to this lack of planning that span multiple groups.
Agile does not mean you don’t have a plan. It means that you have a plan that’s flexible enough to accommodate valuable and important shifts in the plan’s underlying assumptions.
First, and most importantly, let’s look at what the Agile Manifesto has to say about the subject:
[W]e have come to value…
Responding to change over following a plan
Note that this does not say that there is no plan. Rather, it’s a value statement that provides us with guidance — when faced with some change, do we rigidly and strictly follow whatever plan we’ve built, stubbornly pushing forward against all information to the contrary; or do we adjust the plan for the new information, and make necessary changes to accommodate this new knowledge?
The problem in most organizations is that they haven’t adjusted their business practices and expectations for the newly-adopted Agile development practices. Rather, they’ve bought into the myth that Agile is just a development process, which is patently untrue. And, all too often, the developers themselves have been told by others that Agile means “no plan” and “no documentation” — again, neither of which are true in any real reading of the manifesto that supposedly underpins all Agile practices.
Thus, in a business that hasn’t properly prepared for a transition to Agile, you have the tension between the business being very plan-driven, and the development team being very plan-averse. If you’re specifying features that have a dedicated delivery date, and you’re communicating those dates to your customers or using them to assess the performance of your development teams, you are not being Agile. Agile planning requires an entirely different approach and an entirely different set of artifacts than traditional product planning efforts. Rather than working at the feature/functionality level, Agile planning needs to operate at the thematic or vision level — setting goals based on areas of functionality or of market need, and not on specifically defined functional deliverables. This provides the business a foundation of knowing where they are going, and still maintains the flexibility to change the plan, either in the specific deliverable within the theme, or even by changing the thematic goal itself.
Similarly, in a business that’s been founded on the mistaken assumption that Agile means “no plan”, there are different challenges. At some point in the process, investors or customers or even internal resources are going to want to know that there’s an actual point to the work that the development team is doing. They’re going to need to understand what the longer-term plan is, and 2-week delivery iterations just aren’t going to cut it. The more sophisticated the business gets, the greater the need for some form of plan, even if it’s strictly vision-oriented. These companies actually transition more readily and easily than companies used to strict planning, because with a good product manager leading the way, the benefits of having such goals and of planning while maintaining flexibility in the plan will be very clear from the outset.
At some point, every business will need a strategic plan — one that will be used as a roadmap for product design, product development, market segmentation, marketing, and sales efforts. You simply have to know where you’re going in order to know when you’ve arrived there — even if you already have the next stage in your trip planned out. This doesn’t mean you can’t take detours to get there — in fact, it’s often the case that when you’re working “off-plan” you find the most interesting and innovative solutions to your customer’s problems.