How to select kanban tools

I am often asked what software tools are available to support the use of kanban. Many lists of such kanban tools already exist (see the end of this article) and I do not intend to repeat the same information here. Instead, I would like to explain my view of the architecture of kanban tools and provide some advice for selecting those tools.

General information about selecting kanban tools

In this discussion, I will build on the information that I have published in my book, IT Tools for the Business when the Business is IT. Although that book talks specifically about IT and about service management, virtually all the information about how to select and implement tools remains valid for kanban tools.

Here are some of the key messages in that book:

Select tools based on their value to your organization, not based on the breadth of their functionality

Organizational structure is often the most important constraint to finding appropriate tools

Building a relationship with a tool vendor is, unfortunately, mostly an exercise in managing downside risk

No single tool vendor is likely to provide a single integrated solution that provides your organization with the most value

Select kanban tools based on value

Often, organizations make the mistake of confusing a wealth of functionality with value. Unfortunately, it has been my experience that many organizations simply cannot be bothered to think about the real problems they want to solve and the desired value of the tools they acquire. As a result, they tend to select tools based on extraneous, largely irrelevant criteria. Even worse are the organizations that create elaborate evaluation methods with arbitrarily weighted comparisons of tools—an approach that I have likened to voodoo.

Software tools are popular or are used by others in your network of acquaintances for many reasons, few of which concern the value the tools will provide you. But, if you are planning to use kanban, you are probably making a commitment to work in a more lean way. Think about evaluating tools in the same way that you would assess a value stream for value-adding and non-value adding activities. In the same way, you should distinguish between what is value adding in a tool and what is non-value adding.

Organizational issues

The ability to support organizational complexity is one of the biggest differentiators among software tools. If you are looking for a tool to support a single team, this point is probably not important. But modeling the organizational structure in your tool becomes extremely important if you are trying to scale up kanban to the enterprise level, where the links among kanban boards may be very useful or if you have to address issues of confidentiality. Remember that not all tools are created equal in this regard.

Managing vendor risk

Most organizations either completely ignore the issue of vendor risk or get their assessments very wrong. They often assume that vendor risk is inversely proportional to the vendor’s size and age. Yet, those factors have only a minor effect on vendor risk. Indeed, risk may also increase with the age and size of the vendor.

Remember that the more a market space is immature and volatile, the more there will be vendor risk. When most solutions are provided by young startups, the vast majority of those startups will disappear in a year or two. You will see this in the lists mentioned at the end of this article, where many of the vendors or products no longer exist.

Furthermore, those companies that are quick to gain large market share are often the ones that are bought up by yet larger companies. Those larger companies often have strategies that are not aligned with those of the software’s creator. Such changes in strategy may have a direct impact on the attractiveness of a product for a given customer.

I have seen organizations invest large sums in a market leading product, only to find two years later that that product is to be phased out. There is the too common phenomenon among large companies that may be called “serial acquisition”. The company buys a smaller company to get its product. It develops that product during a few years, making it more stable but innovating little. Then it buys yet another small company to acquire a different product that is more innovative and has shown good promise in the marketplace. The older product is phased out of production with varying amounts of grace. So the customers that really preferred the previous product are left holding the bag.

In short, the risk of dealing with young companies is that they and/or their products might soon disappear. With large companies, the organization itself might last longer than a small one, but their products can change too rapidly as they flounder about trying to find good strategies in an ever-changing market. I have a strong prejudice in favor of small companies that stay highly focused on developing their products, jealously guarding their independence and building long term relationships with their customers.

A factor mitigating vendor risk, especially for simple kanban board tools, is the simplicity with which they work. Anyone with a basic understanding of kanban can easily and quickly configure most of these tools. Thus, in the worst case, it would only take a few hours to switch over to a completely different tool. The main issue in case of vendor failure concerns the conservation of historical data. A user may wish to consider this issue when choosing a solution and when determining the operational process by which that data is handled.

Integrated solutions

There is no universal answer to the question of whether it is better to integrate separate, best of breed tools, or better to rely on a single vendor to provide an integrated solution. This issue highlights the importance of understanding the logical architecture of the tools, which I will address below.

