The Problem to be Solved

As of today, many companies are in the process of moving their IT solution management from the more traditional demand-supply model to the more modern product organizational model.

Requirements are no longer handed over between business departments and the central IT department; people from both line organizations move together into a work organization in the middle, centered around digital products, which are managed in close collaboration.

Business takes over the lead for the direction of the product (sending the product owner role to the product team in question) and IT contributes the necessary tech skills.

Such an organization is no longer one traditional reporting hierarchy; it now has two dimensions (the line organization and the work organization), which fulfill different purposes and which are both necessary to manage a complex portfolio of interdependent digital products.

The line organization cares for providing the right people with the right skills, who take over standardized roles in the work organization, sets quality & tools-of-the-trade standards and also enables the further development of the people in their respective roles.

Such line organizations are often called chapter organizations (a term which was originally coined by Spotify) and are organized by roles and skills (e.g. Java Development Chapter, DevOps Chapter, Quality Assurance Chapter, etc.).

The work organization is often organized around the model of the business domain map, which is a structure consisting of horizontal lanes (usually representing core business process chains like Sales, Purchasing, Logistics etc), domains inside of the lanes (representing business capability clusters like Category Management, Warehouse Management, etc) and finally products (implementing a concrete set of related business capabilities with the help of one or more applications).

All of the three levels (lanes, domains and products) usually derive an individual strategy from the overall business strategy, define concrete goals and finally create and execute a business roadmap, which is essentially a set of concrete things to implement usually in multiple time slices of a years quarters.

The overall processes in the work organization are considered lean and agile (output-oriented), everything is done in small increments and uncertainty is not an enemy (things can change often, whenever new knowledge and insights are gained).

In general, the work organization strives to be a high performance organization, borrowing principles of lean and agile management.

The Challenges

When setting up such a modern product organization, a couple of transformational challenges are being faced.

Usually internal systems (e.g. orgcharts) do not deal well with a multi-dimensional organization; so the new structures are visualized with traditional office tools (e.g. presentation slides or spreadsheets), quickly creating the usual problem of multiple versions, fuzzy data models and unconnectedness (the different dimensions are not related to each other).

As soon as a couple of product teams are launched, the challenge of the roadmap management approaches; traditional tools which are good for structured ticketing in the individual product teams (e.g. Atlassian Jira) have added roadmap planning as an afterthought and are way too complex to setup for an organization which just started to learn this new way of working.

Often different teams started to self-organize differently and bringing together all of this in a roadmap planning places unnecessary constraints on the way-of-working of the individual teams.

To compensate for this, companies usually introduce an additional tool which is focused on board collaboration (e.g. Miro).

These tools simulate the pinning of colorful sticky papers on a large wall to visualize the planning process.

These tools naturally have limitations; one of them is for example the graphical nature of the approach; planning board containers are not large enough for just two additional stickies; resizing will influence the entire layout and soon enough just arranging the cards in a meaningful order and dealing with disruptive changes will eat up more and more of your time.

This is not flow; agile is meant to place more focus on content and less focus on organizational overhead.

There are many more pitfalls usually encountered, which are too numerous to list here but you get the hang of it.

All of these experiences during multiple product-organization-related large scale transformation projects have lead to the creation of several releases of a supplementary meta tool, which can ease some of the challenges encountered.

The latest incarnation is called Zingoolarity and has a subtitle of:

A super-simple and cost-free web application to manage many aspects of your product organization and optionally the roadmaps of your teams.

You will learn more about this free and open source app in the upcoming chapter "The Zingoolarity App".

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.

The Zingoolarity App

The Zingoolarity app (whose name is an artificial synonym for singularity, the place where everything comes together in one point due to gravity), is in essence a standalone web service, which can be run on any cloud and needs only a MariaDB or MySQL database as a dependency (to store the data in a structured way).

It is written in Go and is provided under an open source license without any cost involved.

It utilities pure Go and its libraries, HTML and a little bit of Javascript, avoiding the use of complex and heavy weight frameworks.

This is because one of one major design goal: Responsiveness (Response is instantaneous).

Therefore the GUI is clean and simple ... not "fancy".

The Zingoolarity app implements the following objects:

Users

Zingoolarity allows you to maintain users, which can login, use the Zingoolarity app and logoff again (or stay in login state, which your browser automatically remembers).
Users can be either created by an admin and be auto-informed of their new account by email, or they can self-register by providing their name, email address and their details.
Self-registered users are disabled by default and need to be activated by an admin of your Zingoolarity installation.
Existing users can also recover their account information by providing their email address (initially or in case they misplaced the necessary login information).
Zingoolarity does not operate with usernames+passwords; each user receives a 32 character long personal secret certificate by email, which can be used to login and which is automatically remembered by your browser.
If a user suspects that his or her account has been compromized, they can recertify their account and thereby create a new random secret certificate (which they can again recover by email).
Users can be normal users (read-only access), editors (write access) or admins (user management + configuration management).

