Kanban (Development)

Prince2 Certification
Image by/from Andy Carmichael

Kanban (Japanese 看板, signboard or billboard) is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.

Work items are visualized to give participants a view of progress and process, from start to finish—usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.

In knowledge work and in software development, the aim is to provide a visual process management system which aids decision-making about what, when, and how much to produce. The underlying Kanban method originated in lean manufacturing, which was inspired by the Toyota Production System. Kanban is commonly used in software development in combination with other methods and frameworks such as Scrum.

David Anderson’s 2010 book, Kanban, describes an evolution of the approach from a 2004 project at Microsoft using a theory of constraints approach and incorporating a drum-buffer-rope (which is comparable to the kanban pull system), to a 2006-2007 project at Corbis in which the kanban method was identified. In 2009, Don Reinertsen published a book on second-generation lean product development which describes the adoption of the kanban system and the use of data collection and an economic model for management decision-making. Another early contribution came from Corey Ladas, whose 2008 book Scrumban suggested that kanban could improve Scrum for software development. Ladas saw Scrumban as the transition from Scrum to Kanban. Jim Benson and Tonianne DeMaria Barry published Personal Kanban, applying Kanban to individuals and small teams, in 2011. In Kanban from the Inside (2014), Mike Burrows explained kanban’s principles, practices and underlying values and related them to earlier theories and models. In Agile Project Management with Kanban (2015), Eric Brechner provides an overview of Kanban in practice at Microsoft and Xbox. Kanban Change Leadership (2015), by Klaus Leopold and Siegfried Kaltenecker, explained the method from the perspective of change management and provided guidance to change initiatives. A condensed guide to the method was published in 2016, incorporating improvements and extensions from the early kanban projects.

The diagram here shows a software development workflow on a Kanban board. Kanban boards, designed for the context in which they are used, vary considerably and may show work item types (“features” and “user stories” here), columns delineating workflow activities, explicit policies, and swimlanes (rows crossing several columns, used for grouping user stories by feature here). The aim is to make the general workflow and the progress of individual items clear to participants and stakeholders.

As described in books on Kanban for software development, the two primary practices of Kanban are:

Four additional general practices of Kanban listed in Essential Kanban Condensed, are:

The Kanban board in the diagram above highlights the first three general practices of Kanban.

Kanban manages workflow directly on the Kanban board. The WIP limits for development steps provide development teams immediate feedback on common workflow issues.

For example on the Kanban board shown above, the “Deployment” step has a WIP limit of five (5) and there are currently five epics shown in that step. No more work items can move into deployment until one or more epics complete that step (moving to “Delivered”). This prevents the “Deployment” step from being overwhelmed. Team members working on “Feature Acceptance” (the previous step) might get stuck because they can’t deploy new epics. They can see why immediately on the board and help with the current epic deployments.

Once the five epics in the “Deployment” step are delivered, the two epics from the “Ready” sub-column of “Feature Acceptance” (the previous step) can be moved to the “Deployment” column. When those two epics are delivered, no other epics can be deployed (assuming no new epics are ready). Now, team members working on deployment are stuck. They can see why immediately and help with feature acceptance.

This workflow control works similarly for every step. Problems are visual and evident immediately, and re-planning can be done continuously. The work management is made possible by limiting work in progress in a way team members can see and track at all times.

Get More PRINCE2 Information by Clicking HERE

Lean Project Management

Prince2 Certification
Image by/from WikiMedia Commons

Lean project management is the application of lean concepts such as lean construction, lean manufacturing and lean thinking to project management.

Lean project management has many ideas in common with other lean concepts; however, the main principle of lean project management is delivering more value with less waste in a project context.

Lean Project Management applies all five of those principles to project management.

“Lean” is a systematic method for the elimination of waste (“Muda”) within a manufacturing system. Lean also takes into account waste created through overburden (“Muri”) and waste created through unevenness in work loads (“Mura”). Working from the perspective of the client who consumes a product or service, “value” is any action or process that a customer would be willing to pay for.

Lean approach makes obvious what adds value by reducing everything else which does not add value. This management philosophy is derived mostly from the Toyota Production System (TPS) and identified as “lean” only in the 1990s. TPS is renowned for its focus on reduction of the original Toyota seven wastes to improve overall customer value, but there are varying perspectives on how this is best achieved. The steady growth of Toyota, from a small company to the world’s largest automaker, has focused attention on how it has achieved this success.

In general, a project can be said to be Lean if it applies the principles of lean thinking.. There are, however, different implementations of this idea that don’t necessarily apply all of the principles with equal weight.

Two well-known types are “Kanban” and “Last Planner System”.

The term Kanban comes from manufacturing but was adapted for software development by David Anderson when he was working at Microsoft in 2005 and inherited an underperforming maintenance team. The success of the approach in that environment, led Anderson to experiment with Kanban in projects, with similarly positive results. As Anderson publicised his findings through talks and his book , software developers began to experiment with Kanban and it is now one of the most widely used methods for managing agile software development projects.

The Last Planner System is used principally in construction and particularly focuses on pull and flow but perhaps more important than those is its emphasis on a collaborative approach in which all trades work together to create a visual representation of the work that needs to be done.

Get More PRINCE2 Information by Clicking HERE