Kanban tools functionality

Let us consider the types of functionality that software tools might provide for managing work using kanban. Some functionality is specific to the management of flow and to kanban:

make the status of work items easily visible

implement the pull approach to flow

automatically indicate blockages and bottlenecks

support ready queue replenishment

integrate input and output from multiple kanban boards

Other functionality is generic to software, such as helping to:

easily display different views of the state of flow

passively capture data about flow

enforce organizational standards for data formatting and data display

improve data integrity

provide access to data at a distance

automatically generate analytical reports

operationalize the analysis of option value and risk

Make work visible with kanban tools

Often, teams starting to use kanban make use of a whiteboard, cards and markers to make their work visible. Simple, inexpensive and fostering collaboration, such kanban boards are excellent tools for a single team whose members are all co-located.

Frequently, however, a single team might have members located at different sites, or perhaps some team members might work, on occasion, from home or while traveling. In such cases, a virtual, software-based kanban board can easily provide a centralized focus for visualizing work, even though not all team members are grouped together.

Kanban tools used to implement the pulling of work

It is critical to distinguish between the simple display of data in the format of a kanban board and the use of a kanban board to implement the pull principle in managing the flow of work. It is becoming increasingly common for ticketing tools to display tickets and their statuses in a card board format. However, most of these ticketing tools continue to require that work be pushed, rather than pulled. In simple terms, they call for workers to assign tickets to others and to update ticket status when they have completed their own work, thereby queuing up work elsewhere. This is what we mean by pushing work. In a pull system, work in progress is limited, thereby fostering a just in time approach to flow. Downstream workers pull work when they are ready, rather than having it thrust upon them.

Kanban software tools typically implement the pull approach by simulating the physical board. They allow workers to drag and drop cards in columns. But surely there is no added value in sliding a virtual card on a touch screen, as opposed to moving a physical kanban card on a physical kanban board. A kanban software tool that only emulates what you do on a physical board is merely a gadget with little added value. However, more sophisticated tools might, for example, implement rules that constrain the movement of cards and implement the flow management policies.

Indicate blockages and bottlenecks

Identifying blockages and bottlenecks is a central task of the daily stand-up meeting. However, doing so requires a certain amount of manual data tracking. For example, some teams add dots next to each card for each day it is in a column of the kanban board. Software can easily perform the same task and highlight any issues. Teams benefit from this by reducing the time taken during the stand-up meeting in performing administrative tasks, leaving more time for getting a common understanding of the status of work items and deciding what to do about them. This small savings could be important if the team is serious about limiting the stand-up meeting to only a few minutes.

Support ready queue replenishment

In general, the ready queue at the left side of a kanban board is replenished by multiple customers. Since that queue has a WIP limit and is not the same as a backlog, a means must be determined to decide which customer has the right to replenish that queue when a slot opens.

If replenishment is done via a meeting of customers, then a tool could support the decisions in various ways, depending on the policies controlling queue replenishment. For example, a tool could provide historical information about the provider’s previous work.

If replenishment is done via round robin assignment to customers, then a tool could alert the lucky customer whose turn it is to replenish, triggered by the opening of a slot in the ready queue. One might also imagine a more automated replenishment based on the output from other teams, depending on how those teams are structured in the organization.

Integrate multiple kanban boards

Depending on how your organization is structured, each team’s kanban board might have input coming from the work of another team, and its own output might be input to yet a third team. Thus, there might be a certain amount of redundant work in replenishing another team’s board, based on existing kanban cards. Software tools could eliminate some of this redundancy and rework. The value of automating such interfaces depends heavily on the methods used to manage board replenishment, as well as depending on how teams are structured. For example, an organization may wish to reduce the number of hand-offs of work and reorganize team structure along the lines of services, rather than according to technologies used.

Certain organizations use portfolio boards to integrate work and to provide views of aggregated work items. To the extent that such boards are intended to represent the reality, rather than simulations, it should be clear how software can help ensure the coherence of the presentations and reduce double work.

Easily display different views

