Does “agile” complicate your roadmap management process?
July 3, 2007
Have you ever noticed that the two concepts “agile methodology” and “accurate product roadmap” do not co-exist very well together? Here is what I have heard a few times already from folks doing “agile”:
One of the challenges we have is writing a roadmap. We know what should be in there for the future, but getting timing information is difficult because with Scrum, it appears we are not able to set dates (and expectations) with any level of accuracy.
The perception is such that with “agile” it is difficult to manage an accurate long-term roadmap (6months-1year). As if it was easy before, with “waterfall”! Reality is that with a waterfall methodology it was easy to create a spreadsheet with all those long term commitments and milestones but, were you able to actually deliver exactly on those dates? Most probably you were not hitting the dates accurately at all.
SCRUM or any other agile methodology reflects the reality better (every next month your priorities/requirements may significantly change), you can only have more or less precise timing information for the items planned in your current and the immediately following iteration. Not 6-12months ahead.
I believe doing accurate long range roadmaps is a challenge in general, regardless whether it is an agile framework or not. Agile actually keeps you in check. In an agile framework getting the roadmap and approximate dates can be done relatively easily based on your backlog and knowledge of your team velocity, but how about giving your customers commitment dates and making sure you are not over-committing, meaning that what you have committed will fit into your specific Nth iteration cycle later, as you expect?
The task of not over-committing, I believe, could be solved if all product managers (people in charge of committing) in your team use one centralized system that knows the development team velocity, knows all previously committed requests, and based on that, estimates the next available commit date for a task of certain effort. So you get a commitment date for your customer only based on this process, when it satisfies your schedule of iterations and previous commitments. Or if the date does not work for your customer, the system suggests to you what other previously committed requests you could try re-negotiating with your other customers to free up some time slots in the earlier iterations.
What are your thoughts on this?