Kanban method

Latest revision as of 14:10, 21 March 2022

Kanban can be referred to as either a method within process improvement or a visual method in Just-in-Time and Lean manufacturing, following article will be focusing on its uses in process improvement.

Figure 1: Example of a simple Kanban board ^[1]

The Kanban methodology originates from Japan and is therefore a Japanese word that can be translated to “signboard”. Kanban is a framework that is used in teams that is following the agile methodology, which has gained popularity throughout the software development industry, since the adaption by David Anderson back in 2010. To practice Kanban, it is essential to acquire a lean thinking mindset, which focuses on the improvement of processes and elimination of waste, called Muda in Japanese. To understand more about Lean manufacturing see Lean in Project Management. When teams want to implement lean and a lean mindset, Kanban can work as a beneficial method to bring exactly this to the team, which is explained by David Anderson in following quote.

In general, Kanban helps project managers to keep an overview of their projects and the tasks involved in them, it also increases collaboration between the team members that is involved within the projects, mainly because visualization with the use of Kanban boards, creates project transparency. How exactly Kanban works will be the focus of this article with an overview of the historical development of this specific method, an elaboration on its uses in project management and its features will also be enlightened, where the final point of the article will define some of the limitations that is linked to the use of Kanban.

[edit] Historical State of the Art

In the mid 1940’s Japan faced a post-war shortage on materials and low volumes of production, this meant that it was necessary to utilize the materials in the most effective way and hereby raise the productivity to achieve a higher volume of production. This was also applicable for the Japanese car industry that was greatly stagnating. One of these car producers were Toyota, which at the time made economic losses and could not compete with other global carmakers. This changed by Taiichii Ohno, who at that time was an industrial engineer at Toyota. He sought inspiration for changes by studying an American supermarket, which only replenished its stocks when customers had bought the available products and hereby work as a pull system, where the demand and pull of products directly affected the supply of products. This inventory system was called “Just-in-Time” and was a great effector on the reduction of waste which leads to low throughput and low performance. Taiichii Ohno implemented this system to Toyota and called it Kanban, because of its new way of signal demand throughout the factory and the foundation for the “Toyota Production System” were made. Toyota Production System is acknowledged as the predecessor to the more generic Lean manufacturing. ^[3][4]

In 2010 David Anderson wrote his book “Kanban – Successful Evolutionary Change for Your Technology Business”, where he enlightens a new way to introduce Lean ideas and methodology into technology development and IT operations with the use of a new Kanban method that utilizes the Kanban system which is known from the Lean methodology. He did this based on his work and observations at Microsoft where he worked as a development manager. The book describes how he sought a solution to overcome deadlines that were set by managers with no regard to possible complexity, risk and size of project. There was a need for a change that would increase productivity and quality, together with a new norm on working schedules and work commitments, it was described that there was a need for protection of the demands towards the software teams and for a sustainable work pace. The initial findings Anderson made, were through the use of a pull system called “Drum-Buffer-Rope” which is an application for flow problems and an approach in the “Theory of Constraints” framework developed by Eliyahu M. Goldratt. One of the side effects using the Drum-Buffer-Rope system and in general a pull system is that it limits work-in-progress and hereby limits overloading of workers. The implementation of the system showed great result in productivity and in lowering of lead times, therefore a success. The transition to another pull system, Kanban, happened simply because it was found that implementing a Kanban system the results would have been the same, but also because of its easy access and because it has a wider acknowledge than the Drum-Buffer-Rope system. ^[2][5]

[edit] Kanban in Project Management

Kanban can be used in project management to bring a lean methodology into the organization and to the team working in a project. As stated earlier, the new adapted Kanban method developed by David Anderson in 2010, which following wiki article elaborates, is developed towards the use in technology development and IT operations, therefore it is, as a project manager, important to distinguish which type of project they are working with and thereby choose the right method for exactly their case of project. Exactly what the Kanban method can give to a project is that it helps visualize tasks and the tasks status, a very simple Kanban board, which is used to visualize this, can be seen in figure 1. Where the stickers represent a Kanban card and the different lanes represent the task status, which gives the manager an overview of the processes. The effects of Kanban in manufacturing are very clear since its development in the 1940’s, and this shows that Kanban fits in the field of low variety and high repetitive work, which manufacturing is. But because of the findings regarding Andersons work in technology development, Kanban also has great effects to the fields of technology development and IT operations which has very high variability of work and also seeks variability to become first movers within the industry. Visibility in the work of technology development has simply, by limiting the work-in-progress, showed great effects on increased productivity, predictability and lowered lead times ^[2]. Kanban can therefore work as a method that project managers can use both in manufacturing and now in the areas of technology development and IT operations as well.