A physical kanban board based on a whiteboard has the drawback of being able to display only a single view of the data. Thus, each team requires the physical space for its own kanban board. While this requirement is not necessarily a hardship, given the board’s central importance to kanban, a software implementation allows for displaying a team’s board anywhere there is a screen. Furthermore, it allows for selecting, filtering and formatting data however the viewer might wish to see it. In addition, a single screen might be used to display the kanban boards of multiple teams, either aggregated or one at a time.

Passively capture data

When a team member moves a kanban card from one column to another on a physical kanban board, no data is captured concerning the time of movement. The historical data about the configurations of cards at any single moment in a given column is lost. Such data can be captured automatically and historical situations reconstructed and analyzed if virtual cards are moved about using software. Software allows for easily undoing mistakes.

Assuming that each team member has a personal account on the kanban board tool, all changes can automatically record the identity of who makes changes. This sort of information can be used to analyze resource liquidity and blockages, among other identity dependent issues.

Enforce standards

A software tool can help enforce such standards as data formatting, color coding of kanban cards, the use of avatars and other symbols, and any of the visual representations of information that are central to the kanban method. Remember, though, that while standards might help avoid miscommunication, they can also become constraints that limit a team’s ability to work in the best way it knows how to do.

Improve data integrity

Whenever people must record information manually, a certain percentage of that data may be missing, erroneous or hard to decipher. Software can help eliminate these issues, albeit often at a cost of inflexibility.

Provide access to data at a distance

As mentioned above, a team distributed among several sites or the temporary displacement of team members complicate using the kanban method. Tools can provide access at a distance to data and visualizations, thereby removing certain constraints to effectively using kanban.

Consider using video conferencing as a means for sharing the non-verbal communication of team members. Simply visualizing a board on a screen together with telephony cannot communicate the all-important visual cues that strongly influence the communications of attitudes and beliefs.

Generate analytical and presentation reports

Whether you generate cumulative flow diagrams, lead time histograms, statistical control charts, Marey charts, Sankey diagrams or other types of analysis, there is no question that you will be using software tools to do so. The real question is how those tools provide added value in any of three ways:

reduction in manual labor

reduction in errors

improvement in decision making

Suppose you create your reports by manually copying data from physical kanban cards to a reporting tool, such as a spreadsheet manager. Or suppose you collect that data from a software kanban board but have to extract it manually and import it into that spreadsheet tool. These types of manual tasks are forms of coordination work—work that is not value adding from the customers’ perspective. Integrated reporting or automated ETL tools can both reduce the amount of manual labor as well as reduce the errors that might be introduced during that manual work.

Improvements in decision making might take several forms. First, there is the issue of interpreting a report once it is generated. Suppose you create a lead time histogram. How many people are able to assess visually whether a minor bump in the histogram represents an insignificant variation in data or whether it is indicative of a multi-modal data set? For sure, this is easy if the diagram looks like a dromedary, but how often do such obvious, extreme cases occur?

Or suppose you create a control chart and apply a set of rules, such as the Nelson rules, to distinguish the common cause variation from the special cause variation. Even if the rules themselves are simple to understand, a chart with several hundred data points might require a long period of manual checking of each rule. A software tool could identify and highlight special cause variation almost instantaneously.

Evaluate options and risks

Although there is value in keeping your options for the flow of work open until a decision is truly necessary, it is extremely difficult for humans to evaluate those options and to decide when the last moment for starting work might be. This problem is compounded when the expected lead times are relatively short. The shorter the lead time, the less time you want to spend on deciding what to do and when. Software tools can help by using historical data, making Monte Carlo simulations and proposing the priorities and actions to undertake next. In principle, those decisions could be left to the software if the AI capabilities of the system are sufficiently advanced and there aren’t too many black swan events.

Assessing the value of kanban tools functionality

The purpose of the above list is to suggest ways in which kanban tools might be of value to your organization. Based on your own analysis, there are likely other types of functionality that would be valuable. And perhaps some of these functions would be of no particular value to you, at least at present.

Many organizations are tempted to assess a tool, or a tool set, against a list of the tool’s functionality rather than against the expected value of that functionality. The problem with such an approach is two-fold. Firstly, the weighting they often provide to the functions is arbitrary and not readily comparable from function to function. Secondly, they assess that functionality without reference to how it would be used by the organization.

