Kanban

Review

The seminal book on Kanban for software development is still a sound foundation on the matter. Indeed, it is the best book on Kanban to date. This is easily justified by the fact that David Anderson explains Kanban through the original implementations of the method.

Anderson starts the book telling his motivations for solving the Agile manager’s dilemma: how to scale agility in large organizations and how to achieve a sustainable pace? The author tells his professional history back at Sprint PCS (which became a Motorola-owned company) where he was persuaded to influence other teams without success. His conclusion was that prescriptively enforcing a software development process on a team doesn’t work. Every situation is unique (organizations, teams, and projects are different) and this creates resistance to change.

The stories are very interesting as they resonate easily in every software development professional. They are about derailing projects in the hands of teams with low morale. However, the outcomes are even more interesting: the Microsoft case had a 200% productivity boost and 90% lead time reduction. At Corbis (chapter 5), a strong continuous improvement culture emerged (and the documented Kanban Method in the book).

In both cases, a uniquely tailored process was created for each context. This emergent Lean behavior is due to the application of the Core Practices of Kanban: Visualize Workflow, Limit WIP, Measure and Manage Flow, Make Process Policies Explicit and Use Models to Recognize Improvement Changes.

Then the book goes on with a practical explanation on how to adopt Kanban. The chapters 6 (Mapping the Value Stream), 10 (Setting Work-in-Progress Limits), 12 (Metrics and Management Reporting), 16 (Three Types of Improvement Opportunity) and 17 (Bottlenecks and Non-Instant Availability) are enlightening and the author succeeds in adapting all these practices and explaining them in a seemingly logical progression.

If you want to adopt Kanban, this is the book to start. You will understand the motivations that drove the evolution of the method from the pioneer’s perspective. Then look for fresher references, since the method evolved since then. The Core Practices (Chapter 3) were refined, the Foundational Principles were introduced and the System Thinking Approach to Introducing Kanban replaced the Recipe for Success (Chapter 3). Kanban from the Inside (the parts I and III) and Real-World Kanban are good follow-up readings.

The drawback on the Kindle edition are the low-resolution pictures of Kanban boards.

Some quotes

In the remainder of this book I describe Kanban (capital K) as the evolutionary change method that utilizes a kanban (small k) pull system, visualization, and other tools to catalyze the introduction of Lean ideas into technology development and IT operations. The process is evolutionary and incremental. Kanban enables you to achieve context-specific process optimization with minimal resistance to change while maintaining a sustainable pace for the workers involved.

In many ways, knowledge work is the antithesis of a repetitive production activity. Software development is most certainly not like manufacturing. The domains exhibit wildly different attributes. Manufacturing has low variability, while much of software development is highly variable and seeks to exploit variability through novelty in design in order to drive profit.

As should become evident in subsequent chapters, we use a kanban system to limit a team’s work-in-progress to a set capacity and to balance the demand on the team against the throughput of their delivered work. By doing this we can achieve a sustainable pace of development so that all individuals can achieve a work versus personal life balance. As you will see, Kanban also quickly flushes out issues that impair performance, and it challenges a team to focus on resolving those issues in order to maintain a steady flow of work.

Collaborative analysis and design improve quality. When teams are asked to work together to analyze problems and design solutions, the quality is higher. I encourage teams to hold collaborative team analysis and design modeling sessions. Design modeling should be done in small batches every day. Scott Ambler has called this Agile Modeling.

There is causation between quantity of work-in-progress and average lead time, and the relationship is linear. In the manufacturing industry, this relationship is known as Little’s Law. The evidence from these two teams at Motorola suggests that there is a correlation between increased lead time and poorer quality. Longer lead times seem to be associated with significantly poorer quality. In fact, an approximately six-and-a-half times increase in average lead time resulted in a greater than 30-fold increase in initial defects. Longer average lead times result from greater amounts of work-in-progress.

Reducing work-in-progress, or shortening the length of an iteration, will have a significant impact on initial quality. It appears that the relationship between quantity of work-in-progress and initial quality is non-linear; that is, defects will rise disproportionately to increases in quantity of WIP.

Complexity in knowledge-work problems grows exponentially with the quantity of work-in-progress. Meanwhile, our human brains struggle to cope with all this complexity. So much of knowledge transfer and information discovery in software development is tacit in nature and is created during collaborative working sessions, face-to-face. The information is verbal and visual but it’s in a casual format like a sketch on a whiteboard. Our minds have a limited capacity to store all this tacit knowledge and it degrades while we store it. We fail to recall precise details and make mistakes. If a team is co-located and always available to each other, this memory loss can be corrected through repeated discussion or tapping the shared memory of a group of people. So agile teams co-located in a shared workspace are more likely to retain tacit knowledge longer.

Recently, it’s become popular in the Agile community to talk about business-value optimization and how the production rate of working code (called the “velocity” of software development) is not an important metric. This is because business value delivered is the true measure of success. While this may ultimately be true, it is important not to lose sight of the capability maturity ladder that a team must climb. Most organizations are incapable of measuring and reporting business value delivered. They must first build capability in basic skills before they try greater challenges.

