Kanban for Managing Systems and Software Development

"Kanban: Successful Evolutionary Change for Your Technology Business" by David J. Anderson is an interesting new book. It describes how to apply age-old Kanban concepts to systems and software development. Kanban is a just-in-time manufacturing process for regulating the flow of production based on market demand. It uses a "pull-system" philosophy of production vs. a "push system" of mass-manufacturing. It was pioneered by the Japanese in the form of the Toyota Production System (TPS), which is also known as lean manufacturing.

Kanban is a set of principles for creating a lean, efficient, and waste-free production flow by limiting work-in- process. Each step of a process is analyzed to determine its optimal rate of production. Constraints or limits are then placed on that process, so that it is not overwhelmed. This makes each process step flow efficiently without slowing down. The net effects of these atomic-level constraints are that the overall end-to-end process is as efficient as possible.

The reported benefits of a Kanban system are high customer satisfaction, stakeholder trust, product quality, productivity, cost efficiency, and employee morale. The two primary benefactors of Kanban are customers and workers. Ultimately, customers get the high-quality products they want, when they need them, and at reasonable prices. Employees or workers are also enabled to work at a ‘sustainable pace.' That is, they work at a flexible pace that's comfortable, meets their personal lifestyles, and doesn't require them to work unreasonable overtime hours.

High technology firms are notorious for burning out their employees with 60 to 80 hour work weeks, unrealistic deadlines, and the threat of termination for lack of performance. Kanban is viewed as happy medium between buyers and suppliers. Firms can meet the market's cycle-time demands in order to remain competitive and employees can work at a reasonable pace and enjoy a good quality of life.

It would be interesting to know if there is a sweet spot or a breakeven point for applying the principles of Kanban. For instance, is there a point when optimal worker morale could compromise market competitiveness? On the other hand, is there a point when raising the level of work-in-process beyond an individual's comfort- zone can enhance market competitiveness? These points will have to be considered when implementing Kanban in the intellectually-intensive industries of Western, free market-style capitalistic economies.

Kanban is independent of the type of systems or software development approach used. It works with traditional plan and document-driven approaches as well as newer agile systems and software development methodologies. It can even work with ad hoc processes. Kanban is a set of principles that acts as a framework, which can be wrapped around any type of organizational process. It is frequently used in conjunction with agile methods, although it has also proven useful in unison with large-scale traditional process frameworks as well.

Kanban is viewed as amethodological, rather than a systems and software development methodology. Its proponents reject its characterization as a new development methodology or even a new type of agile method. It's viewed as a set of operating principles and policies, not as a prescriptive step-by-step development methodology. Kanban is used for adopting a holistic systems-level view of the world vs. a narrowly-focused suboptimal software-level view.

Kanban is an approach for organizational transformation, change management, performance improvement, and quality improvement. It's simple to use and implement and its net effects can result in order-of-magnitude performance improvements. It starts by analyzing an "as-is" process rather than creating a new one. Then, by instituting minor policy changes, existing processes are incrementally refined to yield large-scale performance improvements.

Typical policy changes include limiting the amount of work flowing through the system, limiting the workload on individual processes and people, and creating small buffers when necessary to regulate the flow of production. Shortening iteration cycles from months to weeks and days is also a typical policy change. Preventing processes and people from becoming overwhelmed enables them to do the job right the first time. Well-run Kanban systems yield order-of-magnitude performance improvements in productivity and quality. These in-turn, have the net effect of improving customer satisfaction and stakeholder trust. The overall enterprise benefits by yielding the optimal rate of production with the least amount of resources.

Kanban's success often depends on key principles of agile methods, although it seeks to distance itself from individual systems and software development methodologies. Like Kanban, agile methods are based on a system of values and operating principles, rather than prescriptive step-by-step procedures. These four values of agile methods are customer interaction, teamwork, working software, and adaptability to change.

The best Kanban examples are ones where there is a high-level of collaboration, interaction, communication, cohesion, and trust between customers and developers. Good teamwork is also a key to successful Kanban implementations. Dependency upon the creation of tacit knowledge is essential to Kanban's success, which is a hallmark of agile methods.

Kanban, as applied to systems and software development, was inspired the field of operations theory (see "The Principles of Product Development Flow: Second Generation Lean Product Development" by Don Reinertsen). It is based on six broad principles: 1) focus on quality, 2) reduce work-in-process, 3) deliver often, 4) balance demand against throughput, 5) prioritize, and 6) attack sources of variability to improve predictability. Queuing theory serves as the scientific basis for Kanban and its proponents accuse agile methods of not having a similar mathematical basis.

This makes Kanban a process vs. people-centric view of the world, although customers and developers are the benefactors of a more perfect production process. Agile methods, on the other hand, are a people vs. process- centric worldview, where humans are the benefactors of a more perfect business and market relationship. Psychology, sociology, and human behavior, with a smattering of queuing principles, are the theoretical basis of agile methods.

The optimal systems and software development approach lies somewhere in the middle or the intersection of these two philosophical worldviews. That is, Kanban and queuing theory are good, but they need optimal social interactions to make them successful. Vice versa, agile methods and social interactions are good, but they need optimal production flow-rate analysis to make them successful.

Kanban seeks to stabilize an organizational process before improving it. It assumes that lasting organizational process improvement is only possible by reaching the highest levels of any myriad of maturity frameworks. It often takes decades and inordinate amounts of resources to achieve these levels. The proponents of Kanban certainly don't want people spending decades and unnecessary resources before organizations begin to improve.

Kanban also draws upon principles and practices of agile methods for scaling up to large programs and projects, such as release planning. It recommends the use of multi-level product teams, planning instruments, requirements backlogs, functional hierarchies, and non-functional organizational structures. It is safe to say that Kanban, as applied to systems and software development, heavily draws upon the principles and practices of agile methods.

"Kanban" by David J. Anderson is a sorely-needed addition to the field of systems and software development. It basically translates advanced principles of product development flow into a set of pragmatic operating principles for today's high-technology organizational leaders. Kanban definitely deserves further analysis and attention.

Kanban is worth considering whether it's a unique approach to organizational transformation and change, a lens for viewing organizations from a systems point of view, or an incremental improvement to the theory of agile systems and software development. The energy and enthusiasm of its proponents is contagious, Kanban case studies are impressive, and its translation into pragmatic operating principles is finally here. "Everything in moderation is good" and the systems and software engineering body of knowledge will certainly benefit from adapting its principles.