It’s been almost twenty years since the founders of the Manifesto for Agile Software Development laid out their vision for satisfying the customer. Since 2001, developers everywhere have memorized and followed the four main concepts, including the fourth one, which goes like this:

Responding to change over following a plan

The problem is, this can make it seem like long-term planning doesn’t fit within the idea of Agile development. But we all know that a product roadmap — essentially a plan — helps the team maintain a unified vision of what they’re trying to achieve.

So, how can you have both?  How can you be part of an organization that reacts quickly to the client and business needs but which also takes into account the bigger picture and does some planning?

Agile Development is Not the Opposite of Planning

Sometimes people think that being Agile means you don’t use product roadmaps. In fact, it’s been used as an excuse not to use a product roadmap or to even put much time into the design process up front.

That would be a mistake because it’s during the process of planning that vision takes shape. And no matter how Agile you are, there’s always a place for product vision.

  • The users’ needs don’t change all that much (that means you can do some planning).
  • But how you fulfill those needs can — and will — change with each iteration as you hone in on a better version (there’s the Agility).

Let us explain…

Planning is How You Arrive at a Broader Vision for Solving Customer Problems

Planning fuels vision. And it’s the vision that keeps an Agile team focused on the larger problem at hand rather than, let’s say, focusing on features. It’s what keeps a team from losing sight of their main goals. Planning helps a team stay focused on the ultimate goal, which is to solve a problem.

Without a plan, teams can easily get caught up in details of “what’s next, what’s next…”. Without a guiding vision of the ultimate goal in mind to unify them, teams can end up scrambling insanely from project to project. They’ll be fulfilling goals alright — small goals that may or may not serve to solve the actual problem the customer is having. We’ve talked about solving the wrong problem before.

Our solution to that is dedicating plenty of time to a full-fledged Discovery Process and coming up with — yes, a plan. But we’re still as Agile as they come!

Here’s how that works for us…

You Can Plan a Design and Still be Agile

There are some things that don’t really change all that much during the course of a product’s development. These tend to be the broader elements of the context in which the product will ultimately be used:

  • Users’ needs
  • Business needs
  • Business goals

Planning your design with these things in mind does not prevent you from adopting an Agile process. You can pivot all you want around the same set of user needs. Those needs don’t change much.

Design planning happens initially, while what makes the team Agile is how they respond to things down the line. Sure, feedback is always helpful but if all you’re doing is guessing and hoping for the best and then simply responding to feedback, you can end up wasting a lot of time. A plan keeps you focused on the problem at hand so you can set up the framework for a thoroughly-analyzed solution to the client’s problem (in other words, a design plan!).

Optimizing Your Team: Planning and Agility

We love how Agility makes teams more efficient. But we also know we couldn’t consistently be producing quality deliveries without a ton of planning.

Planning sets the tone for everything we do. It’s all in the questions we ask, the data gathering that we do, the deep dive into the client’s world that we take in order to understand user needs and business requirements.

And usually, those broader, big-picture observations that we make aren’t likely to change. As we’ve refined our processes over the years, we’ve learned that it’s those ecosystem-level assessments that we make during the Discovery Phase that serve to guide the product’s development and keep us on track for success.

Of course, every organization is different and every customer is different. There are also lots of different definitions of planning. But we’re confident that the system we’re now relying upon — a seemingly contradictory combination of good planning and Agile development —  will stand the test of time and serve us for many years to come. What’s your experience with planning and being Agile? Do you think it’s possible to do both?