Denkplan © – The roadmap step

A physical wall

We urgently recommend a physical wall for the roadmap step. For sure, an electronic representation must be available as well any time in the future in any tool like Jira or TargetProcess. Nevertheless the core activities of conversation and decisions create most value as conversation in front of the physical roadmap wall bound in a ceremony of events in a regular cadence.

In the previous step working with the impact map we identified strategic themes. In the roadmap step we figure out how to develop these themes towards our vision in small steps (experiments?). What we do is pinning the themes on the wall as headers of columns from left to right. The order from left to right depends on the themes. Ideally the order represents in some sections the values stream(s) of your company. The time runs from top to down. The image below shows the schema. The blue post-its in the header line represent the identified themes, the yellow post-its represent the steps to develop a theme over time.

Evolution of the ecosystem in small steps

We use the term initiative for a single step, as we take a sequence of initiatives to develop the theme to the next level, creating value for customers and the company. If you think in the SAFe terminology, an initiative is similar to a business or enabler epic, in smaller companies it might be similar to a feature. In our experience in practice it is important that the initiatives have comparable lead times, i.e. the variance of the lead time ideally is small.

In fact the roadmap is a company wide story map following the story mapping ideas of Jeff Patton. Themes represent the “development backbone” of our company. Attention: the term development stands for business and corporate development, not for IT only. The roadmap helps us to develop our company as the original Jeff Patton story map helps us to develop a product or service.

The portfolio roadmap is a storymap of the company

Question is: where do the yellow post-its, the initiatives, to develop a theme come from?

Good practices for small evolution steps

I cannot say what the concrete action and outcome of a single initiative is. There are good practices how to design or shape a single step as following:

• An initiative delivers a business value. This is a good point to discuss and find a definition what business value is in your company. Hopefully it is customer oriented (delight your customer) and not only inter-company oriented (cost saving and efficiency). I discussed a business value based WSJF prioritization in two previous blogs (intro and example for calculating cost of delay)
• We recommend that each initiative has a short lead time and the variance of the lead time is small. What short is, depends on the ecosystem your company is part of. Small companies in a fast moving market (example: e-commerce) do have shorter lead times than big companies und regulated markets (example: pharmaceutical companies).
• Ideally an initiative is autonomous. An initiative is autonomous when one to three (agile, multi-disciplinary) team(s) can develop the initiative with minimal dependencies to other teams.
• The goals and the desired outcome of initiative are concrete and SMART.

Heading for the shortest possible lead time is essential

If a company is impossible to identify initiatives with a short lead time, Denkplan is most probably not the appropriate approach for this company. I guess such a type of company is not agile or acts within a non-agile ecosystem. Examples might be a railway infrastructure company or a pharmaceutical company in strict regulated areas. In our experience a reasonable lead time for an average company offering digital services to customers is between two and six months.

The Denkplan approach is to develop each theme as a subsequent flow of initiatives with a lead time of two to six months. More than one initiative in parallel per theme is valid – depending on the development power (number of multi-disciplinary teams) of the company. Too many initiatives in parallel violate most probably an WIP (work in progess) limit. We come to that later.

The outcome of an initiative could be totally different: Adding a new feature to an existing customer service; development an MVP for a new product following a lean startup approach; a logistic concept for a new supply chain management approach as enabler to scale the business; building a new flagship store on a top location; the reorganization of a department; a marketing campaign. Remind yourself: the roadmap reflects the development of the company in all aspects.

Why is lead time important and not effort? The goal of the roadmap is the tactical planning of the strategy implementation while being flexible. Flexibility means that we can introduce changes fast without losing a lot of valuable work already done. If we develop a theme in small (two to six months) initiatives and discover that we must stop one single initiative (whatever might be the cause) we do not lose a lot of work, as all previous initiatives in this theme created business value.

While we develop the initiatives for each theme, more and more initiatives will be pinned to the roadmap wall. The initiatives for today are concrete, following initiative proposals are less concrete and the ones at the bottom of the roadmap are probably not more than ideas or fuzzy wishes. This follows the lean ideas to invest effort in time and to prevent upfront work on “stock”.

Prioritization by business value

Now it is time to order the initiatives. This is the point in time to prioritize, to identify cross-theme dependencies and to reflect against capacity from a high-level view. We observed the following ordering good practices:

• Business value: We always want to maximize business value. We strive to deliver always the initiatives delivering currently the highest business value. These initiatives shall be moved to the top.
• Initiatives do have dependencies across themes. If initiative A (in theme X) must be done before initiative B (in theme Y), B will be placed below A, i.e. B can start when A is done.
• Capacity and feasibility: If we identify capacity conflicts, we must decide how to solve this conflict. In an agile and lean world teams pull initiatives in the order as represented in this roadmap.

A team shall not work on many initiatives in parallel. Ideally – with one-piece flow in mind – a team works only on one initiative at every point in time. We identified this is not realistic as in real world. Waiting times exist because of external or (worse – that is an impediment) internal influences. We discovered working on two initiatives in parallel is achievable. In this case the waiting time can be used to work on the in priority following initiative. So, the goal for ordering is: no team and ideally no person shall invest substantial effort into more than two initiatives in parallel. If we identify this, one or the other initiative must be moved down or up. If this is a recurring situation, we have an impediment to address.

Acting like this we develop a tactical actionable idea how to develop the themes – initiative by initiative. The number of teams restricts how many initiatives are “in work” in parallel. Ideally teams pull the next top ranked initiative. As we develop the initiatives, we receive feedback about impediments, changes, demands; as well external as internal. Based on this feedback we have to re-arrange the roadmap in a regular cadence. As in Scrum there is a planning meeting for the roadmap. Interesting questions: Who participates and what is the cadence. I apologize, but I move this discussion to a later blog…

The result working with the roadmap might look like this:

Am example of a portfolio roadmap

There might be gaps in the development of a theme. In this case either we are happy with the theme as it is and add new things later on; or we had to move down initiatives because of dependency or capacity restrictions.

The roadmap establishes flow

Typically, the upper third of the roadmap represents initiatives we are currently working on, the next third represent initiatives that most probably will be pulled for work when current ones are done; and the bottom of this roadmap represents vague ideas of future development as least giving hints what we might do and what capacity then will be required to succeed.

Typically as well the upper two third of the initiatives are managed and documented in some kind of tool, for example in Jira, TFS, VisionOne or Trello. This help to add all additional information following typical agile ideas of documentation (see my blogs about agile documentation and repositories)

Not bad, or?

It is living, visual, invites to lead conversations, is an instrument for (sometimes hard) decisions and for synchronization, it is holistic and represents the complete company, it is tangible and far away from two hundred PowerPoint slides hidden in any shared folder. What to say – most of the companies that experimented with that type of roadmap really like this instrument for tactical strategy implementation.

Denkplan © and the concepts behind is a registered trademark of DoD!fferent GmbH, Saraes Media GmbH and Juropera GmbH.