3D Kanban

Despite the fuss that's been made of its Japanese name and Lean origins, a Kanban is just a card wall where you pull cards toward done from the right rather than pushing them into progress on the left. Pulling toward done minimises work in progress, which is good for ROI and related measures.

But what's a 3D Kanban? The obvious 3 Ds are Design, Delivery and DevOps laid out as if they were stacked on top of each other. Looks a bit complicated, especially if you're used to a 3-column Scrum board. Turning something simple into something complicated doesn't seem like an achievement ... unless there's another benefit?

Business Agility requires Design, Delivery and DevOps to work continuously, hand-in-glove. Self-directing portfolios of self-managing streams of self-organising teams. Relations between many different kanbans make this harder to do and time spent keeping all the boards lined up with each other is kind of painful. So in this respect a 3D Kanban could be simpler. But there's a bigger benefit ...

The Beauty of Breadth-First

On a 3D Kanban we only split work items into smaller pieces when we actually need the pieces. Boxing work up breadth-first rather than detailing long-ass product backlogs makes the context for prioritisation decisions explicit. You can't just walk up the nearest foothill in a highly dimensional design space and expect to discover Everest. Breadth-first targets the global maximum of ROI rather than just some local maximum.

Whether it's XSCALE XPM, Devops 3rd Way, Google's Design Sprints, or Lean's Set-Based Concurrent Engineering, breadth-first avoids exploring any part of the design space in depth until there's a sketchy view of all of it.

Here we're using XSCALE concepts to chunk from Products down to Stories. But you can use any breakdown structure you prefer so long as you do it just in time to track a card's flow. Because less cards on the board means less complexity and more YAGNI.

XSCALE's definitions of these things are minimalist:

• Products are units of marketing and customer experience for some value streams.
• Epics are business objectives relevant to bringing the Product to market.
• Features are the smallest parts of an Epic with appreciable business value.
• Scenarios are sets of BDD acceptance criteria for a Feature.
• Stories are segmentations of Scenarios that share INVEST properties.

Of course you're free to bring your own distinctions to the cards on your own Kanban. The point here is representing the structure breadth-first. Think of the colours here as just a way to see how the boxes on the right are always pulled directly out of the boxes on the left. Let's follow the wall left to right and see how that works.

Walking The Wall

Walking the wall is a kind of standup meeting you use to propel your workflow. You can make your 3D kanban have a very different workflow to this one, which is based on the XPM, XAP and XBA patterns:

• Canvas means boiling business constraints and metrics down to an Epic landscape.
• Analyze means figuring out what releasable Feature-sets are relevant to each Epic.
• Estimate means figuring out priority & budget per Feature to make a release plan..
• Design/Test/Build/CI is the classic agile SDLC.
• FIT is Feature Integration Testing in a Production-Like Environment.
• SIT is Systems Integration Testing in Production using a Dark/Canary/A-B flow.
• Science is where we deploy, experiment and gather data to inform the Canvas work.

So long as BDD tests are written in Functional style their analytics can be collected longitudinally to identify the bottleneck market constraint. Models combining these analytics into metrics can be combined with cumulative flow through a 3D Kanban to inform Throughput Diagrams similar to this:

See Also:

Exponential Business Agility, Corey Ladas. Business Bingo