The Kanban Board is the de-facto standard for visualizing work in software development today. Whether your team does this with an electronic version in your work tracking tool, or on actual cards stuck on a whiteboard in a room, we have all been socialized to expect that the work of making software will be visualized and even analyzed using the movements of cards on a board. For its simplicity and universality, there is really nothing else that comes close to the Board as a metaphor for work, and it is little wonder that it is so popular.
The key shortcoming of the Kanban Board is that it provides no insights into what is happening to work between the time a card enters a column, and moves to the next. In a discrete manufacturing context, where the Kanban Board originated, this was not a problem, because knowing the column for a card pretty much determined what was going to happen to the work product while it was in that state. It was precisely the movement between the states, and the build up of queues in these states that mattered to analyze process flow and spot problems.
But this is absolutely not the case when we make software, instead of widgets. Everything interesting about making software happens in between the time a card enters a column and moves to the next, and this is different for each and every card, almost without exception. So if you want to know what is happening to work in progress on a software team, you need visibility into what is happening, specifically to each and every card, and at every point in time while the card is in progress. The Kanban Board looks on in silence here.
The discussion threads in your work tracking and messaging tools give you some sense of what is happening during implementation, assuming you care to read through them all, but it is hard to figure out any patterns or separate the signal from the noise this way. More importantly, this leaves out the most critical stage: the part where engineers are implementing the cards. Good luck trying to figure out the big picture from the Slack notifications from your DevOps tools.
The Wip Inspector in Polaris is designed to tackle this problem and to show you work in progress in a way that makes more sense for the work of making software, instead of widgets.
With Continuous Measurement in Polaris, we have a detailed picture of the state of play for work in progress, accurate at all times, up to the last progress event: currently defined as the last commit, or update to a card or pull request.
The Wip Inspector organizes your work in progress into three buckets for easy focus and analysis and keeps it updated in real time. Take a glance at it whenever you want, and it will tell everything you need to keep up to date with the progress of the team.
This shows the cards that have had commits in the last 24 hours, using the SpecFlow Chart for this period. You can use all the power of the SpecFlow Chart to explore everything about this set of cards. Typically these are the cards you have to worry about the least, unless something has been churning for a long time, and we will show you how to spot those quickly on the Wip Inspector.
The other category to focus on here is invisible work: commits that are not associated with cards. These show up as Untraceable commits in the chart, together with full details as to who made the commits and why they could not be traced back to a card. This will tell you who you need to nag about that.
In this bucket we look at all work in progress items as a whole and figure out what has moved at all (either via a commit or a card state update), what has not moved, and whether the delays are in engineering or downstream from engineering in delivery.
Separate latency charts for cards in engineering (before code-complete) and cards in delivery (code-complete to release) allow you to keep track of the critical bottlenecks at the card level, make sure that work on cards are prioritized appropriately, and figure out what's stuck.
Since Pull Requests (or Merge Requests) are a very well known and common source of latency, we call these out and track these separately in the Wip Inspector. Setting Age and Latency limits on Review Requests, is a powerful policy tool that can be used to make sure that the team takes collective ownership for getting code reviews completed efficiently, and Polaris gives you the tool to monitor compliance for these policies in real time via the Wip Inspector.
After latency, the next most critical measurement in Ergonometrics™ is Effort. This measures the effective engineering capacity, measured in developer-days, consumed by a card. Polaris measures this directly off the Ergonometric Graph™, using the mapping between commits and cards, so you don't need to have engineers track time in timesheets or time tracking tools anymore, if that is what you have been doing for this up to this point.
Effort is usually much smaller than the total duration the card was in implementation, for most individual cards. Human delays dominate actual effort for individual cards for the most part and latency measures this implicitly. But if a card requires many developers to work on it, or it requires a single developer to work on it for many days because it is a complex feature, or they are churning on a solution, then this will be reflected in a high effort card. Cards that are churning without making progress stick out like sore thumbs on the effort metric.
Effort is both a measure of implementation complexity and as well a cost metric, since engineering capacity is a close proxy to cost. We use this in both senses, interchangeably in Polaris.
While individual cards typically have low effort, when there are a lot of cards in progress, the aggregate effort serves as a very reliable metric for the Cost of Wip. Think of this cost as the total engineering dollars you have spent on these cards so far, but have not yet realized any value because the work has not been released to customers. If you keep a lot of Wip around for long periods of time, then your Cost of Wip will add up over time.
The Cost of Wip metric can be used to put a concrete cost on utilization based resource allocation strategies. These tend to allocate work so that people are maximally busy, instead of allocating work so that work can be most efficiently moved through the delivery pipeline. This has a real cost in terms of increased Wip, and measuring and reducing this cost concretely and in real time is a key strategy in Ergonometrics™, showing teams the value of prioritizing flow over allocation efficiency.
High Wip also increases the likelihood of wasted effort. If you have a card sitting around in implementation for a month, especially a high latency one, it is likely that this work will never actually get released and will count as wasted effort. Its cost stays allocated to Wip until it is either released or abandoned. Releasing it will probably require significant integration and/or rework since the code base has probably moved on since the original work was done.
Either way, the costs are going to go up. Another reason not to let your cost of Wip accumulate.
Finally, the Wip Inspector shows KPIs for Work In Progress. This is a key feature that is enabled by Continuous Measurement. In most reporting based systems, KPIs are shown only for work that has already been completed. However Polaris can measure every KPI at each progress event and give you the current state of the KPIs for your current pipeline in real time.
So if you've set a target of 7 days for your average cycle time and the average cycle time of your work in progress is already much higher than this, you know that your numbers are headed in the wrong direction, and you can try and do something about it instead of waiting until the cards have completed and it shows up in your Work Tracking reports.
The Wip Inspector also gives you easy access to a set of benchmark metrics (for example, work that completed in the last 7 days) for you to compare the current performance against. This is useful to keep an eye on how your current work is trending against your most recent performance.
The Wip Inspector is the key control tool in Polaris, enabling teams to inspect and adapt to the state of work in the pipeline as it executes, and letting the team keep within policy guidelines in making tactical day to day choices on what to work on and prioritize. The Wip Inspector drives the innermost fast feedback loop in the Ergonometrics™ framework.
So there it is. The Wip Inspector. Tells you everything your Kanban Board does not. Look at it every day, and use it in your stand-ups, and you'll find that it will change the way you make software.
