When the Agile development mindset runs head-on into the traditional methods of project planning and budgeting, here are three things you can do.
Agile estimation and roadmap development is an area fraught with potential conflict and misunderstanding. Clients or business sponsors, especially those well-versed in traditional project management disciplines, make the assumption that the roadmap's function is to develop a project estimate, and they will often immediately jump from the roadmap planning exercise to the million dollar question, "How much?"
Let's visualize what we produce as a result of a roadmap exercise. Typically, we create a long-term vision, usually around 3-5 years, of where we see our product going, which major features we hope to develop and implement in what broad time frame, how individual programs and projects might fit into these overall strategic goals, and how the efforts will be parsed out among teams and leaders. Some teams will draw an actual roadmap on a flip chart or a whiteboard, and some will use a software product to capture this path.
For example, if we're thinking that we'll deliver a social networking component to our application suite, we may plot our roadmap geographically and say we'll roll out United States in 2013, then Europe in 2014, and Asia, Africa, and the Middle East in 2015. We may take an alternate approach and plan our rollout by target customer segment. The point is that we're thinking and planning strategically, and digging down into tactics only when we must in order to make critical staffing or market decisions. This is where the potential for conflict and missed expectations begins to manifest.
As we start to lay out these plans and goals against a time line, the sponsor naturally wants to quantify the investment. If the organization has not transitioned to an Agile mindset at the executive level, we may be working with a CFO and finance team that expects a fixed budget long before the actual work plans are plotted out. For public and regulated companies, there's no choice but to predict at some level the investment expected. From the agile team's view, however, the more speculative the strategy, and the more innovative the product, the more likely that we'll be modifying our feature sets, expectations, and work plans significantly as we go. In short, this is where the Agile development mindset runs head-on into the traditional methods of planning and budgeting.
Sponsors need to tell investors and executives what sort of investment will be required to deliver the features that will keep customers in the fold. Agile practitioners want to keep their options open and move forward in an iterative, incremental fashion, even if that means that we can't know the cost, the final feature set, or the exact path we'll take to get there. So what do smart Agile teams do to mitigate this rock-and-hard-place conundrum? Here are three suggestions:
- Clarify the intent: You need to make sure that everyone associated with the roadmap exercise understands this is a broad strategic planning exercise, focused at the portfolio level, and not a detailed tactical workplan.
- Don't get dragged into tactics: It's common for sponsors, and often for the more tactical-minded among the development and project management staff, to want to interrupt the vision exercise with the granular "who's going to do what when?" conversation. This is not strictly forbidden, because we often need to go there to build a realistic strategy, but if it threatens to derail the strategy and become a project-planning session, leaders need to remind participants about the goal of the roadmap exercise.
- Help sponsors visualize the broad investment: All of this "vision" stuff is great, but if we insist on ignoring or shutting down the pragmatic questions of cost, we risk losing the support of our audience and sabotaging our methods.
The path to a budget or estimate often seems extraordinarily complex in an Agile environment; how can we plan for the unplanned, leave space for iterative discovery, and still help the sponsor envision the cost in dollars and resources associated with the features? The answer is simple: ask the sponsor.
If we can deliver the features in the time frame we're speculating upon, what would that be worth to the business? How much is the business prepared to invest to gain these advantages? The response to these questions not only gives the Agile team a framework to live within, but it also has the subliminal benefit of forcing the sponsor to take ownership of the business case, financial expectations, and resource limitations.
Every IT professional has banged up against the sponsor who, at every juncture, wants to remind us that "you said it would cost X!". Now we set up the relationship that that the sponsor is telling us the number they imagine. There's no guarantee we can deliver within that investment or timeframe, but we can make sure the sponsor understands that business case justification is their job, and ours is to apply the expertise and creativity to deliver the results.