Process to Agile Roadmap

> On Product Management level, they’ve gathered all the features (of every
> modules) and creates a prioritised backlog which is the yearly company roadmap.
>
> Because your company wants to upfront communicate to your customers
> what is coming when, there is a necessity to know how many features can
> go into Q1, 2, 3 and 4.
>
> Your company currently has 1 scrum team with a steady velocity.
> What are the steps that needs to be taken to come up with a stable roadmap?

Who are these Product Managers? It doesn't sound like they are Scrum Product Owners, because they appear to be serving a "yearly company roadmap" rather than customer interests. In fact they seem to be more keen on "telling" customers rather than listening and responding.

Roadmaps aren't stable unless requirements and market behaviors are predictable. That's rarely the case. So instead of trying to come up with a stable roadmap, it might be better to challenge the predictive and didactic behaviors being exhibited here. Rather than telling the customers what is coming up several releases ahead, promote a leaner pull system of small batches.

Customers can't be relied on to predict what they want or will purchase. Hence, in agile practice, the timely and incremental flow of value to meet demand is encouraged. If roadmaps are in force, the planning horizon should be reduced. This can be a gradual process but it nonetheless requires commitment at a strategic level.

Who are these Product Managers? It doesn't sound like they are Scrum Product Owners, because they appear to be serving a "yearly company roadmap" rather than customer interests. In fact they seem to be more keen on "telling" customers rather than listening and responding.

RIght on the spot. 1. They aren't Product Owners. They are roadmap-driven Product Managers. They usually come up with a verb or if we're lucky an one-liner. After that it's up to the team (plus Product Owner) to translate this vague feature into relevant PBI. 2. They are indeed "telling" customers rather than listening and responding. The company has the feeling that they already know what customers want.

Roadmaps aren't stable unless requirements and market behaviors are predictable. That's rarely the case. So instead of trying to come up with a stable roadmap, it might be better to challenge the predictive and didactic behaviors being exhibited here. Rather than telling the customers what is coming up several releases ahead, promote a leaner pull system of small batches.

Can you give me an concrete example of a leaner pull system?
Should I see this as some sort of Roadmap Backlog with no dates? Purely prioritized items?
I've suggested this in the beginning, but the CEO's responds was "the market is killing, so we need to be able to tell our clients what and when it is roughly coming. Doesn't need to be precise, but in terms of Q1, 2, 3, 4.

Customers can't be relied on to predict what they want or will purchase. Hence, in agile practice, the timely and incremental flow of value to meet demand is encouraged. If roadmaps are in force, the planning horizon should be reduced. This can be a gradual process but it nonetheless requires commitment at a strategic level.

I don't fully understand what you mean here. Please explain..

> Can you give me an concrete example of a leaner pull system?

The canonical example is probably IMVU. Here is the case study: http://iacis.org/iis/2010/635-639_LV2010_1497.pdf.

I wrote an article on pull systems a couple of months ago: http://java.dzone.com/articles/pull-practice-0

> Should I see this as some sort of Roadmap Backlog with no
> dates? Purely prioritized items?

Essentially yes. Hard dates can exist in a problem domain (e.g. the start of an academic or tax year) but these should be the exception and not the rule.

> I don't fully understand what you mean here. Please explain.

Customers can't be relied on to know what they want. The further ahead you try and anticipate what they want, the greater the risk becomes of not meeting emergent requirements in a timely manner, and of work being wasted. The more long-term the roadmap tries to be, the bigger that window of exposure to risk becomes.

As you've seen, getting prioritized requirements is hard and it can involve a major cultural shift. The organization's strategy has to become one of responding to emergent needs, and minimizing the waste that comes from long term planning. Truly lean organizations are able to build MVP's that are barely sufficient to validate assumptions about what might be needed. If validated, then further work can be done...if not, then losses can be cut and the organization can pivot to a different MVP.

Essentially yes. Hard dates can exist in a problem domain (e.g. the start of an academic or tax year) but these should be the exception and not the rule.

