Category Archives: Visibility

Using card types and filters as “Virtual Horizontal Swimming Lanes” on a Kanban Board

Estimated Reading Time: 2 minutes

After a serious break from Kanban Mechanics posts, here is one for you Kanban System Designers/Practitioners out there…

I’ve recently become a fan of the “Virtual Horizontal Swimming Lanes” style of Electronic Kanban Boards. These Boards don’t use physical horizontal lanes but instead use dynamic and easy filtering to show virtual lanes. Specifically I helped several teams come up with this style to represent a 2-level board – for Features and Stories (actually 3-levels if you count breaking each Story into Team-Stories or Tasks using a sub-taskboard). Since I get some questions about this, I thought it will be helpful to record a short screencast about it. So here it is.

These teams use LeanKitKanban by the way, which does a very nice job, especially with the refreshed UI and filtering capabilities. I’ve worked with simpler designs in AgileZen and more and more tools provide dynamic data-based horizontal swimming lanes these days (Atlassian GreenHopper RapidBoards seems to have a good one that some teams like but I haven’t worked with it too much myself). In order for the tool to support this you will need a way to filter/split into lanes based on data attributes of the cards, ideally with the ability to setup a couple of identifiers for the virtual lanes that will be attached to the items moving thru the lane and then detached from it.

Kanban Board Hierarchies using Virtual Horizontal Swimming Lanes


Also, once you start using such a board, getting to a workable “Release Burnup” which shows you trendlines of your progress compared to where you need to be can be tricky, as it always is with multi level boards. A key trick is hiding the parent expanded Feature when its child Stories are in play as well as hiding the completed Stories from the CFD when they are collapsed back into the parent Feature. This way we avoid showing a piece of work multiple times in the CFD. This CFD is calculated based on card size since that is the way to deal with different levels of size on the board as well as the fact that Features in the backlog might not yet even be Minimally Marketable and so can be quite large. Not this is the way to track a “Release”/”Project” comprised of multiple Features. To track a single Feature you simply use the filter above to see how it is doing, or create a CFD focused just on the cards in this virtual lane and then see the burnup towards completion of this specific feature.

To generate this CFD in your tool you will need a strong CFD capabilities that allow you to expand/collapse lanes as well as ignore lanes and calculate CFD based on size.

If you are interested in the template for this board here it is. Maybe the LeanKitKanban guys will add it to their template library at some point…

If you want to learn more about this leave me a note, I might be convinced to elaborate some more…

Kanban Networks Exercise

Estimated Reading Time: 3 minutes

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 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…

Touching your electronic kanban board

Estimated Reading Time: 2 minutes

Some of the teams I work with choose to have electronic kanban boards. Why? see for example 5 Reasons Why Electronic Boards Are Better Than Physical Boards a good new blog post from the guys over at Silver Stripe Blog.

My main recommendation to those teams is to insist on having a big visible board, preferably in a public non-meeting-room space. This is useful both to ensure the daily sync meetings are casual rather than formal, as well as to have a constant big visible control in your face, showing both your boards as well as other dashboards (e.g. Continuous Integration status, Defects Metrics, Production Analytics, etc.)

In LSSC11 the LeankitKanban guys came with big touchscreen LCDs, which seem a great direction to go with.

Bandit Software CEO, Chris Hefley, using LeanKit Kanban on an 82-inch touchscreen

Bandit Software CEO, Chris Hefley, using LeanKit Kanban on an 82-inch touchscreen

The question I then get asked, especially in Israel, is how do I find such a thing…

Following the reuse guidelines we preach when talking about good engineering practices, now that I’ve been asked 3 times, I’m collecting the relevant links in a post I can refer people to in the future, as well as to serve the general public looking for such information.

Note: I still haven’t seen such screens in action beyond the short demo mentioned above, so consider this information “AS IS”, not a review/endorsement. Also note I have no connection whatsoever to the vendors or sellers listed below. I just found some links on google. Hopefully a couple of organizations I’m working with will get such a board soon and I’ll be able to do an actual experience report.

HP LD4200tm 42-inch Widescreen LCD Interactive Digital

HP LD4200tm 42-inch LCD - Used by LeanKitKanban















Touchscreen 42" from JB in Israel

See also pdastore in israel which has a variety of touchscreen LCDs

If you’re in the US and are looking for a real treat, seems like Horizon Technology are a good custom installer to check out. They provided LeankitKanban with the 82″ custom screen shown above. If you want to be the team with the biggest LCD touchscreen in town, that’s the way to go I guess…

Hope this helps. And if you’re in Israel and are setting up a cool electronic board/dashboard, let me know! I’ll be happy to drop by and check it out!

If you have good experience with other types of touchscreen LCDs, or a good review resource for those, please comment and let others know.