October 28, 2016
How Do You Plan In An Agile Environment?
One of the biggest struggles with introducing a company to Agile development is the fact that we don’t sit down and plan every last detail up front. Don’t misunderstand that though. We do plan. We plan all the time actually – every two weeks in fact. What we don’t do (for reasons which I will explain) is plan every last detail up front at the start of the engagement.
It’s true that this makes it difficult to tell you exactly what you’ll get by what time, and for traditional waterfall developers this can generate a strong feeling of uneasiness, even panic (at least it can for the traditional project manager). But by delaying the decisions to the last responsible moment, we can apply our learnings from previous iterations to the upcoming ones. We can apply the feedback we’ve received from our clients, end users, and stakeholders to the upcoming features. In the end, this means you will end up with a product more closely aligned to what your end user needs and will use.
So how do we do it? How do we maintain a trajectory without planning out everything in advance? We use the concept of progressive elaboration guided by a product vision, road map, and release plan. Before we even get started, we review the roadmap and product that may exist for a client (if one does not exist, it will be developed alongside the release plan many times). This helps us understand the goals our clients and stakeholders have for their product.
Once we’re clear on the roadmap/vision, we’ll start to decompose the features/efforts at the front of the roadmap. We list out features and then decompose them again into user stories (that don’t yet have all the details). We do a quick affinity estimation on these to get a sense of size and then prioritize them in order of most important to least (although everything in a first release is important). It’s salient to note that we’re looking only at the features/efforts that are to be in the first (or next in subsequent iterations of this) release.
We then place these stories into a release plan. This release plan is a more detailed view of the efforts, generally broken into iterations, with stories or high level features listed out. The further out you get in the release plan, the less detail you have. Don’t worry, you’ll fill that in later.
I mentioned earlier that I’d expand on why we don’t plan everything up front. The answer is easy – things change. Markets shift, priorities change, you learn something during a previous iteration. The world changes, so waiting until the last responsible moment to add the details allows us to be the most reactive to these changes. In fact, our plans are made to change. We anticipate learning things as we go and having to adjust. That’s what makes a great product.
The important thing to remember is that we review the plan often and add details as we go. The release plan should be reviewed EVERY iteration. The roadmap should be reviewed at least monthly. Changes to either should be communicated to all stakeholders and made as visible as possible.
So, in the end - planning is a core tenet of Agile development. And while we don’t often generate exhaustive project plans, our efforts are guided by an overarching product vision, roadmap, and ultimately a release plan designed to help communicate to everyone what our end goal is. The outcome of this is almost always a better product that is more closely aligned to what your end user wants.