We started this series on the Scrum methodology with an introduction (LINK), followed by two pieces on two of the most important roles in the Scrum framework (the Scrum Master and the Product Owner, LINKS), and an article on the framework itself and why it's called a framework for Agile working (LINK). After that, we focused on the ceremonies or events around which a Scrum-based project tends to revolve.
When it comes to Scrum, a project consists of Sprints and Sprints are built up of events. The role which each of these events plays and the way in which they take place can differ considerably based on factors like the the product that is being developed, the experience of the people involved in the project, and the preferences of the team members themselves. In general though, in a traditional Scrum project, a Sprint contains at least four major events, namely Scrum planning (also known as Sprint planning, LINK), the Daily Scrum (LINK), the Sprint Review (LINK), and the Sprint Retrospective (LINK).
Besides the roles and the events that are relevant to Scrum-based projects, the so-called artefacts also represent a key element of the Scrum framework. Usually, there are three artefacts that present in every Scrum team, namely a Product Backlog, a Sprint Backlog, and a type of backlog that defines a “finished” part for you. An artefact in a Scrum environment is a type of tool that teams can use to solve complex problems together. Considering the particular role and importance of the Product Backlog to the correct functioning of a Scrum team, we also dedicated a separate piece to this artefact (LINK).
As you probably know by now, Scrum is an agile methodology to help plan, manage, and optimise product development cycles by cutting them up in a series of fixed-length iterations. As we wrote before, both earlier in this article and in separate articles in this Scrum series (LINKS), a Scrum production cycle or Sprint consists of at least four main events: Sprint planning, Daily Scrums, the Sprints themselves, and Sprint Retrospectives. In our series, we have also covered the Sprint Reviews, which take place after the Sprint ends and before the Sprint Retrospective is held. In order to help Scrum teams perform these events with ease and to chase the highest possible product value for the end customer in the most efficient manner possible, Scrum teams can make use of several sets of tools that were especially designed for use in Agile projects. In our previous article, we took an in-detail look at Scrum Boards (LINK) and the tool we will be covering in this piece is the Kanban Board.
Simply put, a Kanban Board is a practical tool that can be used to manage complex projects in simpler and clearer ways, very much like a Scrum Board. To start off, we will briefly go over the key similarities and main differences between Scrum and Kanban, and the different boards, followed by a detailed look at what a Kanban Board exactly is, some of the Kanban Boards that are available on the market right now, a few recommended ways of using a Scrum Board, and a brief comparison overview of the pros and cons that come with using a Kanban Board.
What is a Kanban Board exactly?
We already stated that a Kanban Board is a tool to facilitate the management of complex projects, but in the coming pages, we will be explaining how it can do so. Expanding on our earlier brief definition, a Kanban Board is an agile project management tool that can help to visualize work, limit the number of items labelled as work in progress, and maximise the efficiency of the team working on the project in question. By using cards, columns, and continuous evaluation, Kanban Boards can help development teams to optimise their efficiency and output.
The word Kanban actually means visual signal or card in Japanese, which makes sense, since the Kanban method has its origins in Toyota's production plants of the late 1940's. As a part of their efforts to re-imagine its approach to manufacturing and engineering, the company designed a new, highly visual management system based on line-workers using kanbans (actual coloured cards) to inform colleagues and counterparts along the production line which parts and what kind of assembly work were needed. The idea behind this overhaul was that a more visual system would allow teams to communicate more easily on what work needed to be done and when, while it also helped to standardise and refine processes. This, in turn, would lead to less waste and a maximisation of value for the end customer.
The Kanban method has come a long way since then, mainly due to the fact that many of Kanban's core principles are considered key for project management in other sectors and industries as well, including software development. Nowadays, there are plenty of software developers and development teams who swear by the Kanban approach and the use of Kanban Boards as a result. In order to give you a better idea of what a Kanban exactly is, we have broken down the tool into five principal components, each with its own value and purpose within the framework.
- Visual signals
The appearance of a Kanban Board in use is first of all dominated by coloured visual cards. These can be Post-Its, stickers, or simple pieces of paper on which the involved development team writes down its separate work items. One card could, for example, feature one User Story. Together, these visuals will help teammates and stakeholders to quickly understand what the team is currently working on.
Each Kanban Board consists of columns. Each of these columns represents a specific activity and together they provide a visual representation of the workflow. The previously mentioned visual cards enter the workflow in the first column and then flow through the structure until they are completed. The complexity of the workflow is entirely dependent on the type of project and the preferences of the development team working on it.
- Work-in-Progress (WIP) limits
The work-in-progress limits play a crucial role in the Kanban framework in the sense that they represent the maximum number of cards that can be in a single column at any given time. In other words, they determine on how many items the team can work for a specific activity at the same time. This helps teams to recognize their productivity limits, to identify potential bottlenecks in the operation, and to prioritise their work. In order to move a new card into a maxed-out column, the team will first need to complete one of the items already inside the column.
- Commitment point
Like Scrum teams, Kanban teams usually work with a backlog where customers and teammates can put ideas and work tasks. A commitment point is the point when one of these ideas is picked up by the team in order to start working on it. It functions as the entry point of a work item in the workflow.
- Delivery point
Just like the commitment point marks the beginning of a work item's voyage through the development team's workflow, the delivery points represents the end of that workflow. Usually, reaching the delivery points means that the team will be delivering the product or service to the end customer. The time between a work item entering the workflow at the commitment point and leaving the workflow at the delivery point is referred to as the lead time and the goal is to continuously decrease this lead time.
How does a Kanban Board differ from a Scrum Board?
Even though Kanban employs a different terminology and focuses on different details at several points in comparison to Scrum, it's quite clear that both frameworks largely cover the same need. In the end, both Kanban and Scrum are so-called iterative work systems that rely on process flows, the optimisation of productivity, and the reduction of waste. Considerable differences to exist between the two though, as Scrum is generally seen as the more prescriptive alternative when compared to Kanban. In continuation, we will highlight some of the major differences.
To start with, a Kanban team generally does not work with predefined roles like a Scrum team does. When it comes to Scrum, it's very important for the execution of certain fundamental tasks to assign tasks to people within the team, like a Scrum Master for oversight and support, and a Product Owner to define objectives and manage the Product Backlog. Such formal rules do not exist within the Kanban system.
Each system also has its own way of managing deliveries and delivery times. For Scrum teams, these are determined by the Sprints, but Kanban teams neither work with Sprints nor a comparable alternative. Instead, products and processes are developed on a continuous basis. For the determination of delivery dates, a lot depends on the needs of the business at that specific moment.
The more prescriptive nature of the Scrum framework has a lot of advantages, including the reduction of ambiguity in terms of task descriptions and due times, but it also reduces the flexibility of the system. This is illustrated by the fact that it is strongly discouraged to a Scrum team's Sprint once that Sprint has been started. The Kanban framework, on the other hand, does allow mid-workflow changes to be made to a project, which in turns allows development teams to make iterations and continuous improvements prior to the completion of a project.
There are plenty of other differences and subtleties between the framework still, but what it comes down to, in the end, is what the team in question needs and prefers. It's hard to say whether one framework is definitely better or worse than the other. The Scrum approach is generally best for teams with relatively stable priorities that are not expected to change much over time, while the Kanban system is likely a better fit for teams whose priorities can fluctuate widely.
Some of the most effective Kanban Boards on the market
One of the great things about the Kanban method is that is can be applied to many different types of projects when the objective is to organise and optimise. This also means that, in order to achieve optimal effect and benefits, the Kanban Board used by an organisation should ideally be organised completely according to the needs and objectives of that organisation. As a result, there exist countless examples of Kanban Boards, all with their own specific design and purpose, and we will discuss a few of those boards in more detail here below.
This is especially useful for large projects that are being managed in relatively small physical spaces, but it can come in handy for any project manager. It can happen that a project is complex to such an extent that an accurate visualisation of the project on a Kanban Board requires more space than there is available. In such situations, a square board might come in very handy. Instead of moving tasks from the left columns to the right columns in the traditional way, the work items flow through the system in a clock-wise fashion.
The Arrow Kanban Board
This concept of a customised Kanban Board was designed by Tomas Rybing, director of project management at Aptilo Networks, back in 2015 (see his presentation here). This type of board is based on so-called priority pyramids (more information here) and is considered advanced. Besides the addition of priority pyramids to the classic Kanban Board, the Arrow concept also adds a visualisation of the backlog.
Kanban for Human Resources (HR)
We have already mentioned automotive manufacturing and software development as sectors on which agile project management has had a considerable impact through frameworks like Scrum and Kanban, but Human Resources is another one of these industries. As a result, there are plenty of HR-specific Kanban Boards as well. The workflow in this case represents the hiring process, from the collection of candidates (backlog) and the initial contact with a candidate (commitment point) to contracting (or rejecting) of the candidate at the delivery point. The signal cards represent the candidates instead of the work items on this type of Kanban Boards.
Or just go digital
Physical Kanban Boards are very popular, but that doesn't mean that you can't go digital with your Kanban-based approach. The right Kanban software can help project managers and their teams visualize their workflow and collaborate even better. It basically takes the basic visual approach of a Kanban Board and its cards, and digitizes it. This way, the workflow can be seen by the whole team, which makes this especially useful (and possibly crucial) for remote development teams. Software like this makes organisation easier, and helps project managers and teams manage the workflow better. Examples of Kanban software are Taskade, Hygger, and Trello, just to name a few tool suites.
How to best use a Kanban Board
By mentioning the possibility of a digital Kanban Board, we have also touched on one of the fundamental decisions that needs to be made when choosing the Kanban approach, namely the one between a physical and a digital Kanban Board. Physical boards are often a very good choice for teams of which all of the members are in the same location. It will allow each member to interact with the board and update it, while the tactile aspect might help to make updating a habit rather sooner than later.
A virtual Kanban Board, on the other hand, offers the chance to effectively cover projects in which larger numbers of people are involved. On top of that, it's the perfect solution for teams that have multiple members working remotely. Online Kanban Boards also offer features, such as counting cycle times and creating reports, that can help to reduce the project manager's workload.
Once a Kanban Board of choice has been determined though, there are a few general good practices regarding the Kanban method that are largely the same for both physical and digital boards. That's because both types are aimed at creating a visualised representation of a complex project, albeit in different ways. In order to give you an idea of what these best practices consist of, we will describe a few of them here below.
- Start with the work
This might sound logical, but what we mean by this is that each project should be started by looking at the work that needs to be done and the objectives that need to be achieved. It's much more important for all of the work to be visualised clearly and accurately than for the Kanban Board to boast a certain design. In other words, don't get stuck on a specific board design and don't be afraid to adjust the board according to the needs of your team. If you need more columns than just the Do, WIP, and Done columns, for example, just add more columns if that makes the work easier to oversee for everyone.
- Take it easy at first
Especially when the team is relatively or completely new to the Kanban method, don't worry about issues that might be occurring throughout the workflow in the very beginning. It can happen, for example, that work items are always piling up in the same column. By adjusting the board as a whole, this issue might be very easily resolved, but in helping you identify this bottleneck in the production process, the board has already proven its value as a tool for project management.
- Remember what the board is about
Even though it might look like it at times, Kanban Boards are not about having as many people as possible working on as many tasks as possible at the same time. The quality of the end product is always the leading parameter and the Kanban method aims at maximising its value by having as few tasks as possible in the Work-in-Progress column at the same time and moving individual work items through the flow as quickly as possible. The use of WIP limits comes strongly recommended in this sense.
- Make use of Work Blockers
Every development team and any project will, sooner or later, face one or more factors that are preventing the achievement of optimal productivity and efficiency. These factors can range from outdated tech issues and poorly designed Kanban Boards to inadequate management of the backlog and a fundamental lack of communication within the team. In the Kanban framework, these factors are called Work Blockers and it's wise for teams to use special signs to identify them on the board. A team might use stickers in the form of exclamation marks, simple red dot, or any other way that works for them, but the most important thing is that these problem areas are clearly marked and communicated to the rest of the team.
- Use your data
Again, this might sound logical, but it's still surprising how many project managers fail to use all of the information generated by a Kanban Board to improve their processes. The goal of iterative systems like Kanban and Scrum is to divide complex projects into smaller parts (or iterations) in order to make the big picture more tangible for everyone on a team. By doing so, the team is continually learning by doing, and the learnings from each iteration can and should be used to improve the efficiency of the next iteration. This is how products can be delivered within the shortest time possible, and it can only be done if the collected data is meticulously organised, managed, and interpreted.
- Get more work done in less time
By using Kanban, a team is basically putting a system for constant communication in place. By correctly and accurately using and updating this system, the members of the team should have a lot less need for multiple meetings. This way, the team can spend less time on planning and holding meetings, and more time on actually working on maximising the value of the end product.