I think for me the 2 most important questions would be:
1. What arguments can be used to convince management that we need to let go of upfront roadmap planning and start thinking of working in priorities? I know for a fact that my company is very marketing-driven. They need to set up deadlines so that their customers knows what features are in the pipeline.
2. What arguments can be used towards our customers. Our customers uses our product (some of them as white label) to set up their own business. For them it's very important to beforehand know what is in the pipeline. Which important feature is coming out when. That's a bit of the culture of this company.

Does your company face much competition in its market? It sounds as though customers just get what they're given. Or are you mainly serving resellers, e.g. of "white product"?

Reselling extends the feedback loop from end customers, so the response to demand and changing requirements can become attenuated. It can also buffer the risks I referred to.

Posted By Ian Mitchell on 10 May 2014 04:29 AM
Does your company face much competition in its market? It sounds as though customers just get what they're given. Or are you mainly serving resellers, e.g. of "white product"?

Yes, my company faces much competition in its market. I'm not proud to say that our Research & Procurement division comes up with the features they THINK the customer will want. So yes, basically we are telling the customers what they want. I've had many discussions with management regarding this way of working and it's not going to change. (no point in changing that part) So seeing that that is a given fact, we now have a backlog (which is our roadmap) that is priorities with high level features. (for the team these are epics and bigger)
Our product is being used by wholesalers/dealers and they are reselling it.

What I've suggest now is the following:

1. We have our super high level backlog. This backlog consists of large epics, really large! Can also be seen as a project if you ask me. This backlog is actually a Kanban board.

2. The Roadmap backlog is prioritised.

3. Because its the first time we do this we dont have any historical data so its a big guessing how much can go into a quarter etc.

4. Once every 3 months Business and IT sits together where the Business place Value to the items, IT place they relative guestimate.

5. My idea is to built up historical data for next year and hopefully we can say something like... Ok the Roadmap velocity (which is of course NOT the teams velocity) is x points so we are able to take x amount of points into a quater.

Does this sounds like a good approach?

I'd say that sounds like a *better* approach. Your super high-level Kanban board represents a portfolio view for management, and this is a strategic approach that has improved things for others in broadly similar situations. The metrics are beneficial. It could be a good first step.

What it doesn't do though is to tighten iterative-incremental feedback loops as far as possible. It sounds as though your company is a degree removed from the majority of end users of the product, because it uses resellers and wholesalers. This limits the ability of your company to receive timely feedback about market needs, so it takes a prescriptive approach instead, and attempts to formulate a roadmap for its product.

You said you want arguments you can present not only to company management but also to customers as well. I think that's an important point. Your company only represents part of the value stream because resellers are also involved. It's therefore the whole value stream that has to become leaner and more pull-driven, and not just your company.

In a competitive market, few manufacturers will stay in business for long if they think they can just tell dealers what is coming down the pipeline. They need to work with the dealers and the consumers to identify actual market needs, and to respond to those needs, in terms of quality and quantity of product, on a just-in-time basis. That's how top car manufacturers have been able to lean out their value streams and stay in business.

Failure to do this will presumably leave your company vulnerable to disruptive innovation by competitors. In other words, competitors will eventually find ways to respond to emergent requirements in leaner and more just-in-time ways, and with less waste being incurred. They'll master their value streams so that their feedback loops are tighter. Their roadmaps will be less prescriptive, and more geared towards emergence and learning about what customers need.

Perhaps if you highlight the risks that disruptive innovation can present to market-inefficient value streams, you might find an ear that will listen.

Posted By Ian Mitchell on 10 May 2014 03:01 PM
I'd say that sounds like a *better* approach. Your super high-level Kanban board represents a portfolio view for management, and this is a strategic approach that has improved things for others in broadly similar situations. The metrics are beneficial. It could be a good first step.

What it doesn't do though is to tighten iterative-incremental feedback loops as far as possible. It sounds as though your company is a degree removed from the majority of end users of the product, because it uses resellers and wholesalers. This limits the ability of your company to receive timely feedback about market needs, so it takes a prescriptive approach instead, and attempts to formulate a roadmap for its product.

You said you want arguments you can present not only to company management but also to customers as well. I think that's an important point. Your company only represents part of the value stream because resellers are also involved. It's therefore the whole value stream that has to become leaner and more pull-driven, and not just your company.

