Example: Product-line technical debt over 2 years

A 90-node strategic tree, built in one planning cycle and updated in the next.

Context

A software organization sold a product line of operations software, installed at each customer's site. Over the years, the product line had built up technical debt of many kinds: deployments that were different for every customer, gaps in test coverage, a tightly coupled architecture, slow development, and a growing support burden. Customer confidence was suffering.

These problems were not separate. Each one made others worse, and together they stood between the organization and what it wanted from the business.

Goal

Connect the technical debt of the whole product line to the business outcomes it was holding back, in one picture, to inform strategy over several years.

The outcomes on the tree are business goals: a better customer NPS, a better uptime SLA than competitors, more customers on the core product, and more sales of an add-on product.

How the tree was built

The tree was built in a digital diagramming tool, as one full tree on a single page. It was built in one planning cycle and brought back, updated, in a later one. The 2 versions are called the first year and the second year here.

• Dozens of root / problem nodes run in chains toward the desired state / outcome nodes. There are very few plain actions.
• The legend names "half-way problems": states that are partly a problem and partly progress, such as "Faster deployment process in production." They play the role of action / intervention nodes.
• Artifacts sit next to what they relate to. Artifact / deliverable nodes are specific technical deliverables: an automated deployment, a shared logging library, an architecture model. Many are placed beside the problem they are meant to resolve.
• Shapes mean nothing. The tree mixes rectangles and sticky notes because the way of adding nodes changed along the way. Everyone read them as the same thing. See colors and shapes.

Besides the full tree, the document had a page for a blocked outcomes view. It lists every outcome with the 2 to 5 problems that block it.

The tree

In its second year, the tree has about 90 nodes and 100 arrows. This excerpt shows 14 of them.

Read the left column from the bottom. Every deployment needs its own customized steps, so every deployment is different, so nobody can test all the variations, so deployment issues are found for the first time in production. Each node on its own was well known. The chain was surfaced by the exercise and discussion facilitated by the tree.

From the first year to the second

The second-year tree also has a parking lot, a frame for nodes that do not fit yet.

What it revealed

• Technical problems reach business outcomes. A customized deployment step is a long way from customer NPS. The tree shows the path between them, one arrow at a time.
• Most of the first year's problems are still on the tree in the second year. That says as much about the nature of the problems as about the work done in between.
• The first-year legend has no attacks relationship. It appeared in the second year, once artifacts sat in the full tree next to the problems they target.
• Artifacts were first organized in a tree of their own. That was abandoned, and the artifacts moved into the full tree. The old page was kept, clearly marked, as part of the tree's history.

Lessons

• Clustering keeps a large tree readable. About 90 nodes on one page is the largest tree observed so far that stayed usable. It stayed usable because related nodes sit together in frames. See runaway scale.
• A complete legend lets the tree speak for itself. This tree can be read by someone who was not there when it was built, because its legend names every node type and arrow style in use.
• Removal needs attention. Very few nodes left the tree between versions. Some problems truly persisted. Others may have stayed because nobody asked whether they were still true. Make that question a step of every update. See a living document.
• Let the notation grow from need. Add a relationship when the group keeps reaching for it, not in advance, and update the legend when it happens.
• Mark dead ends instead of deleting them. A page marked frozen and obsolete tells the next reader that the idea was tried, and saves them from trying it again.
• Some nodes stay ambiguous. "Faster deployment process in production" reads as an outcome or as an implied action. That is acceptable. What matters is the balance of the whole tree.