Use of kanban software functionality is directly related to the maturity of the organization using it. For example, integrating kanban boards is largely useless to an organization where kanban is used by only one or a few teams. Assessing option value does not help unless a team understands why having options are valuable. Automating the creation of analytical reports is of value if the organization understands the purpose of those reports, understands how to use them to make decisions and really makes decisions on that basis.

Dubious reasoning in tool selection

There are various types of disputable reasoning used by many organizations in selecting tools. Kanban software tools are not immune to various problematic approaches. Here are some examples.

Future-proofing???

Some organizations might consider tool functionality against possible future needs. While there is value in tools that might support future needs, this approach has several traps that should be avoided.

First, do you really want to pay today for functionality that you will not use until tomorrow and that you might never use at all? This is especially problematic when the licensing fees for software depend mostly on factors other than functionality, such as on the number of users. In fact, very few kanban software tools differentiate their pricing plans based on the kanban functionality provided. A list of the typical differentiators is provided below:

Differentiator

Description

Number of entities

An entity might be, for example, a kanban card

Number of users

Typically, plans are based on the number of defined users, not the number of simultaneous users. Some products distinguish between view-only users and view-and-update users

Support

Levels of support range from community support through support plans with varying service hours and response times

Platform location

While most products provide only cloud platforms, some also offer private cloud or on-site options

Authentication

Some products offer LDAP integration for user authentication and single sign-on functionality, especially with their “enterprise” plans

Styling

Some products differentiate based on the degree to which objects may be styled

Branding

“Enterprise” plans often allow for the removal of the provider’s logo, replaced by the customer’s logo

Training

Certain plans include various training and on-boarding options

Customization

While some plans allow little or no customization, others allow for the use of web hooks, custom fields, etc.

File import/export

There may be limits to the number of files that can be imported in a period, e.g., for attachments or data importing

Knowledge base/wiki integration

Some products provide knowledge base or wiki integration for their more expensive plans only (this being a rare example of functional differentiation)

Number of boards

Certain products limit the number of kanban boards according to the pricing plan

Storage space

The total storage space for data may be limited

Rules executed per day

With products that offer rule-based automations, the number of rules or the number of times a rule may be executed might be limited in certain pricing plans

Number of metrics reported

Products might limit the metrics reported or the complexity of dashboards and analytical reports

Access rights

While some products only have all or nothing access rights, others might offer different levels of granularity of those rights

As you see, while there are a few cases where different price plans provide significantly different functionality, they are exceptions that prove the rule. The differentiators are mostly constraints on the use of the product, rather than features increasing its fitness for purpose. Whether you are using a free version, a professional version or an enterprise version, very often you get the same functionality, whether they provide value to you or not.

Secondly, given the relative ease with which kanban tools can be configured, it is not really a hardship to change pricing plans or even to change tools, should the maturity of your organization evolve and other tools would provide significantly greater value.

Letting the tool structure your work

I sometimes see organizations that select a software tool on the assumption that the tool’s designer knows more about the work being supported than do the people performing that work. They believe that they can benefit from the “structuring” that the tool could afford them.

Such a belief is diametrically opposed to the agile culture of which kanban is a representative. Someone deciding to use a kanban software tool, on the basis of this reason, is perhaps not yet ready to use kanban.

Allowing teams to manage flow asynchronously

Some organizations might be tempted to use software tools as a way of avoiding spending time on the various cycles of meetings used to manage flow. In particular, a team that has no culture of short, daily meetings may try to avoid spending time on those meetings, believing them to be a waste of time. Software tools do not replace these meetings, but they do allow teams to process their tasks without them.

Using software tools for this purpose indicates a misunderstanding of the purpose and the value of having a team review the status of its work, recognize improvements, identify blockages and take initial steps to unblock work and to make adjustments in the value stream.

Lists of tools

The purpose of this article is not to list available software tools, nor is it to evaluate their individual attributes. Here are some of those lists, without implying anything about their completeness or objectivity. Note that these lists are not always well maintained, containing many products that no longer exist or have been acquired by other companies and rebranded.