One of the most important things to elaborate regarding Kanban in Project Management is that Kanban is not an approach to Project Management, which is stated by David Anderson, ”Kanban is not a software development lifecycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process” ^[2]. Therefore, there has to be some kind of processes already in place before using the Kanban method, which is different from other agile methodologies like Scrum, see Scrum for more information, because Scrum focuses on ways to handle the process of Project Management ^[5].

As a Project Manager, who wants to stabilize and improve the system in technology development and IT operations there are some foundational Kanban method principles one can follow:

• Start with what do you know
• Agree to pursue incremental, evolutionary change
• Initially, respect current roles, responsibilities & job titles

Firstly, when talking about “Start with what you know” the method does not require any changes in the current work processes, but it is implemented directly to the working process, and the focus is solely on improving them. When looking at other agile methodologies like Scrum, is it a whole new system for managing the project and there will be new roles within the team and new activities. Secondly, “Agree to pursue incremental, evolutionary change”, means that when using Kanban there is a search for making improvements within the system that the team works with. By system this means in what way the team is doing their tasks, this could be by following a certain methodology or something else, but the only thing that matters when using Kanban is that everybody on the team understands this system. Measurements within the system and team is very important to make changes, because feedback can be given upon this and hereby help changes. Thirdly, “Initially, respect current roles, responsibilities & job titles”, means that if different representatives of the team do not respect roles, responsibilities and titles, the system of the team would not work out, because everything then will become unclear. This is especially important when working in technology development and IT operations because there is no correct answer on how to manage it, it varies from project to project ^[5].

The third principle of the Kanban method is well stated as something a Project Manager in every sense needs to take care off, because projects involve people and there needs to be some kind of control of what there is expected of people in an organization or team and what people expect of each other. As stated by Nigel Bennett who writes about the PRINCE2 method. “To be successful, projects must have an explicit project management team structure consisting of defined and agreed roles and responsibilities for the people involved in the project and a means for effective communication between them” ^[6] Furthermore, the ISO 21502:2022 states that “The project manager should seek to optimize team performance by providing feedback, resolving personal disputes and encouraging collaborative working” ^[7]. This is exactly a point which is important for the project manager leading a project with the use of Kanban, it requires the use of feedback in the search of continuous improvement, and the collaboration between team members and the organization improves with this.

[edit] Features of the Kanban method

One of the greatest features surrounding Kanban is to adopt the philosophy surrounding it, which means adopting the lean mindset. There is also a very important distinction when working with Kanban and more traditional process improvement, because in Kanban it is the team that is responsible of improvement decisions, where the decisions in traditional process improvement is more based on top-down management. There is simply more responsibility left to the team itself ^[5]. There are five practical core features related to the implementation of Kanban and each one of them will be explained in the following subsections.

Figure 2: Kanban board, self made with inspiration from ^[8]

[edit] Visualize Workflow

The visualization part of Kanban is of great importance, because it enables team members or managers to spot potential bottlenecks in the process. One of the great features for visualizing workflow is the Kanban board, an example of this can be seen in figure 2. The Kanban board showed in figure 2 has also been applied with a pull system, which allows the team members to pull a task when there is capacity to do so ^[9]. Kanban boards can vary a lot, meaning that they are specific for each team, this means that when a team wants to apply the Kanban board, they should study their own workflow and visualize exactly this. On the Kanban board there are several stickers, these stickers represent a user story which can be stated as the collection of a persona, need and purpose of the task, it is a short and precise explanation of what this exact feature will bring to the end user ^[10].

[edit] Limit Work-in-Progress

