Kanban in Project Management

Revision as of 12:45, 16 September 2016

*** work in progress - some sources are still missing and of course the list in the end, so no need to comment on this :) ***

Kanban(看板 signboard from Japanese) aims to provide visibility, highlight bottlenecks and improve communication and work flow throughout a project, a process or similar. The Kanban system was originally an inventory control system developed by Taiichi Ohno, an industrial engineer at Toyota. The vision then was that the system would reduce the waste (muda) in the production line and improve the manufacturing efficiency. Kanban is a flowcontrol system for pull-driven JIT (just-in-time) production, the upstream processing activities are triggered by the downstream demand signals[1][2]. The Kanban system is now, with some alterations, applied as an agile project management tool. It is argued that the system offers improved project visibility, product quality, team-motivation, communication and collaboration[3].

The basis of the Kansan system is to have a board with cards attached. Different parts of the board represent different stages of the development which all work items go through. The cards represent the different work items in the project, and move from left to right on the board. The board and the cards can be arranged and divided however the user would like. Nonetheless the main concept of Kanban is always the same, and can be summarized by these six points[4]:

1. Limit WIP (work in process): The board is divided in parts, and each part can only have a pre defined number of work items, WIP limit, thus this don't need to be the same for every part. This is true for all parts except the “backlog” and “done” part, which is always unlimited
2. Cards : Each work item is represented by a card (sticky note or similar)
3. Flow: The work items on the board are moved from left to right between the different parts. The person performing the work, is also the one moving the card
4. Team: The team working with the Kanban board agree on some rules for when the cards can be moved
5. Kaizen (constant improvement)

   • The team working with the Kanban board have to get together on a regular basis to analyze the flow, focusing on work items that are stuck on the board
   • There is no Kanban police - and if you need to alter the board or break the rules that's ok, but inform the rest of your team

Kanban in Project Management

Figure 1: Five Stages of Project Management

The goal of project management is to improve the total quality of project results. This include on time delivery, stakeholder satisfaction and financial results.[5] In otder to do so one have to poperly execute the five processes of project management, see figure 1.

The Kanban project management tool can help in regards of the planning, executing and monitoring and controlling aspect of project management by solving the questions stated below.

• How can workflow be visualized in real time?
• How can team members and stakeholders get a sense of understanding of the whole project?
• What is the bottleneck in the workflow of this project?
• How can we improve day-to-day openness in the project?
• How can a project be lean and agile at the same time?

How each of these questions is solved is explained throughout this article and subsequently summarized in the benefit section.

History

Kanban is now a popular system used by teams practicing agile and lean project work. In recent years Kanban has become a popular framework for managing software development teams, and is now often implemented to complement Scrum or other agile software development methods.[6] Kanban is considered to be a prominent and relatively new framework, it was first introduced (to this use) in the early 2000’s. Nonetheless the Kanban methodology dates back more than 50 years.

Kanban was first implemented in the Toyota factory in 1953 by Taiichi Ohno, an industrial engineer and the creator of the Kanban concept. The system was inspired by the grocery store model. The concept of this model was that grocery stores was stoking just enough product to meet customers demand. This practice enables the inventory levels to match the customer pattern and therefore be at a minimum without affecting the customers in a negative manner. Thus the store can gain efficiency in inventory management by decreasing the amount of excess stock.[7]

Taiichi Ohno’s vision, when implementing Kanban to Toyota, was to align their massive inventory with the actual consumption of materials. In order to communicate capacity levels at the different workstations on the factory floor in real-time, workers would pass a card with capacity information between workstations. When the batch of materials used at one point in the production line was emptied, a card with this information was sent to the warehouse. Here it would be a new batch ready to be transported to the production line. Subsequently, the card would be sent to the supplier, where a new delivery for the warehouse was waiting to be shipped. This pattern can be carried on in as many steps of the value chain as desired. The Kanban framework for production lines is still very much used today, though it has been developed in line with the the technology to a faster and more agile version of the same system.

When Kanban was introduced as a project management tool for software development by Microsoft in 2004 the workstations were replaced by parts of a Kanban board and the cards was replaced with sticky notes. Other than that, the concept, value and advantages remained the same [8].

Kanban Step-By-Step

