The Roadmap Challenge

If you are a medium to large sized company in the digital tech industry (or want to be like one to be more effective and efficient in your IT solution management), you are likely to run multiple tech teams to build, improve and maintain your digital products, along with overarching initiatives (lightweight projects) which span and impact many of the teams with requirements and dependencies.

As self-organization is a leading paradigm in effective and efficient tech teams, your teams individually choose a way how to organize, plan and track their requirements.

In small companies, you can still get a grip of the state of affairs by just talking to the teams on a regular basis; but as you grow further and more and more structure and specialization starts to become necessary, just talking becomes inefficient and unprecise and you need to formalize the planning and tracking a little bit more to keep transparency (but you still do not want to encumber your teams with more and more bureaucratic overhead and unnecessary standardization).

Many companies dream the dream of a fully interconnected, standardized ticketing system, spanning from the single user story of the team up to the strategic planning in one single system, where you can drill from the strategic goal all the way down to the implementing tasks in the different teams.

So they invest heavily in licenses of famous tracking solutions like e.g. Jira, buy a lot of plugins and additional features for single use cases and try to rollout a uniform way of organizing, standardizing and interconnecting the tickets.

As this is perfectly possible in theory, we have seen many large companies fail in this endeavor.

This is mainly for two reasons:

• The organizational overhead to introduce and uphold such a complex integrated process starts to eat away a large amount of the productivity of your teams (at least during a long period at the beginning).
• The necessary change management to align everybody involved to stick to certain standards when maintaining the tickets (which is required to keep this desired automatic transparency by the press of one button for upper management) is also a complex project in itself and often not invested.
  

So in practical experience, introducing and running such a fully integrated process is often not worth the involved energy, cost and complexity, and many companies who attempted this, rolled back after some time trying (reverting back for example to a roadmap management process with the help of virtual walls of sticky colorful papers, supported by solutions like Miro).

The pragmatic solution to this dilemma is quite simple.

Just let the teams continue to run their individual best practices (and also introduce a culture of best practice sharing, so that teams can benefit from the innovations of other teams and are free in their decision to adopt what helps them the most).

On top of this existing process, establish a completely separate very lightweight process to manage the company roadmap, which makes the company goals transparent to everybody involved and deals with the individual roadmaps of the involved teams and their high level dependencies, which implement these goals.

The individual team roadmap is maintained by the leader of the individual team (usually the product owner) and contains items, which represent desired capabilities or desired target states, which can be easily associated with the company goals.

The breakdown into real work packages and tasks, which often also need to be implemented over multiple teams to provide the full functionality, will be done in the tooling which the individual teams use for their daily work.

Therefore the individual topics on the roadmap typically span multiple weeks or months, whereas the breakdown work packages are managed by Kanban boards or Sprint planning for example in Jira or any other solution the individual teams use.

It cannot be overemphasized enough that this roadmap management process needs to be lightweight and dead simple for everybody to use.

The need to map every detailed technical dependency is simply not there; as soon as teams know and understand that they have a dependency to each other, they start managing the intricate details of these dependencies themselves (assuming you created the self-organizing culture for this).

Therefore many companies establish this process in a more traditional way (e.g. big yellow stickies on a wall, as long as the responsible team leads can come together in one physical room on a regular basis) or they implement this with a different tooling (e.g. Miro).

Why is this?

Using the established tools like Jira again introduces unnecessary complexities, as they are made for a special problem, have lots of features and need a lot of workarounds, customization or custom development to make your lightweight process really simple and usable by everybody.

For example using the Jira enterprise feature for roadmap planning requires to pull-in tickets from the existing ticket pool of all involved teams, which are often incompatible regarding granularity, state and way of handling.

The tickets are planned by default with exact dates, which makes it much more difficult to easily plan in week cycles.

Tickets do not provide an easily viewable multilevel hierarchy on the timeline.

Sure, you can develop all of this on top of Jira, but it is complex, needs certain specialized skills, is expensive to build and maintain and is not portable to companies not using Jira.

That is why we added this to Zingoolarity:

The lightweight roadmap management process.

It mostly boiled down to the Roadmap view mode of Zingoolarity, which is explained further down in this getting started guide.