In a team there is a certain capacity of how much work there can be made, and by first have visualized the workflows and tasks it becomes clear if there is any column on the board that piles up a great amount of tasks, when this happens it gives the managers a possibility to control this by applying a limit of work-in-progress. By applying this, the team will focus on the work they are already doing and do not start on new tasks, which ends up with a better flow of tasks, followed with less context swinging which has been found to leading to waste of time ^[9]. Furthermore, there is great gains in limiting the work-in-progress because the team does not get overburdened, which has been an issue in technology development and IT operations.

[edit] Measure and manage flow

Figure 3: Example of a CFD, where the Kanban board categories are defined by different colours ^[11]

The feature of measure and manage flow is a corrective step, where the team uses information based on measurements of the flow to improve it, which means that they are looking for ways to improve continuously. There needs to be a certain amount of willingness to maximize the flow and this means for the whole team, because it can help with unevenness, frustrations and decrease of lead times. When there is a maximization of flow the effectiveness of the Kanban implementation is high, therefore is it interesting to look into the effectiveness of the implementation. When measuring the effectiveness there is several Key Performance Indicators (KPI) that can be used, the three main flow metric indicators is: Cycle time, throughput and work-in-progress. A cumulative flow diagram (CFD) can be used to visualize exactly these three indicators if they are measured. The CFD is a great tool to look in to where problems derive from, so this can be managed, and in the end, create an even better flow. The derivations can be managed by looking after following patterns ^[12]:

• Differences in gradient: This is a common pattern, where the input flow rate is often higher than the output flow rate, indicating that more new tasks enters the system before finishing new tasks. This will lead to longer cycle times and inefficiency. One way to overcome this is to be strict about work-in-progress limits.
• Flat lines: When the CFD shows flat lines there is an indication of tasks not being completed and they are blocked at some point in the process. To overcome this obstacle it is important looking into why there is blockages and how these can be solved.
• The S-curve: Following pattern is an indication of little to no work-in-progress, meaning that there is not a stable amount of work during the days and the days become unpredictable. A way to overcome this issue is by trying to flatten out the work, and hereby create a steadier workflow.
• Bulging bands: This pattern happens when one or more bands are increasing in thickness, leading to increased work-in-progress and delivery times. The issue here can either be created because management try to push tasks trough the workflow or because there is a blockage in a process. To overcome this, an investigation needs to be done in every process, where the process can be split into different states, trying to understand where the tasks spend most time.
• Stair steps: This pattern occurs when tasks are delivered at once or in batches, this could indicate that there is some place in the process where tasks are accumulating until they are released simultaneously. To overcome this, make sure that when a task is ready for next process state, then move it.
• Disappearing bands: Following pattern indicates that there is either a blockage in the system or some tasks are skipping process states. To solve this check if there is any tasks that has not been through the whole system or split the states to see if there is any blockage.

One very important lesson to learn from the use of CFD is that it does not explain how to handle flow problems within your team, but it helps detect issues, and upon these issues the management and team can make adjustments.

[edit] Make process policies explicit

In general, this feature requires that there is a description of how the team works within the project, how they do it and what they do, this also needs to be explained to everybody on the team and to those in the organization who is affected by it. The policies in Kanban do not tend to be long descriptions, because it will then tend to be overdone and too complex. A common way to create policies within Kanban is when they are "established collaboratively and evolved experimentally by the whole team" ^[5]. This is important to remember, because by doing this everybody on the team will have a better chance to understand the policies.

[edit] Use models to recognize improvement opportunities

Kanban can, as stated earlier, be used as a method for continuous improvements and to look for other improvement opportunities. But this requires that the models Kanban delivers are being used. David Anderson states that Kanban supports at least three continuous improvement methods, which are: Bottleneck removal, Waste reduction and Variability management. But there are other continuous improvement models that also needs to be recognized, and they have all their own knowledge and tools for improvements, the thing to recon throughout those models is that Kanban shows opportunities within all of these models and therefore is a great method that has basis in a variety of models ^[2].

[edit] Limitations of the Kanban method

The Kanban method is often used or seen as a methodology for building software, furthermore, it is sometimes also mistakenly seen as a project management tool, which has been described in earlier subsections ^[5]. It is neither of those things and per that definition the Kanban method implies some of its limitations. Hamzah Alaidaros, Mazni Omar and Rohaida Romli, explain in their their article, that elaborates on the challenges with the use of Kanban method, that there are three main and current challenges ^[13]. These three challenges are found through the use of a narrative review method that focuses on critical summarization on a variety of literature and hereby concluding them.