Users also represent resources in the broader context of Zingoolarity (they can take responsibility for roadmap items or become part of a team with a certain role).

Timings

Zingoolarity allows you to maintain timings, which represent slots in a timeline, on different granularity levels.
You can for example create 3 different timelines for the current and the next year, one on years quarter level, one on month level and one on week level.
These timelines are used to place roadmap items on one of the pre-defined timelines and along with the duration attribute, define the planned end of a roadmap item.

Types

Zingoolarity allows you to optionally maintain types, which represent categories of topics.

This helps to establish a certain terminology in your company.

You can for example create the following types ...

• Lane
• Domain
• Product

... to structure your business domain map.
You could also created types like ...

• Unit
• Department
• Team

... to represent the line organization of your company.

By default (to reduce complexity), types are not used (except for the micro-website feature explained at the end of this guide).
You just create topics within topics to model your structures and optionally add types later-on incrementally.

States

Zingoolarity allows you to maintain states, which represent the different states a roadmap item can be in (or the item of a Kanban board).

By default, the following states are available out-of-the-box (which is some kind of best practice collected in different projects with different companies, but feel free to create your own state model):

States are associated with colors.
These colors are a simple instrument for making roadmap, Kanban or context views easily understandable.

Roles

Zingoolarity allows you to maintain a reference list of typical roles needed in your teams.
By default, the following roles are available out-of-the-box (based on a simple model of a product organization, but again, feel free to create your own role model):

Capabilities

Zingoolarity allows you to maintain a list of business capabilities in the structure of a classic business domain map (lane, domain, product), which can be associated initially with any level of your product organization (to assign responsibility in the first step).

The association with a topic represents the reponsibility by a lane, a domain or a product team during the initial build-up phase of your work organization (by definition, there can only be one responsible team).

In the second step, capabilities are intersected with applications and products and assigned a lifecycle state, which lays the foundation for a target architecture map.

Applications

Zingoolarity allows you to maintain a list of applications, which can be associated initially with one responsible person ("owner") and with any level of your product organization (to assign responsibility in the first step).

An application is an architectural building block and can represent a true software application (either a service or something with a user interface), an internal or external service to be delivered (e.g. Governance, Helpdesk, etc), a platform on which other teams can build their applications (e.g. Microsoft Dynamics) or a module inside of a larger platform (e.g. SAP Material Management (MM)).

The association with a topic represents the reponsibility by a lane, a domain or a product team during the initial build-up phase of your work organization (by definition, there can only be one responsible team).

An application also usually has an application owner, who is the main responsible person for the application and works in a product team (and is the ultimate specialist for this application).

Finally, an application can have a direct lifecycle status, from being part of the target architecture up to the end-of-life decommissioned state.

Categories

Categories are an optional way of structuring your applications into different kinds.

Usually there are at least something like business applications, foundation applications (which provide technical building blocks for business applications) and services.

Cycles

Zingoolarity allows you to maintain cycles, which represent the different lifecycle states an application or of a usage of an application to implement a capability.

By default, the following cycles are available out-of-the-box (which is some kind of best practice collected in different projects with different companies, but feel free to create your own cycle model):

Cycles are associated with colors.
These colors are a simple instrument for making your target architecture map easily understandable.

Periods

Zingoolarity allows you to maintain periods for budgeting and cost control.
This is an additional time dimension for managing the commercial aspects of your organizations.

By default, there are two example years available, each containing 12 months.
But again, feel free to create your own budgeting period model.

Forms

Zingoolarity allows you to define forms, which can be used in the context of other objects (at the moment, this is only used by applications).

Forms can represent questionnaires or checklists and are a collection of 1..N input fields (single line, multiple line, select box, etc).

Form definition and data is stored in a unified format (ZML), so that you can evolve and further extend your forms without affecting existing forms first.
The new version of the form can later be applied to all existing forms, when the new version has reached maturity.

In a future version of Zingoolarity, forms will become a standard part of all major objects.

Topics

Topics are the main item in Zingoolarity, which can represent items on a roadmap or a Kanban board, units in an organization and at the same time can optionally contain a bunch of people representing a team associated with the topic.

With this approach, you can have everything from product teams, project teams or chapters which assign their people to products or projects in certain roles.

They could also represent work items or really anything else.

Each topic has a couple of simple attributes:

Actions

Actions in Zingoolarity are taken in the context of a topic.
They represent any activitity performed or relevant information shared by a user for this topic.
An action can optionally contain an attachment (e.g. a concept document), if it cannot be shared by reference (as an URL).
You can understand actions as a chronological list of activities performed to complete the topic.

Teams

