← all posts

Ice Floes and Hexagons: Visualizing Complex Work

Most process visualizations pretend work is linear. Here's a model that doesn't — inspired by Cynefin, The Art of Agile Development, and a children's tv show.

This is a model I’ve been thinking about for a while. Not a framework. A tool for teams to think with.


There’s an “action” game in the old Tabaluga TV show — a set of children has to cross a frozen lake by jumping from ice floe to ice floe. The floes are connected. Some are stable, some are shaky, some you have to skip entirely to find a better path. The structure of the lake is always there. But the path across it is yours to discover.

I keep coming back to this image when I think about how teams actually work in complex domains.


The problem with process diagrams

Most process visualizations are flowcharts. Linear. Sequential. Node A leads to Node B leads to Node C. They look clean in a slide deck. They describe how work should go.

They rarely describe how it actually goes.

In complex domains (software product development being a textbook example) work is not a conveyor belt. It’s navigation. Teams move through uncertainty, loop back, skip steps, combine things in ways the process diagram never anticipated or is able to visualize. The interesting question isn’t “did you follow the process?” It’s “did you make good decisions about which practices to apply and in what combination?”

A flowchart can’t visualize that in a realistic manner. So I thought, maybe a hexagon map can.


Hexis and Hexagons

I discovered the use of hexis in Cynefin — Dave Snowden’s framework for understanding complexity. It describes a part of a process, a practiced capacity. It can help make complexity more visible or it visualizes steps to take in a complex domain

I liked the concept: hexagonal tiles as a shape connected like ice floes in a frozen lake. So: hexagons.

Each hexagon represents a single practice. Inspired by The Art of Agile Development — practices like user story mapping, pairing, retrospectives, definition of done, scenario writing, stakeholder review — each one a discrete, learnable, applyable unit of work.

The hexagons connect to each other. The connections aren’t arbitrary, they represent real relationships between practices. Some practices enable others. Some run in parallel. Some build on what another produces. The structure is intentional.


Work modes as patterns

Here’s the core idea: a work mode is not a process. It’s a lot of patterns of hexagons.

For example: Discovery looks different from Delivery, because they activate different practices in different configurations. Discovery might center around Hills, Personas, Idea Pitches, lightweight prototyping. Delivery around Epics, Scenarios, Software Teaming, Definition of Done, Sprint Review.

But the real power of the model lays in what teams can do when they describe their working mode with it:

They can skip ice floes. If a practice doesn’t apply right now — skip it. The structure is still intact. The other floes are still connected. Nothing breaks.

They can swap ice floes. A team working in a context where formal user research isn’t possible might replace a Persona workshop with a quick stakeholder interview. Same position in the pattern, different practice. The shape holds.

They can see where they are. This is underrated. A hexagon map gives teams a shared visual language for “what are we doing right now and what comes next.” Not a prescription — a compass, that can be changed and visualizes how practices are connected to one another.

This is an example that I used to visualize a work process for a team of mine:

Work modes visualized as connected hexagons — each hexagon a practice, each cluster a mode


How can this help me?

It’s a visualization tool for complex work. One that holds structure and flexibility at the same time. The structure gives teams orientation. The connections between hexagons make the reasoning visible: “if we skip this one, what does that mean for the ones it connects to?”. It can be used in events like Retrospectives, to point to certain practices and analyse how they worked in a certain timeframe.

That’s a conversation worth having. In my experience, looking at a description of a work process or looking at a process diagram don’t even make it possible.


Where I’m taking this

I’ve mapped a couple of team processes with it. It is difficult for a team to understand at first, but once they got the hang of it, it can really make a difference. But I am sill experimenting with making it more readable, understandable or how to create a catalog of hexagons for people to use.

The Tabaluga tv show never gave you a fixed path. It gave you a lake, a set of floes, and a problem to solve. The skill was in reading the ice.

That’s what I want for teams.


Inspiration