In software development inventory waste is best represented in the queued activities in between the hand offs from individual to individual. If using a complicated board, you would represent the full flow or value stream for delivering stories. This would normally contain columns such as “Ready for Development” or “Ready for Testing”. A build up of one or two items in these columns isn’t necessarily bad, but when moderate to large queues start to appear it is symptomatic of constraint or flow issue within the team.

In teams doing Kanban well, they are limiting their work in progress across both the active and the queueing columns (ie “In X” and “Ready for Y” columns).

What a Hotspot board does is visually highlight the inventory waste areas of the team’s flow. Rather than structuring flow going across via the headers or columns, it balances the zones of the board so that the inventory waste areas are all in the center part of the board – ie the key focal area of your eye, highlighting the criticality of watching these waste points by backing the zone in red.

There are a few potential downsides to such a board:

1) Swimlanes become difficult to utilise as a visual technique (as flow bounces around the board)

2) Visual fixation on only the hotspot results in the “In X” activities having reduced focus. This could result in high WIP of in flight work being ignored which would definitely not be a good thing.

To overcome this second issue and to align more closely with one of Kanban’s key pricinples, limit work in progress, I extended the idea of the Hotspot board to become the Twister board (yes like the game with spots).

The Twister board re-introduces work in progress limits in three ways – 

1. In the hotspot zone itself
2. In the active flow states – visually highlighting the actual kanban availability through the existence of the circles
3. In the active flow states – visually highlighting the risk of hitting to top threshold of work in progress through colour – green =  all good, orange = getting close, red = upper threshold of work in progress being met

Note: pictures are examples only of flow and work in progress limits. As always, apply this contextually to your work and teams.

• used Kanban – work item types to allocate capacity and 3 levels of service (standard, coordinated, expedite)
• JIRA was the tool but was not the most ideal choice and not really up to the task
• reported by type on backlog, work in progress, throughput (number of work items not size), velocity (throughput and velocity were similar which showed average size), cycle time, class of service mix, due date performance, estimation accuracy, cancelled WIP (started and then cancelled work) and demand balancing (clearing out the backlog)
• flow efficiency – percentage of time you work on an item versus in progress, also referred to as touch time – using time tracking in JIRA to do this
• time allocation – value add, failure load (defects), transaction cost (overheads of planning and releasing), coordination cost (management), used percentage of time spent rather than actual hours

The one things that got me thinking during this presentation was the flow efficiency report.

Early on my journey of being an Iteration Manager, my teams used to track times per card. We used to use XPlanner which had some reasoanbly easy functionality for tracking time (one of the good features was as the Iteration Manager I could enter time for my team if needed, tools like JIRA require the developer to record that data if you want it assigned to that developer). We used to use thee metrics for comparing estimates to actuals but over time I came to the conclusion that we would be much better off just making sure that the cards were completing on time (an average of 3 times) and splitting cards out if they appeared to big.

Lately, a number of people in my Agile classes have been arguing that time track is beneficial. My usual response to this (like for all metrics) that it is OK if it adds value, but my recommendation is not to waste your time. Even more so, this opens up the estimation debate that I also believe that a lot of time should not be wasted on (#noestimates), but that is a discussion for another post. My main reasoning is often we need to track for other sources (like timesheets) in different systems, and the overhead does not justify the effort. If teams need time metrics (often to see if time is being wasted away from the core work of the team, say on production support or corporate meetings), I suggest they are done at a team level and rounded to the nearest hour, and collected as time not spent not on project work.

In the graph above, flow efficiency is a good way for showing waste in the system (in this example, the team could potentially be way more effcient), but it relied on the team tracking time (in this case using the time tracking feature in JIRA against each card). I really like it as a graph, I am just not sure the effort to produce it is justified.

Some discussion in the Q&A revolved around recording time tracking (or similar metrics) is OK if the team understands it is an incentive for better metrics, and I can’t disagree with that thought. Just in my experience as an Iteration Manager, getting reliable and timely time and effort metrics ha been painful and the reward outweighed the effort.