Kanban in Project Management

Revision as of 11:23, 13 September 2016

Kanban aims to provide visibility and improve communication and work flow throughout a project, process or similar. The Kanban (看板 translates directly to signboard from Japanese) system was originally an inventory-control system developed by Taiichi Ohno, an industrial engineer at Toyota. The vision than was that the system would reduce the waste (muda) in the production line and improve the manufacturing efficiency. It is a flow-control system for pull-driven JIT production, in which the upstream processing activities are triggered by the downstream demand signals[1]. 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.

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 that 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 set-up and divided however the user like, nonetheless the main concept is always the same, and can be summarized by these six points[https://www.atlassian.com/agile/kanban ]:

1. Limit WIP (work in process): The board is divided in parts, and each part can only have a set 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 on the card is the on moving it
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 your board or break your rules that's ok, but inform rest of your team

History

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

Kanban was first implemented in the Toyota factory in 1953 by Taiichi Ohno, an industrial engineer and the father of Kanban. The system was inspired by the grocery store model. The concept of this model was that grocery stores was stocking just enough product to meet customers demand. This practice causes 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 gains efficiency in inventory management by decreasing the amount of excess stock.

Taiichi Ohno’s vision, when implementing Kansan to Toyota, was to align their massive inventory with the actual consumption of materials. In order to communicate capacity levels at the different workstation on the factory floor in real-time, workers would pass a card with capacity information between workstations. When the bach 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 bach 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 could be carried on in as many stages as desired. The Kanban framework for production lines is still very much used today, though it have been developed in tact 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 developnment in the early by Microsoft in 2004[3]. The workstations was replaced by parts of a Kanban board and the cards was replaced with sticky notes. Other than that, the concept, value and advantages stayed the same.

Kanban Step-By-Step

The Board

Figure 1: 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 reasons for doing this, the main one being to visualize when the work items is ready to go to the next main part Each of the parts of the board 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 generally 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 any part of the board should be according to the maximum WIP level.

To Do

Backlog: In this section cards with work items your are doing if 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 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 by either the group leader, or in the group 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 a higher chance it will get stuck at one part of the board, and it can be difficult to diagnose why. 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, Test and Deploy. In each of the subsections of this part of the kanban board, it should be a limitation as to how many work items can be at each part. 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 in your WIP-limit.

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 ide to a product. This section is often divided in two sub sections, In Process and Done. The reason for having a Done part, is to make it visual 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 then 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 the ‘’done’’ 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 on your bard. Nonetheless it is important to remember that all work items do not have the same work load, and that is it the workload throughput that should be celebrated, not the number of work items.

The Cards

Picture 2: Example of kanban card

The cards include critical information about the particular work item. This includes a short description of the job, the time estimation for the job, 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.

The 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, the status is now pending. Now the team member can choose a new work item matching their capability and with the highest prioritisation on the board, this should now be marked as undergoing wok.

Kanban in Software Teams

Kanban vs. Scrum and Whaterfall

Change Management When Implementing Kanban

Benefits

Limitations