Teams in Zingoolarity are assignments of users to a topic in a certain role and with a certain FTE (full time equivalent).
Teams can be assembled for everthing: a line organizational unit, a work organizational unit (e.g. a domain or a product) or a work item (a project, an initiative, an epic etc).

Links

Links in Zingoolarity are relations between topics (in addition to the primary relation of parentship).
Links can represent simple things as dependencies between work items.
But they can also represent the relation between two different maps (e.g. between projects and strategic goals).
Links are always bi-directionally visible (you can view and edit them from both sides of the relation).

Usages

Usages in Zingoolarity represent intersections of business capabilities, technical applications and parts of your product map (usually product teams).
This allows you to map all your existing applications to business capabilities and assign them into the responsibility of product teams.
At the same time you can add different applications in different lifecycle states, so that you can clearly document applications which are currently used and which will be used in the future.
Each intersection has a maturity level and a description, so that you can easily create a structured data pool which automatically visualizes your architecture target map.

Matches

Matches in Zingoolarity represent a special relation between budget topics and invoice topics, additionally specifying the period to which the the relation belongs.
This allows you to establish a dynamic budget control process by creating budgets on whatever organization you deem necessary (e.g. line organization, products or projects).
When you receive a real spending of the budget money (e.g. an invoice from a supplier or a monthly booking salary record of HR), you simply create an additional topic representing this (as one process step) and then matching these spendings to your budgets by mapping them to the correct periods (as a second process step) and setting the amount in currency.
The maps containing the budget will automatically show planned and as-is numbers, which provides a simple but tremendously effective tool to control your cost.

Views (or View Modes)

Views in Zingoolarity are the visualization of topics in various ways.
Based on practical experience, exactly three different views are available (to keep things simple):

• 1. Roadmap
  Visualizing topics on a certain timeline, thus representing a roadmap.
  Topics are represented by bars of different length, mapped on the configured timeline of the parent topic.
  This is the preferred view for roadmap planning and review.
• 2. Kanbanboard
  Visualizing topics in state columns, thus representing a Kanban board.
  Topics are automatically placed into state columns.
  This is the preferred view for to-do lists.
• 3. Contextmap
  Visualizing topics in nested boxes, mapped out horizontally and vertically.
  This is the preferred view for hierarchical structures or orgcharts.

As topics in Zingoolarity can contain other topics, any view in Zingoolarity is drillable by clicking on the name of a topic.

By that, you can for example create a topic Implementation Phase in the context of your project, focus on it and create more topics in the context of the implementation phase, which need to be completed to fully complete the implementation phase.

These sub-roadmaps can have the same timeline as the roadmap above, or they can have a different start and end, or they can even have a different timeline level (thus making it possible to drill from a monthly roadmap to a weekly sub-roadmap).

In Roadmap and Kanban view, topics on a map, which do not have a timing (yet), are automatically shown in the left-most column (undefined), which can be seen as a kind of backlog.

These three views are essential in Zingoolarity.
Everything is created and edited in the context of a view.
You can easily navigate between the different levels by focusing on items (drill down) or using the breadcrumb on top of the screen, which shows the path up (drill up).
You can even open or close topics to view or hide their content (like a directory in a file browser, but with the individual dynamic formatting of the selected view).

This allows you to nest Kanban boards within Kanban boards, roadmaps within organizational units, dynamically add Kanban boards to roadmap items and much more.

It is one of the key strength of Zingoolarity, to provide this kind of iterative and incremental flexibility.

Summary

The additional summary view of Zingoolarity (which is read-only) allows you to view a topic tree with all relevant information, including the actions for every topic.

This is a good way to provide a status report in a meeting or a call, as it shows the relevant information (assuming you use the actions to log relevant events).

Daily News

Zingoolarity allows every user to optionally subscribe to the daily news.

This is an automatically generated email once per day, which contains all the new actions of that day in all topics.

It can be easily digested to keep up with the progress of your roadmap (assuming you use the actions to log relevant events).

Export

Zingoolarity provides the capability to export and (re-) import all available data objects.

Exports are being performed in ZML format, which is a simplified tag-based format (much like HTML) and which can also be edited with a simple text editor before (re-) importing.

Here is an example of a ZML file containing one role object:

[role]
[id]cpo[/id]
[name]CPO[/name]
[detail]The chief product owner steers the entire product, platform and initiative portfolio.[/detail]
[active]1[/active]
[lead]1[/lead]
[sort]0[/sort]
[/role]

Bookmarks

Zingoolarity allows you to add any number of topics to your personal bookmark list.

This provides quick pick capabilities for your most-used topics (e.g. the projects you work on, your personal workspace, etc).

This is a convenience feature.

Capability Map

Based on the structured list of capabilities, Zingoolarity allows you to automatically generate a business capability map to visualize and support your business process improvement.

It can also automatically show usages, which transforms your business capability map into a target architecture map.