To visualize the work of your team with Kanban project management all you need is a board and cards of some kind. This can be either physically, a board and sticky-notes, or virtually, using an online platform. There are numerous variations of booth of this (which a quick google search can show you). After choosing a type of Kanban system it is time to set up the board and make rules for the cards. There is no limitation to the different variations of boards division and card rules, the example in this article is just one way of doing this.

There are several ways to mark the priority of the work items, one can for example organize them in line, where the top one is the most urgent, see figure 1. This priority of work items are most often carried out in stand-up meetings. These meetings take place in predefined time slots, last 5-30 minutes, and address all "issues of the day".

The Board

Figure 2: Example of Kanban Board

The Kanban boards for project management most often consists of three main parts To Do, Doing and Done. Each of these is divided in sub sections. There are many advantages to do it in this way, the main one being the visualization of when work items are ready to go to the next main part of the board. Each section also have a WIP-limit, this is the maximum number of work items that can be at that part of the board. These will of course be different for the different parts as the workload varies. The parts with a higher workload should have a higher WIP. In order for this to not limit the flow, and become a bottleneck, the number of employees assigned to the different parts of the board should be according to the maximum WIP level.

To Do

Backlog: In this section cards with work items which is to be performed in the future, but have not started on yet, is placed. This part of the board have no rules of an upper limit. The number of cards here is most often limited by your lack of knowledge of the future, as you don't know of all your future work yet. To indicate which of the work items that is most urgent in the backlog they are sorted by urgency on the board. This can be done in the stand-up meetings.

Breakdown: The Breakdown part is managed by a rule limiting the work item size. An example of this can be that all work items must be limited to take approximately two working days. If the work item initially is longer/larger than this, it is divided into several smaller work items before moving on to this part of your board. The work items are broken down like this to enhance the flow of work items in the project. If a work item is too big it is both a higher chance it will get stuck at one part of the board, and more difficult to diagnose why the work item is stuck. When a work item is placed in the breakdown part of the board, it is ready for the next main part Doing.

Doing=

All work items that are undergoing some kind of work is located in this part. This part of the board is almost always divided into several smaller parts as it is where the most complex and challenging activities take place. An example of this can be Plan, Develop and Test. In each of the subsections of this part of the Kanban board, it should be a limitation of work items. This is to limit the WIP, and secure a agile project work. In some cases a work item is stuck in a section of the doing part due to interdependencies of outer work items or people, and there is no current work to be done on the work item. In this case you can mark the activity as stuck and the work item does not count as your WIP.

Plan: In this section the work is planned, this includes both allocation of resources and finding possible ways to perform the work.

Develop: In this section the work item is developed from an idea to a product. This section is often divided in two subsections, In Process and Done. The reason for having a Done part, is to visulize when the work items is ready to be transferred to the next stage, testing.

Testing: After the development, the work item/product is tested or checked, before being marked as finished. This is often done by a different person than the developer. This stage often have some rules set by the team to secure the quality of the end product. When this stage is completed the work item moves to the last and final part, for this Kanban board, Done.

Done

When the work items arrives at this area of your Kanban board it means that your team is done with this work item. The done area, of course, do not have any WIP-limit, but it can be a good idea to set some goals and milestones related to this part of the board. This should be related to the throughput of work. Nonetheless it is important to remember that all work items do not have the same work load, and that it is the workload throughput that should be celebrated, not the number of work items.

The Cards

Figure 3: Example of kanban card

The cards include critical information about the particular work item. This includes a short description of the job, the time estimate, and so on. In the virtual Kanban cards it is possible to add more information, as pictures, technically detailed information and other documents that may be valuable.

Kanban cards can have three stages pending, undergoing work or finished. When a team member is finished with his or her work they go to the board and mark their work item as finished. If there is room for the item in the next part of the board, it is moved there and the status is now pending. Now the team member can choose a new work item matching their capability and with the highest priority on the board, this should now be marked as undergoing wok.

Kanban in Software Teams

As previously mentioned Microsoft first introduced Kanban for software development. This has later been adapted around the world, and is the most prominent software management after Scrum. The methods are in many ways similar but have some differences that will be discussed below. After this it will shortly be explained how a team can transfer from Scrum to Kanban

Kanban vs. Scrum

