Kanban Development Process

Last reviewed: February 2017

Abstract

The Kanban (pronounced KAHN-BAHN) development system represents a methodology for designing and then directing the complex process in which a team of like-minded but not like-talented computer software engineers shepherd an idea from development stages to final launched product. By applying a tight control process model (one derived from the methods of industrial plant operations from the mid-twentieth century) that compels the team and its project manager to think collaboratively in discrete but related steps, the Kanban development process offers contemporary information systems management an agile and flexible model for completing a software design project with maximum efficiency.

Overview

Taiichi Ohno and Toyota. The theoretical foundation of the Kanban development process rests on two premises basic to any organization: understand what is being done and understand that a company is a team. Without those guiding principles, no organization can maintain efficiency and stay in operation. In the mid-1950s, in an era when American car companies dominated international markets and Japanese cars were popularly seen as cheaply made and poorly designed, Taiichi Ohno (1912-1990), an industrial engineer whose background and education were in operations management, not automobile design, was hired by the Toyota company to revamp its plant operations, at the time widely perceived to be inefficient.

Toyota was plagued with bottlenecks in the assembly line process; different departments and divisions would not clearly communicate; steps in the actual automobile assembly were inconsistent and dysfunctional; corporation executives were out of touch with day to day plant operations. Some car lines were being overproduced way ahead of sales expectations; some popular lines significantly underproduced.

Without overarching organization, any industrial plant faces inevitable confusion (Faccio, Gamberi & Persona, 2013). Quietly, Ohno revolutionized Toyota production protocols by essentially creating what has come to be called the Kanban process. Drawing on the deceptively simple philosophical positions of Zen Buddhism and Ohno’s own admiration for the basic layout of an American supermarket, Ohno conceived of a factory that valued steadiness, direction, and flow. He envisioned a collaborative process designed to move the product through the process cleanly and steadily. The process has since been applied to virtually every sort of industrial plant and service industry (Thomas & Lev, 1989).

“Kanban” means (loosely) a billboard or more specifically a very large card. At the core of Ohno’s perception of plant operations was a simple visual device: a dry erase board or a simple cork message board (Rousmaniere, 2015). The board always begins blank. A company first looks at what is being done currently. Ohno believed that work should flow, that a process as complex and as abstract as car production could be (in fact needed to be) broken down into its basic elements or stages and those stages posted visually to give all the production line managers a chance to see the process concretely. The board is divided into three simple columns: TO DO; IN PROGRESS; and DONE. According to Ohno, if a process could be directed into those basic stages, the process itself could run efficiently because the entire team would be seeing the same process. If a bottleneck developed in one area, the team would see that and efficiently review the process at that point and redesign the elements to return the process to an appropriate flow. Demand drove the process.

Indeed, for Ohno, bottlenecks were the demons in any system. He focused particularly on the IN PROGRESS stage. He argued that whatever the system was engaged in producing, it should be limited to three or four elemental stages, each one a simple verb and a simple noun. Conceive of the operation in its simplest terms. Work with fewer units. Work in shorter periods of time. Limit each stage to smaller units of time. Involve fewer decision makers. Rely on care and precision of production rather than bulk. It was a revolutionary concept; to an industry that had grown so big and so involved, Ohno argued for quality, not quantity.

Ohno conceived of industrial management as a related process of simple steps designed to eliminate waste. If, for example, a company is engaged in producing ladies’ hats with a decorative feather, that would be the TO DO stage. The IN PROGRESS stage would represent the bulk assemblage processes and would itself be divided into four stages: In stage one, the worker would pull the hat units from the delivery boxes; in stage two, the worker would cut, wrap, and attach the ribbon to the hat; in stage three, the worker actually affixed the feather; and in stage four, the hat would be tested for quality control. If the production assembly were to back up at some point during the IN PROGRESS stage, the production management team would break it down into its elements to find where the clog was happening. Then entire process would be redesigned to move product into the final DONE stage.

The turnaround in Toyota was historic. Within four years of implementing Ohno’s vision, Toyota became the most successful non-U.S.-based car company in the world.

Kanban in the Digital Age. With the revolution in digital communications and information networking in the mid-1980s, an entire field of software development was created within a scant single decade. The most promising and creative minds in software design joined into computer engineering firms in which the newer application of existing computer technology made the most cutting edge computer devices obsolete within a single sales quarter. Companies rushed to convert existing operations into the far more streamlined and efficient operations that used new generation software applications.

