The main objectives of the Toyota Production system, which is one of the primary sources of inspiration for Kanban for knowledge work, were to get rid of overburden (muri) and inconsistency (mura), and eliminate waste (muda) from your system. Any system/ business process you are using to develop products or offer services will have a certain amount of waste generated. All the current Kanban products in the market including SwiftKanban have mapped most of the basic principles of Kanban like Limiting Work-in-Progress (WIP), visualization, flow and so on. However, very few of these products have helped identify and measure the waste in your process.
SwiftKanban has had a couple of metrics for quite some time that helped in this area. These are the Blocking Analysis, which provides a detailed look at why cards get blocked on your Kanban boards and how much time is lost to blocking, and also the Flow Efficiency, which gives you an immediate feedback on the amount of wait time in your overall Cycle Time. Both these metrics, while providing a great insight into your system, are nevertheless a “rear-view” of your work – giving you insights into work that has already happened, waste that has already occurred.
As a part of our constant endeavor to improve the efficiency of your system, we have been focussing on this issue for some time now. Consequently, we have come up with a set of features which will help you identify, measure and take proactive action for waste reduction! This feature set is introduced as a part of 4.16 release.
Waste?
A basic question that will come up to your mind might be “What is a waste in my system?”.
The answer is – there are several aspects of your process that represent wait. As mentioned earlier, blocked cards sitting on your board are a waste. Cards sitting in intermediate buffer columns (wait states) are a waste.
A very crucial – and historically significant – form of waste is work that is taken up and then abandoned mid-way because customer requirements changed, market conditions changed, or other similar phenomena. In terms of a Kanban board, this would be in the form of cards which were added on the board and taken up for work, which means they moved along the Kanban value stream, but exited out of board without completing the lifecycle. They essentially represent work that was “aborted”! The aborted cards represent the effort (resources, cost) that was put in till the time it was aborted. They represent the opportunity cost of other work that could have been taken up and completed, but could not.
Some typical business scenarios which come to mind include:
• In product development, features getting partially worked on before being discarded, due to change in product, business or sales strategy.
• On a Helpdesk/ Support board, work done on Issues or Change Requests, before the end-user discovers they no longer have that issue or need that change request.
• On a sales board, work is done in the sales funnel and prospects dropping out at various stages of the board before becoming actual customers. (Of course, this is an expected outcome, hence may not be considered a waste. We all wish we could win a 100% of our sales!)
In all the above scenarios, work was underway (there were cards under execution) which was aborted (cards exited the board) due to various reasons without being completed.
Waste Categorization
Before we proceed further, for any Kanban system, there are 2 stages of the process represented in that system: the system’s own workflow (visualized on the system’s board) and its upstream process.
Upstream processes are stages of workflow before the main workflow of the board (for ease of understanding, we refer to this as the downstream process). They may be visualized on the same kanban board or in a separate “upstream” board all together!
From the Kanban system (under observation) point of view, cards can be discarded in the upstream process or during the downstream process. It is useful to know and understand your system’s behavior from this aspect.
If work is discarded in the upstream process (such as the process of prioritization of product features to be taken up for development), then the work does not enter the downstream process at all, and does not take or spend any resources of the downstream team. Such work is typically referred to as “discarded work”. On the other hand, work that enters the downstream process, where resources are spent on doing it, and then business takes the decision to no longer continue that work as the customer no longer needs it, then such work is typically referred to as the “aborted” work. From the downstream process point of view (the current Kanban system’s point of view), aborted work is
From the downstream process point of view (the current Kanban system’s point of view), aborted work is a waste, discarded work is not. (However, for the upstream board/ team, where work might have been done to, for example, provide detailed specifications or for prioritization, that work would be considered waste for them. At an overall system level, both ‘Discard’ and ‘Abort’ represent waste of some magnitude.
With the latest release, SwiftKanban helps you identify both these forms of waste!
In order to do so, you can now do the following –
- You can identify the “upstream” and “downstream” sections of your board (the assumption being that your upstream process is being modeled on the same board. You can do this in the Board Editor.
- You can discard or abort cards, depending on whether they are in the upstream section of the board or in the downstream section.
- You can then view your Discard and Abort analysis to see what is the overall waste in your system.
These are described in the sections below.
Upstream Process definition
Typically, your upstream process might be your backlog board, where the team performs backlog grooming activities and identify the cards to be moved to the Ready queue on the Kanban board – the downstream stage.
This is the base assumption in SwiftKanban – so by default, the “Backlog” is considered to be your upstream process or stage. However, often the backlog is not enough and we have encountered various board designs where the upstream process is modeled on a separate board altogether or in a set of initial columns of the Kanban board.
To handle the various kinds of board designs, we have provided the option for the board manager to specifically define the upstream stages for their boards, in the Board Editor. Using this capability, you can simply select the upstream columns as per your board design.
The following is the Settings screen, where you can select your upstream column range.
Once the upstream columns have been selected, the rest of the columns will automatically be considered as the downstream process!
Identifying Waste
In the context of this feature, when you chose to discontinue working on a card, that card is associated with waste.
To discontinue the card, you can right-click on the card and select either the Abort or Discard option, one of which is shown depending on where the card currently is and based on the column definition. To differentiate between 2 types of waste, we have provided the Discard and Abort status indicators. A “Discard” status indicates ‘waste’ from the upstream process while the “Abort” status indicates ‘waste’ from the downstream process.
Measuring Waste
In the Toyota Production system, there are 8 types of waste already defined which broadly fall into the categories of effort, time and materials. In other domains like marketing, IT, software development, telecom etc., there are only 2 relevant waste units – effort and time. Considering this, we have designed the following Discard and Abort analytics components
Discard analysis
A sample screenshot for discard analysis is shown below, where you will see the discard data for a particular time range. It is plotted in terms of Discard rate and the Discard Reason code. Discard rate provides the number of cards discarded for a time period. You can also compare the discarded cards against the completed cards. (cards which successfully moved through the selected column range)
The reason code part will take up later in the article.
Abort analysis
The Abort analysis is similar to the Discard analysis but for cards discontinued during the Downstream process. All the filter settings for the Abort analysis are the same as those for the Discard analysis, except that there is an additional option to plot the chart based on ‘Effort’. For the downstream board, the Abort analysis by effort is in two forms: one is by Cycle time (i.e summation of the cycle time of the aborted cards) and the second is by the ToDo effort (i.e summation of ToDo effort associated with the aborted cards for the particular time range).
Eliminating Waste
To eliminate waste, you need to understand the root causes of why cards are being discarded or aborted.
To support this analysis, the user is prompted to provide a reason code from a drop-down list of Reasons and also enter their comments every time they discard or abort a card.
The Reason codes available by default in the product are Dropped, Obsolete, Deferred, Merged and Clarification Needed. You can add or edit these codes as needed, by editing Abort Reason Codes and Discard Reason codes master lists.
Based on this data, SwiftKanban provides the following Pareto analysis of the number of cards dropped based on each reason code.
The analysis helps you understand what are the most common causes for this waste and helps you and your team address those root causes.
Going back to some of the initial business scenarios listed, users could conduct the following analysis and attempt to arrest or eliminate various types of waste:
• A Development team can communicate to their customer the overall effort wasted due to aborted cards due to change in prioritization.
• Product owners can provide the discarded roadmap items analysis to stakeholders, helping them to understand the wasted effort of the product management team.
• Management and Sales teams can identify the major reasons for client dropout, as well as the amount of overall effort spent for those clients, and try to make changes to the sales process to improve sales.
Conclusion:
With this set of features, we will help you reduce the muda from your system and make the system more efficient. We will continue to iterate on these features from time to time and make improvements as needed! Please give them a try and tell us how you have been able to identify, analyze and eliminate different types of waste from your system.
Register for a SwiftKanban 30-day free trial here!
For any issue, queries and feedback do write back to us at [email protected].
Priyank Parekh
Product Owner –SwiftKanban
