Many organizations use issue tracking systems to identify, capture, and authorize the work requests that should be processed by a system. These system may be of many types, including a team manufacturing a product, a team fulfilling orders, or a team which is sustaining a software-intensive system. Nearly always, some priority scheme exists to signal the importance of each request.
- Critical requests describe work that must be acted on immediately, because the system is unusable, has or will suffer information loss, is exposed to security vulnerabilities, or is undergoing serious performance degradation.
- Major requests have significant repercussions on overall system features, performance, or workflow, and may require prototyping and exploration in order to finalize the definition or configuration of candidate solutions. These issues are usually targeted for a specific, planned release.
- Normal issues typically affect a specific set of functionality, do not leave the system completely unusable, and have limited coupling with other system elements. Workarounds typically exist for such issues until they can be addressed.
- Minor issues address cosmetic issues that don't inhibit the functionality or main purpose of a system, such as correction of typos in code comments or white space issues.
In practice, these signals often provide little information to help balance supply and demand.
The importance of evaluating the value and cost of performing each individual work item is often not evaluated on a periodic basis, though in practice both inevitably change with time. This is because work requests presume that the environment in which the reporting or authorization was originally recorded is static, even though this assumption is highly unlikely. In practice, over-reliance on such prioritization schemes nearly always result in queues of work which build up. As these queues and backlog grow, the utility of the ranking among individual items deteriorates, while the effort to manage this inventory increases. Further, such designations may not effectively communicate that:
- An issue's urgency for resolution may be entirely dependent on being ready by a deadline, and thus may be more urgent than work already underway
- An issue's priority may be different than its severity, which is the impact the problem has on certain stakeholders
- The time it will take for an acceptable solution to be developed, given available resources at any particular point in time
In the face of this growing inventory, the leaders of an organization often enforce rules of 'incumbents' (a freeze on new work), or re-evaluation (which may not produce any better estimates of how long things will really take. They will usually also require increased visibility of this work in process and inventory. One way this often is provided is through work in process boards, which attempt to make the progress on active work more visible. Considerable effort is often expended in managing this inventory (often in costly meetings), as more and more people are brought together to discuss new requests, negotiate priorities, provide status, and generally vent frustration over how long it takes to actually perform the work. Meanwhile, delays erode the potential value which can be realized from actually delivering results from the work.
A kanban system is a fundamentally different way to prioritize and track such work. It is a work processing system which provides visual indicators of the work as it flows through a system. The kanban system adds several important features to those offered by traditional change management system:
- Limits are placed on the work in process that are allowed into each processing stage; the work in each of these stages is the work in process in that stage.
- Work is 'pulled' to columns on the right from the immediately preceding column on the left based upon the stated intentions or specific direction of the customer
- As bottlenecks become apparent, they become the focus of improvement activities by the team
Kanbans thus help groups to self-organize and implement a form of pull systems, in which each responsible workcell will accept work as there is capacity to handle it. These systems are frequently employed in lean production systems. One of the unique characteristics of knowledge workers that distinguishes it from such production systems is that knowledge workers initially do not really know what they are capable of, or what is really being asked of them:
- work is highly variable in what it takes to do
- some aspects of the work may impede making progress
- the interrelationships of the work are not visible
- everyone is trying to work on everything
- the resulting multitasking erodes efficiency
One of the most accessible sources of information about these techniques is in the book of the same name, Kanban, by David Anderson. David is clearly one of the primary thought leaders in applying kanban techniques to managing the flow of work through a software organization. David originally developed these techniques at Corbis in Seattle. Since then, he has started his own consulting business, written this book, and has organized an industry consortium which focuses practical experiences utilizing all [wlean software development] techniques (The Lean Software and Systems Consortium), and the consortium's annual conferences have been attended by thousands of practitioners by leading software companies around the world.
Kanbans are often implemented within an agile environment, such as a development organization which uses scrum development practices. David describes how the idea of scrum
Typically Scrum teams went form four weeks to two weeks and Extreme Programming teams from two weeks to one week.... It can be difficult to analyze work into small enough units to get it done within the available time window... Reducing variability requires people to change their behaviors and learn new skills. Teams... struggle to write user stories consistently small enough to fit into small, time-boxed iterations. This often leads to several dysfunctional behaviors... The first is to reverse the trend to smaller iterations and go back to larger ones... The alternative is to write stories that are focused on elements of the architecture or some technical decomposition fof the requirements... A second alternative is to break the story across three iterations in phases... [These] make a mockery of the notion of time-boxed iterations and disguise the fact that work is actually still in progress when it is reported as completed... Kanban decouples... prioritization and lead time for development from a delivery cadence.
For a good overview of the differences between the use of Kanban and Scrum techniques, see this article.
I attended a seminar by one of Corbis's managers, Darren Davis. The seminar discussed how Corbis uses kanban techniques in detail. Corbis uses Service Level Agreements (SLAs) that document the throughput which they have committed to their customers for their sustainment requests. Any visual control like a kanban should be used to help achieve important business outcomes; kanbans are a means to that end. If Corbis does not deliver on these commitment, there are significant finanical consequences to their business.
The Corbis work groups must manage a variety of assignments and priorities to be successful, including change requests, problem reports, maintenance requests, and hot fixes, in order to support these SLAs. Servicing these requests at prescribed rates and flow times are key to meeting these SLAs. Some of these work items are date dependent, and some are not; it is their overall job mix, and the natural issues and constraints that are encountered as they attempt to implement these jobs, which must be managed effectively and efficiently in order to achieve the throughput necessary to accomplish these business goals. In order to understand the mechanics of how kanbans are used in practice, see this article.
The underlying premise of Kanbans is that it is only possible to discover what each work cell's capacity is, once the work cell has limited the number of tasks they attempt to work on at the same time. When demand exceeds capacity, there will likely be a backlog of requests for service which accumulate. With kanbans:
- This backlog of the requests will be made more visible
- Fewer people will be spending their time managing this inventory of work, and thus more time will be available to actually act on the requests
- There will be a basis to measure how much time is being spent on each task.
- Tasks will get finished faster.
David reminds those with the courage to pursue such goals that "Introducing a radical change is harder than incrementally improving and existing one". With that in mind, he offers a formula for successfully implementing Kanban:
- Focus on quality - a technical discipline that can be attacked by the functional manager.
- Perform prioritization according to costs of coordination, transactions, and organizational maturity (this may mean using on-demand or periodic ordering, depending upon each situation)
- Reduce work-in-process
- Increase cadence to deliver more frequently
- Establish consensus on balancing demand against throughput
- Attack sources of variability
Realize these goals require agreements and collaboration with other teams, and skills in articulation, negotiation, psychology, sociology, and building trust.
Dave's book provides a practical and accessible introduction to using a Kanban in an engineering environment. His book's cover articulates the problems which kanbans seek to solve at the level of individuals work groups, who often find themselves in one of three conditions: "I'm stuck", "I'm too busy", and "I'm idle". David's book offers readers the chance to find a way do something about each.