Governments, schools, factories, hospitals, banks, transportation systems—every organization, from local corner businesses to global conglomerates—clamored for operating systems just to stay competitive and viable. Computer technology quickly became a non-optional component of a business plan. The demand for newer and more efficient and more inclusive software rose to unprecedented dimensions. Software development firms rushed apps to market sometimes with only the most rudimentary testing; systems coders, those computer engineers actually responsible for designing the basic algorithms of the computer program, worked long hours to create products that could be immediately launched. Back orders for new software were stacked; by the time companies completed work on a program the conceptual template itself would be near obsolete.

The sheer bulk of the demand created untenable pressures on the development field largely because colleges and trade schools could not provide sufficient numbers of qualified personnel. Production lines were careless and casual; new software products were rushed to market; meanwhile, computer software CEO’s, interested in creating buzz and generating investor interest, publicly held out tantalizing promises for visionary software yet to be coded; productivity staggered, hobbled by redundancy, inefficiency, and waste. Expectations, nevertheless, were unbounded, the market all too open and all too waiting; the software firms themselves were overworked and their production processes uncoordinated and inefficient. In short, by the last decade of the millennium, the software industry was itself prepped to discover what the broader industrial world had discovered nearly a generation before: the operational logic of Kanban.

Designing software is almost by definition abstract. Software engineers, charged with particular ideas or requests from clients, must conceive in their heads of how a computer program might be coded to address those needs. Engineers must perforce think outside the box—the request itself testifies that current technologies are inadequate and must be pushed into new directions. Software engineers are temperamentally accustomed to thinking in conceptual terms, and information systems are by definition virtual. The process is further complicated because software development cannot be accomplished through the efforts of a single entity, a single person who carries the idea from concept to code to testing to launch. Information system development is a team concept.

For all its technological sophistication (or maybe because of its technological sophistication), then, software engineers and information systems technicians needed to return to the basics, to conceive of the complicated and abstract process of creating a functioning app as in its core identical to any factory system geared to produce any tangible product—that is, as a cooperative system directed by a team of specialists, cross functional, but whose individual contributions needed to be coordinated and worked into a single process or flow (Majer, 2014).

Further Insights

Information systems development turned to the Kanban template: Everything began with a blank dry erase board, a visual of the process (Jou Lin, Frank Chen & Min Chen, 2013). The software system and its development would be conceived as a staged process, a system of connected boxes visualized on a dry erase board that was itself divided into the three traditional columns that Ohno had originally proposed: TO DO, IN PROGRESS, DONE. The board organized the entire production process, coordinated its execution, and ultimately unified the team.

The information system process is divided into two broad phrases: lead time and cycle time. Lead time refers to the absolute process from its idea to its production. The goal of the Kanban development system is to make this as short as possible without skimping on quality—that is, without getting sloppy or cutting design corners. In the highly competitive software systems market, a reputation for shoddy workmanship and careless systems design can quickly drive a company into financial troubles.

“Cycle time” refers to the particular stages of the process itself—that is, the IN PROGRESS steps that organize the core of the Kanban. General preference is to keep steps to a minimum number to increase efficiency and to focus the work. In informational systems management generally, there are primarily four steps that need to be completed: (1) development—the initial meeting with the client and the review of their ideas and the general sketching of the specifications the new system would be expected to perform; (2) coding—the actual hands-on computer instructions written by software engineers who meticulously design the line by line code that will direct the computer to perform the conceptualized tasks; (3) testing—the software prototype being checked in limited function not only to determine its level of usability but its design strengths, its user-friendly appeal, its reliability, and its speed of operation; and (4) production—the launch of the product into the virtual marketplace or set up within with a business’s complex of already existing operational platforms.

Because of the work flow, the ultimate product theoretically will not have features that are not needed, computer programmers will not develop specifications that are not required, the engineers will not write code that is not part of the overall design, and all the original code will be tested before the product is rolled out and subsequently launched. The bugs will have been worked out. Thus, problems are detected in process, in real time; computer engineers then work with code writers, who in turn work with the production technicians, who work with the design engineers. The product is conceived as a team construction—and that process is defined and tracked and contained on a dry erase board.

Viewpoints