Both the Kanban and the Scrum method focus on quick response to changing customer requirements, and full utilisation of resources. The methods can therefore be described as both agile and lean [9]. Both methods are also highly adaptive and are based on self-managing teams with a high level of cooperation. The methods depends on a visual representation of future and ongoing work and includes short stand-up meetings with the project-teams.

The most prominent difference between the stand-up-meetings is that in the Scrum meetings every team member states what they did and what you are doing next, but in the Kanban meetings only the issues of today are discussed. Thus the Kanban meetings are severely shorter and less informative, a team member who wants to obtain this information can do so from the information on the Kanban board. Because of this difference between the two systems, the Kanban can be used for much larger teams than the Scrum. In Microsoft a Kanban board have been used for teams up to 75 people, the stand-ups then took around 15 minutes, which would not have been feasible for the Scrum[10].

Opposite to Kanban, the Scrum method does not visualize continuous flow and delivery, and it is not possible to make managerial changes during a ‘’sprint’’. The work items are also released in batches so that there is a WIP-limit for the system, but not for each piece of the system (as in Kanban). The Scrum method also requires the team to define a “Scrum master” and in Kanban there is no predefined roles. To get an overview of the previous mentioned differences, see table below.

Developing from Scrum to Kanban

Implementing Kanban should not be experienced as a revolutionary change for participants of the team. Especially if the team is already working with Scrum, as they already have a board with work items moving through, a definition of "done", daily stand ups etc. The team do not have to rely fully on the new Kanban system from the start, as it can at first be supplementing the existing project management system. Idealy there should be one or more experienced Kanban user(s) in the team, to prevent insecurities that may cause the team to stop using Kanban and fall back on their old management system. [11]. If the team is moving from Scrum to Kanban it is recommended to keep the Scrum master and meetings at first. In time you introduce the new aspects (see table ‘’Differences between Kanban and Scrum’’) of the Kanban system step-by-step.

Benefits

Visualization

Kanban helps the team to visualize the work in real time, it is therefore easier to see emerging patterns. The possibility to find new waiting task on the Kanban board makes the team work visually and consistently, and the time when waiting for new tasks is eliminated. By limiting the WIP at each step in the process Kanban prevents overproduction and reveales bottlenecks dynamically so that you can address them before they get “out of hand”.[12]

Communication

The most important benefit from using Kansan is maybe that the team can get a better understanding of the whole process. In general it is also proven that the quality of communication both within the team and with stakeholders improve. This, in the end, result in higher customer satisfaction.[13]

Team Mentality

Each team is different, and it is therefore a huge advantage that the Kanban system can be adapted to fit various team cultures. No matter how the system is set up, or how the board is designed, the outcome is always the same as long as everything is tracked and followed accordingly. As each member contributes to the the Kanban system it often emerges a sense of comradery around it, day-to-day conversations and openness. All concludes to a improved team mentality.[14]

Limitations

Expertise

If the team consist of highly diverse personnel with no overlapping knowledge fields, Kanban may not be the ideal tool. This is not because it will not work, but because the advantages of Kanban will not come to full use, as all the work items are already assigned to a team members. On the outher hand, if you want to make your team more robust, you can use Kanban as a learning tool, where the work item gets one inexperienced owner, and one experienced supporter.

Learning

The Kanban system is always focusing on ‘’right now’’ - never the past. This limits the learning, especially double loop, and future risk management. To enable double-loop learning when using Kanban it has to be supplemented with another tool or system, this is in opposition to Scrum which has learning and after action review embedded in its structure. However some "Kanban enthusiasts" argue that the visibility in the Kanban system give the team members instant feedback on what is going wrong, thus the "looking back" part is not necessary to learn from the projects [15].

Dependencies

The dependencies is not directly visualized in the Kanban system. The system is therefore most suitable to project with a relatively small amount of dependencies.

Focus on End-Date

With the Kanban system it is easy to visualize the time it will take for your team to finish the work on the board. Nonetheless it is difficult to estimate end dates if your project is large and the work items exceeds the work items visualized on the board. Nor is there an option for marking a fixed deadline or end date set by the customer or another stakeholder. This does not necessarily have to be a problem, but it is something that requires extra attention when using Kanban, and in large projects a supplementing ‘’planning’’ tool should be utilized.