• Determining Optimum WIP Limits: Having determined WIP limits is one of the essential features of the Kanban method, but with bad estimated WIP limits there can be caused lag in the scheduling and in overall this will lead to delayed delivery times. It has not yet been clearly defined how to determine the optimal WIP limit, which also implies for the rest of the Kanban method, there is simply just no specific determinations of how to exactly implement it ^[13]. It is possible to use tools like Littles Law to determine a WIP limit, but this is not a concrete feature within the Kanban method.

• Visualizing Useful Insights for Workflow: Visualization of workflows is another key element of the Kanban method, this is done by the use of features like a Kanban board or CFD. Kanban boards do have limitations because they do not indicate other information than where tasks are placed in the workflow, and hereby the development. CFDs also just inform on specific KPIs I does not indicate how much work there is left to be done in the project or where it should be at on the specific time. In general they both show progress and not target nor if the project will meet its commitments ^[13].

• Progress Tracking: The Kanban method is not as earlier mentioned a methodology for project management, and it is not a method where there is any sort of tracking throughout the project progress, the tasks are not time-boxed, as they are in Scrum. This is being considered as both an advantage but also as a limitation and should be modified for the given project ^[13][9]. It can hereby be advisable as a project manager to look into Scrumban, which is a mix of Scrum and Kanban, to try to accommodate eventual limitations in a project.

[edit] Annotated Biography

The book 'Learning Agile: Understanding Scrum, XP, Lean and Kanban' from 2014 by Andrew Stellman and Jennifer Greene gives a detailed introduction on how to become more agile working in a software development team ^[5].

The book 'Kanban: Successful evolutionary change for your technology business' from 2010 by David Anderson is a thorough and detailed book which describes the evolution of using Kanban in a software development setting ^[2].

The book 'The Lean Toolbox' from 2016 by John Bicheno and Matthias Holweg is a handbook for lean transformation and its sole purpose is to help an organization become lean ^[14].

[edit] References

1. ↑ The kanban method. (2022). How to implement kanban. [1]. Accessed February 16th.
2. ↑ ^{2.0 2.1 2.2 2.3 2.4 2.5} Anderson, D. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. Pages 21-31
3. ↑ Bicheno, J., & Holweg, M. (2016). The Lean Toolbox: 5th edition. Picsie Books
4. ↑ Ilmi, M. A., Pradana, F. & Hayuhardhika Nugraha Putra, W. (2020). Software Project Management Systems Using Kanban Method in the CV: Universitas Nusantara PGRI Kediri, Volume 4, Issue 2, pp. 215-231
5. ↑ ^{5.0 5.1 5.2 5.3 5.4 5.5 5.6} Stellman, A., & Greene, J. (2014). Learning Agile: 1st edition. O'Reilly Media. Pages 315-358
6. ↑ Nigel Bennett. (2017). Managing Successful Projects with PRINCE2. 2017 Edition. The Stationery Office Ltd. Page 22.
7. ↑ Dansk Standard. (2020). DS/ISO 21502:2020, Project, programme and portfolio management. 1st Edition 2020. Dansk Standard. Page 31.
8. ↑ The kanban method. (2022). How to implement kanban. [2]. Accessed February 16th.
9. ↑ ^{9.0 9.1 9.2} Al-Baik, O. & Miller, J. (2014). The kanban approach, between agility and leanness: A systematic review. Empir Software Eng (2015) 20. Pages 1861–1897
10. ↑ Atlassian. (2022). User stories with examples and a template. [3]. Accessed February 20th.
11. ↑ Tipsographic. (2020). How to Read a Cumulative Flow Diagram in Kanban. [4]. Accessed February 20th.
12. ↑ Nave. (2020). Reading the Cumulative Flow Diagram. [5]. Accessed February 20th.
13. ↑ ^{13.0 13.1 13.2 13.3} Alaidaros, H., Omar, M. & Romli, R. (2018). Identification of criteria affecting software project monitoring task of Agile Kanban method. AIP Conference Proceedings 2016, 020021 (2018). PP 020021-1–020021-7
14. ↑ Bicheno, J., & Holweg, M. (2016). The Lean Toolbox: 5th edition. Picsie Books