By this time the team had reduced the lead time to an average of 14 days against an 11-day engineering time. The due-date performance on the 25-day delivery time target was 98 percent. The throughput of requests had risen more than threefold, while lead times had dropped by more than 90 percent, and reliability improved almost as much. No changes were made to the software development or testing process.

In Japanese, the word kaizen literally means “continuous improvement.” A workplace culture where the entire workforce is focused on continually improving quality, productivity, and customer satisfaction is known as a “kaizen culture.”

Adopting Kanban should change the culture of your organization and help it mature. If the adoption is done correctly, the organization will morph into one that adopts change readily and becomes good at implementing changes and process improvements.

Adopting Kanban is an investment in the long term capability, maturity, and culture of your organization. It is not intended as a quick fix.

The physical board had a huge psychological effect compared to anything we got from the electronic tracking tool we used at Microsoft. By attending the standup each day, team members were exposed to a sort of time-lapse photography of the flow of work across the board. Blocked work items were marked with pink tickets, and the team became much more focused on issue resolution and maintaining flow. Productivity jumped dramatically.

Kanban WIP limits enable “stop the line” behavior. Kanban WIP limits encourage swarming to resolve problems.

Another school of thought takes a different approach. It suggests that rather than implement loose WIP limits to avoid a challenging introduction of the system, each stage should be buffered, and the activity steps should have tight limits. Bottlenecks and variability will reveal themselves by how full the buffers become. Small, simple changes can then be made to reduce buffer sizes and then eventually you can eliminate unnecessary buffers.

Particularly in highly innovative and experimental work, there may be several activities that need to happen with a piece of customer-valued work, but those activities do not need to happen in any particular order. In these circumstances, it is important to realize that Kanban should not force you to complete the activities in a given order. What is most important when modeling your kanban system is that it must reflect the way the real work is done.

So standups take a different format with a kanban system. The focus is on flow of work. The facilitator, typically a project manager or a line manager, will “walk the board.” The convention has developed to work backward—from right to left (in the direction of pull)—through the tickets on the board. The facilitator might solicit a status update on a ticket or simply ask if there is any additional information that is not on the board and may not be known to the team. Particular emphasis will be placed on items that are blocked (have a pink ticket attached) or delayed due to defects (have a series of blue tickets attached). Questions may also be asked about items that appear to be stuck and have not moved for a few days.

A good rule of thumb might be that if the backlog exceeds three months’ worth of work, that is, three months of delivery throughput, and all the items in the backlog cannot enter the system within that time, it would be a good idea to prune the backlog.

Kanban still delivers on the Principles Behind the Agile Manifesto19. However, Kanban avoids any dysfunction introduced by artificially forcing things into time-boxes.

By avoiding detailed estimates as much as possible, the transaction costs are minimized, which facilitates more frequent prioritization meetings.

The sizing of the buffer is important. Again, you want it to be as small as possible. Buffers and queues add WIP to your system and their effect is to lengthen lead time. However, buffers and queues smooth flow and improve the predictability of that lead time. By smoothing flow, they increase throughput, so more work is delivered through the kanban system. Buffers also ensure that people are kept working and provide for greater utilization. There needs to be balance, and buffers help maintain it.

Queue and buffer sizes should be adjusted empirically as required. Hence, do not fret over a decision to establish a WIP limit. Do not delay rollout of your kanban system because you can’t agree on the perfect WIP-limit numbers. Choose something! Choose to make progress with imperfect information and then observe and adjust. Kanban is an empirical process.

Commitments in Kanban are made against lead time and target delivery dates. Throughput may be used on larger projects to indicate the approximate time to completion with appropriate buffering for variation.

Although our main goal with Kanban is to introduce change with minimal resistance, there must be other goals. Change for the sake of change is pointless. These other goals should reflect genuine business needs such as high-quality, predictable delivery.

Kanban does not offer a commitment on a certain amount of work delivered on a certain day. It offers a commitment against the service-level agreements for each class of service, underpinned with a commitment to reliable regular delivery, transparency, flexibility on prioritization and processing, and continuous improvement on quality, throughput, frequency of delivery, and lead time.

The five elements—WIP, prioritization, delivery, classes of service, and lead time—provide levers that can be pulled to affect the performance of the system. The skill is in knowing how to pull those levers and how to trade off options to devise an agreement that will work effectively.

In general, any form of meeting is a coordination activity, including favorites of the Agile community, such as daily standup meetings, unless the meeting is designed to produce a customer-valued deliverable. If three developers get together at a whiteboard and model a design for code they are about to implement, this is not a coordination activity, it is a value-added activity. Why? It is valued-added because it produces information that builds toward a complete customer-valued function.

The process definition in use on your team, expressed as policies, represents the rules of the collaborative game of software development.

Early literature describing the Extreme Programming method explained user stories as a narrative description of a feature as implemented and used by an end user, written on an index card. The only constraint was the size of the card. The effort required to create a user story was described as anything from a half-day to 5 weeks of work.

By aligning all the groups up and down the value stream with the same goals, there is an incentive for swarming behavior to emerge. Everyone wins when idle people volunteer to collaborate to resolve an issue that affects them even though it is not in their immediate work area or area of responsibility.