Kanban Networks Exercise

One of the approaches I’ve been using lately with clients is starting with whole system Kanban, focusing on Discovery and Delivery, and then potentially zoom into Team Agile in some/all streams as the organization understands the concepts of Flow, Stop Starting Start Finishing, Inspect and Adapt etc. It IS typically necessary to go to smaller batches earlier on so I recommend setting up Lean/Agile Discovery processes that pull market/product demand and create Features, MMFs and Stories from it.

I want to quickly share a Kanban exercise I ran today in a workshop focused on this approach. The organization decided to indeed start with a Kanban system and

I won’t go into too many details, but if I see there is interest I might blog more about it, or write a chapter in the upcoming book.

The first exercise I ran today was Jesper Boeg’s HairDresser.dk Story Mapping Exercise. I followed his exercise with a discussion and short exercise for how the Story Map would translate into a Discovery/Delivery Kanban System, and how it might look like in several points along the development life cycle.

This setup the basic building blocks for creating the real kanban network of the organization.

We identified the product streams - 5 real Product streams driven by Product Management, with an additional stream covering R&D housekeeping, Research, Automation, etc.

We then split into small groups, each covering one of the streams - with the real PM of that stream as well as actual people that will probably be involved in working that stream day to day.

We then Visualized the work - at the level of Features currently in the various stages of the Stream - Backlog, Analysis, Implementation, Ready to be Released, etc.

Now it becomes interesting. Each Feature in a stream might require work from several different technological teams (4-5 of them). We gave a color to each technology team/stream and each group marked each Feature with the technology streams that were involved. We played with various expand/collapse patterns when trying to visualize the flow of these technology aspects of the Features, and discussed whether that visibility was required for a Product Stream interest level or not.

Then we took a step back, and went Small Batches. We took a couple of Features and sliced them to Minimally Marketable Features and then User Stories. Since we still have technology teams we still had to slice the stories to technological aspects, but at a much smaller batch size which will provide much faster/earlier integration/testing and faster cycle times. All of this still without going Feature Teams. The value of Flow/Pull without Iterations in this model is clear - there is no unnecessary wait between the time a Team finishes its “Team Story” until Integration can happen or Testing can pull.

We then visualized the Technological Team Stories and had another discussion about visualization patterns.

Next step was zooming into Technology Team Boards. It was simply a matter of collecting all the colored cards from the different Product Stream boards and representing them on a single Team Board for each Technology Stream. We are not even sure those Boards will be used at the team level up front. We might start with a Kanban system used by the people involved at the work management (PMs, R&D Managers/Leaders) to learn the ropes of the system and then extend its usage.

We also discussed priorities between Product Streams and the R&D internal streams. The understanding that allocating WIP to each stream and creating a Weighted-Fair-Queuing system based on that was very important. Senior managers in the room felt that this would make it much easier  to meet the portfolio allocations the organization decided on. By default when work for a stream is finished it would mean pulling a new card from that stream.  But there is still the flexibility to deal with struggling items by optimizing globally across Product Streams.

Another board level is the “Big Picture” board where the MMFs from each of the Product Stream boards will be represented.

The exercise brought to life the complexity of the organization’s network but highlighted how a Kanban system can simplify its operation as well as drive towards improvement. There were several A-Ha moments of understanding how Limited WIP would solve systemic problems currently haunting the organization.

It also highlighted how creating Feature Teams allocated to a Product Stream would make life easier from a coordination perspective. This gives the organization incentive to try some form of Feature Team approach when the time is right.

The fact that we exercised all this using real work of the organization, real teams, discussed real problems of starvation, one technology team being the bottleneck, how overall WIP limits might affect that, etc. was a great way to understand what an organization-wide Kanban system is all about.

I loved this exercise so much I’m thinking about creating a “sterile” version  for advanced public product management / kanban workshops…

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.