Rolling wave planning compromise.
February 14, 2008
David @ 37signals is saying, You do not need a product road map:
It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see.
John @ SplicedNetworks is saying, Goodbye Roadmap:
The concept of a roadmap has been thrown out, replaced with list of initial functional features . These features are currently in development, and will be the initial AppOS 4.0 release. AppOS 4.0 won’t be the bells and whistles release initially, instead it will be functional. Features will be expanded and added based on customer feedback , as well as our own use of the product.
These are agile companies talking. I support this concept and I am pretty sure they know what they are talking about. Our backlog is our idea of a road map, it is telling us what could be coming in the future releases (most probably the higher priority items) although you can not really say when exactly and in which order. One or two iterations ahead the situation is much clearer but beyond that not really, it is all driven by the changing market requirements.
But then, even scrum masters keep bringing up the concept of the rolling wave planning, which basically means: lets still try to maintain our road map and long term release plans, even though we’re agile. Isn’t that somewhat contradictory to the iterative “agile” concept which tells you that it does not make much sense to predict that far ahead?
I think Jerry Manas expressed it very well in his comment to Forced Into ‘Agile’:
But even in the Defense Industry, Rolling Wave scheduling is becoming the norm, where each horizon is planned at a more granular level as it approaches (although the whole project is laid out up front at a higher level). I look at Rolling Wave as a hybrid between Agile and BDUF (and it’s appropriate for most projects most of the time).
So is the rolling wave a vehicle for transition to agile or a means to keep your business/management/VC folks happy (by giving them a plan that wont survive the reality)? What is your take on this issue? Do you create product road maps in your agile environment? Do you use the rolling wave concept? How practical is that? It would be very curious to learn.
Our product Yoxel Agile Product Management is quite straight forward in this sense. You’ve got your backlog and your iterations, which we also call incremental releases, because for us those are the same (~1month: implementation+testing). No rolling wave with long term release plans and even longer term road map plans. You can start planning next iteration while you’re implementing/testing one and so you will have a good idea for what is coming in a month or two but beyond that your best bet is the prioritized baclkog :).
Cheers!
One Yoxel 
February 14, 2008 at 12:59 pm
While I agree that roadmaps may not be as effective as other methods – especially with the adoption of agile practices, they are still necessary. They can’t be ignored.
The reason, as you point out in your post, is that some people can’t get past how they are used to software being built. You have many people, in important positions, who refuse to see things any other way.
And you certainly can’t say, “no, I won’t take that 10M in funding that I need to start / keep my business, because roadmaps are obsolete.” You’re creating that roadmap.
My main thinking here is with VCs and senior management that refuse to see things any other way. The reality is, stubborn people refuse to accept software development any other way than, “we create a roadmap, we create a schedule, you hit all of your dates, you release an alpha, you release a beta, and then you ‘ship’.”
It is a load of crap that software works BEST this way, or that this is the only way. I can point to many specific examples in my career where if dates weren’t the deciding factor in product launches, or a “beta” was released because “that’s how things are done,” or some other archaic reason, the product would be WAY better off.
But, such is life. I happen to find roadmaps useful for getting big picture. Will they change? Yes. But do you need direction and focus? Also yes. You can’t get a good 2 or 3 quarter product overview from backlog lists of hundreds (or thousands) of features / bugs. I find constantly evolving theme-based roadmaps the best way to achieve that.
February 14, 2008 at 3:36 pm
Hi Adam, thanks for the eleborate comment.
My experience with VC funded companies is the same: have to to build a roadmap; have to show alpha, beta, …; have to deliver on time …; have to maximazi quaterly revenue. Actually most of the marketing books teach you the same: have to have a vision and a long term roadmap (on a vision I do not disagree at all although usually even that changes or adjusts quite a bit as you start getting your regular customer feedback).
Does it mean this roadmap business basically a broken means of connecting your software building reality with VC money and VC influenced management goals? I wonder if there is a better way. Or, as you said “such is life”. I guess ideally it would be nice to be able to run a business without any VC money :).
As for the backlog of thousand features, I agree, it may get overwhelming but the main features that define your direction are usually already in it, right? If you mark those as your main themes (backlog management tools should probably help here), they would be your milestones or potentially alternative directions.
How you pick which milestone to focus on or which direction to follow is another big topic. Business value, ROI, … Most VC backed up companies probably choose the order of the milestones that result in immediate revenue. Theme focused iterations seem to be more than enough for me. Oh, yes, almost forgot, the VCs … they want the roadmap so we have to find a compromise, hence the rolling wave.
February 15, 2008 at 6:50 am
Just like sales people who are thinking one deal ahead, the agile product team is focused on one or two iterations ahead. But where are we going? Some products, one assumes, are completely driven by feature ideas from the customer base and what started as ‘x’ ultimately becomes ‘y’. But more often, having ONLY short-term thinking creates the swiss army knife which is really not a very good knife. Developing to a laundry list of features without strategy satisfies no one.
The roadmap is the favored method of illustrating a strategy. I agree with 37signals; a roadmap shouldn’t be a tool to get people to buy but a roadmap is a good tool to think beyond the current list of features.
Shouldn’t someone be thinking ahead?
February 15, 2008 at 10:34 am
Steve, it is hard to disagree with your last statement about thinking ahead.
What people call a “product road map” is usually a document that lists your long term milestones in certain order and assigns dates to those, right? And what I do not like is that certain order and the dates:
– People start using it as your master plan and fight a natural change which is inevitable (the dates are usually artificial anyway)
– Sales start setting certain customer expectations and quite often simply selling this when they get the dates.
One should be really careful publishing such a document. What I think a better document could be is just a couple of immediate milestones (your next 1 or 2 agile iterations) with dates and then just a list of likely milestones that you would like to tackle next but can not know for sure neither the exact order or the dates. This defines your direction, and thinking ahead.
I liked the comments by Mark Gladding, to the original 37signal’s post:
“Instead of publishing a roadmap I’ve published a Product Vision. This simply states a set of design goals that were used during development and a pledge to refine the product over time to better meet these goals.”
I believe that is the way to go.
It is quite ironic but even your vision will probably be changing over time :). Just think of Nokia that started as a manufacturer of rubber boots and tires. Their vision was quite different then, I am pretty sure. I would like to see their roadmap from that time to see if it mentions a cell phone.
May 8, 2008 at 5:01 am
This is an amazing discussion. What about using scenarios of alternate future states of your product that reflect customer needs in a heuristic way? We do Web2.0 PR and use scenario planning extensively to keep our cleints and thier customers focused on key issues that make products market leaders and interesting to the media. We will be covering this issue in our blog http://prmeasure.blogware.com.
May 8, 2008 at 9:53 am
I guess you always have those scenarios of alternate future states. That is why you use market research, customer feedback eventually prioritization to decide which one to actually implement.
Again, I am coming from more technical software dev. and product management background so may be I am missing something here.
Can you please elaborate, what do you mean by “reflecting customer needs in a heuristic way”? Is that basically figuring out weight factors that define the final priorities?