In a competitive market, few manufacturers will stay in business for long if they think they can just tell dealers what is coming down the pipeline. They need to work with the dealers and the consumers to identify actual market needs, and to respond to those needs, in terms of quality and quantity of product, on a just-in-time basis. That's how top car manufacturers have been able to lean out their value streams and stay in business.

Failure to do this will presumably leave your company vulnerable to disruptive innovation by competitors. In other words, competitors will eventually find ways to respond to emergent requirements in leaner and more just-in-time ways, and with less waste being incurred. They'll master their value streams so that their feedback loops are tighter. Their roadmaps will be less prescriptive, and more geared towards emergence and learning about what customers need.

Perhaps if you highlight the risks that disruptive innovation can present to market-inefficient value streams, you might find an ear that will listen.

What I have managed so far is that the management are slowly accepting that development work is equal to research and development. Therefore it will always be a unpredictable forecast. So in a way I think management has recognized that the roadmap isn’t fixed.
I understand the pull-system, but I have a bit of trouble understanding how this can be applied in our situation.
Are you suggesting that we drop the entire roadmap and purely do it “on-demand”. In other words, pull in work when there is “room”?
If yes, how can this be explained towards wholesalers, dealers, end users etc. whom are relying on “what will be developed this year”.

> Are you suggesting that we drop the entire roadmap and purely do it
> “on-demand”. In other words, pull in work when there is “room”?

In theory that's what should happen, because in order for a genuine agile transformation to succeed it must apply across the whole value stream. This requires strong executive sponsorship not only in your company but also with the wholesalers, dealers etc.

> how can this be explained towards wholesalers, dealers, end users
> etc. whom are relying on “what will be developed this year”.

By focusing on the identification and elimination of waste across the chain. The first step would be to get transparency on this before any concrete moves are taken. Once waste become visible it is easier to get buy-in for removing it. Waste includes a slow response to changing market conditions, building the wrong thing and not finding out in a timely fashion, rework, the batching of defects for future resolution, and so on.

Even so, that's a very tall order and value stream optimization remains hard to put into practice. The cultural shift is enormous and strategic. Sometimes the best you can do isn't to scrap the roadmap, but rather just to gradually shrink it. The key to this is making sure release feedback is taken seriously and factored into the roadmap as soon as possible. It then becomes clearer to stakeholders that planning outside of the feedback loop is largely wasteful, and that it is better to have a validated learning strategy instead.

In theory that's what should happen, because in order for a genuine agile transformation to succeed it must apply across the whole value stream. This requires strong executive sponsorship not only in your company but also with the wholesalers, dealers etc.

I think my company is still in the phase of being stubborn. We’ve hired a couple of Product Managers and heavily relying on them to tell us what the wholesalers, dealers and end users wants.
Our client base is extremely large and complicated. Plus we try to set up a very generic web application. If 1 feature is introduced EVERYONE will have access to this functionality. (of course this can be manually excluded for others)

Even so, that's a very tall order and value stream optimization remains hard to put into practice. The cultural shift is enormous and strategic. Sometimes the best you can do isn't to scrap the roadmap, but rather just to gradually shrink it.

Perhaps this is the best way indeed. Removing the roadmap would be too big of a step and too confrontating I guess.

The key to this is making sure release feedback is taken seriously and factored into the roadmap as soon as possible. It then becomes clearer to stakeholders that planning outside of the feedback loop is largely wasteful, and that it is better to have a validated learning strategy instead.

What I mentioned earlier? Like establishing some sort Roadmap Velocity so that we can guess how much work can be "pulled" in the quarter? The twist would be that every time we do a project release, feedback needs to be received

> The twist would be that every time we do a project release, feedback needs to be received

That's right, you need feedback so a course can be set and subsequently adjusted. Velocity should be understood not only in terms of speed but also direction.

Posted By Ian Mitchell on 13 May 2014 10:09 AM
> The twist would be that every time we do a project release, feedback needs to be received

That's right, you need feedback so a course can be set and subsequently adjusted. Velocity should be understood not only in terms of speed but also direction.

Thanks for your inside on setting up Agile Roadmaps.