Kanban has been dismissed by some critics as being a better theoretical template than an actual process. Indeed, the principal objection to Kanban, whether applied to automobile assembly or computer software design, is that it creates by definition an unstable manufacturing process. Stability, for Ohno, ensures only the status quo. By design, the middle stage—the critical IN PROGRESS steps—are deliberately under constant review as a way to make sure the process runs as efficiently as possible. That means that the engineers are always returning to the development looking for redundancies, wasted time, inefficiencies, areas where the prototype may not entirely meet the specifications. If the software needs to be refined, if the gadget needs to be recalibrated, if the application needs to be made more user-friendly, if the app is burdened with unnecessary code, the team understands this before the product moves into testing. Problems are detected and resolved along the way.

In keeping with a system grounded in Zen Buddhism, the concept here is deceptively simple: engineers do not pretend to contain or control all the elements of the production, but rather the team watches, responds, returns to the process in a protocol that is, in turn, leaner, cleaner, and more agile. Under the theoretical model of the Kanban system, a team is no longer what it was traditionally: a group of people under the direction of a single manager. Rather here the group is a team, each with a responsibility, each with a specialized skill, and each an integral part of the process (Majer, 2013). One product, one team, one process—from idea to launch, information systems are maintained within a tight, efficient, and clean development protocol in which every worker contributes and is rewarded with a feeling of commitment and achievement.

Terms & Concepts

Cross Functional: A team in which members share some similar expertise, background, and/or education and thus can help and support the work of other team members.

Cycle Time: The time planned for each step in the development process.

Feedback: The process through which a software system under construction can be reviewed and response in turn fed back to the team to help move the process to successful completion.

Launch: A term used to designate the end point of the development of an information system, app, or software program.

Lead Time: The total time conceived by the information system team to complete a new program.

Specifications: The proximate conceptuals the client envisions for software or an app.

Work Flow: The total sum process through which a product or service is delivered to a client or customer.

Bibliography

Faccio, M., Gamberi, M., & Persona, A. (2013). Kanban number optimisation in a supermarket warehouse feeding a mixed-model assembly system. International Journal of Production Research, 51(10), 2997–3017. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=86746174&site=ehost-live

Jou Lin, C., Frank Chen, F., & Min Chen, Y. (2013). Knowledge kanban system for virtual research and development. Robotics & Computer-Integrated Manufacturing, 29(3), 119–134. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=85396450&site=ehost-live

Lolli, F., Gamberini, R., Giberti, C., Rimini, B., & Bondi, F. (2016). A simulative approach for evaluating alternative feeding scenarios in a kanban system. International Journal of Production Research, 54(14), 4228–4239. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=118193655&site=ehost-live

Majer, C. (2013). Six silent killers of productivity and profitability. PM World Journal 2 (11), 1–9. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=91904594&site=ehost-live

Majer, C. (2014). Wastes in the modern world: The silent killers of productivity and profitability. Employment Relations Today, 41(1), 19–25. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=95576805&site=ehost-live

Millstein, M. A., & Martinich, J. S. (2014). Takt time grouping: Implementing Kanban-flow manufacturing in an unbalanced, high variation cycle-time process with moving constraints. International Journal of Production Research, 52(23), 6863–6877. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=99207966&site=ehost-live

Rousmaniere, D. (2015). Project manage your life. Harvard Business Review Digital Articles, 2–7. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=118666568&site=ehost-live

Thomas, P., & Lev, B. (1989). Kanban: Just-in-time at Toyota: Management begins at the workplace. Interfaces 19 (6), 113–114. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=4488985&site=ehost-live

Suggested Reading

Hammarberg, M., & Sundan, J. (2014). Kanban in action. Greenwich, CT: Manning.

Lei, H., Ganjeizadeh, F., Jayachandran, P. K., & Ozcan, P. (2017). A statistical analysis of the effects of Scrum and Kanban on software development projects. Robotics & Computer-Integrated Manufacturing, 43, 59–67. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=118357616&site=ehost-live

Lianyi, Z., Qingdi, M., & Guiming, L. (2016). Verification of lean-Kanban processes with probabilistic model checking. International Journal of Computer Applications in Technology, 53(4), 358–368. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=118016033&site=ehost-live

Papalexi, M., Bamford, D., & Dehe, B. (2016). A case study of Kanban implementation within the pharmaceutical supply chain. International Journal of Logistics: Research & Applications, 19(4), 239–255. Retrieved October 23, 2016, from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=118193065&site=ehost-live

Skarin, M. (2015). Real-world Kanban: Do less, accomplish more with lean thinking. Boston, MA: O’Reilly Media/Pragmatic.