Even though we all have seen Kanban boards, many of the principles that stand out this methodology are often overlooked when in practice.
If you are working in software development, in a technological environment or in a start-up, it is very likely that sometime you have used a Kanban board to visualize which tasks are still pending, which ones are in progress and which ones are already finished.
This is the Kanban MVP: three columns, three stages: to do, in progress, recently completed.
ITM Platform’s personal board sums up the pending work with Kanban.
This simplicity has been, in some way, a blessing, because boards have become hugely popular. However, in a way it has also doomed them – many people either use them or criticize them without knowing in detail the characteristics of this method.
For example, Kanban’s usefulness for managing work that doesn’t fit into any project is commonly ignored.
This makes Kanban an excellent tool accessory to manage a portfolio of projects, in which change demand also includes isolated tasks for which there is no formal coordinator or project manager.
Nevertheless, very few portfolio tools include Kanban among their characteristics; and very few online Kanban versions feature portfolio management.
If you fancy having both things, ITM Platform is on the of the few suppliers that can satisfy you.
Link your Kanban projects with a unified portfolio with ITM Platform.
Kanban vs agile vs SCRUM
In the software development world, it is common to consider that SCRUM is the best agile methodology, if not the only one. However, each methodology has its pros and cons. If you want to have a look at the main differences, here you have a helpful article.
SCRUM, for example, is only used for software projects and, in that field, it replaces traditional waterfall design methods in a much more efficient manner.
However, outside that field, SCRUM becomes very fragile, not to say useless. For example, it cannot be applied to design processes of new products that lack programming elements.
On the other hand, besides being used extensively in development (often mixed with SCRUM methodologies), Kanban has proved its utility in contexts where most of the work volume is operational. The classic example is industrial manufacturing, such as the Toyota factories where this method was invented. But the design of new goods and services of any industry can benefit from its structure.
The 3 principles of Kanban:
- Visualize everything that is happening at any given moment. Each element and its stage can be seen within the context of all scheduled work, regardless of whether it’s a project or operational work.
- Set caps for work in progress (WIP)There should be a maximum number of tasks that can be managed at the same time, and the visual boundaries of the board help us perceive that limitation. For example, if a quality control unit can manage a maximum of 5 batches, it shouldn’t accept the 6th one until it has one empty spot for it. This might not be very intuitive, but WIP limitation consists, precisely, on visualising bottlenecks in order to prioritise work in those areas and gather the resources required to solve them.
- Improves work quantity. As soon as a task is finished, another one from the backlog is started. In order to do that, it is essential that the backlog be correctly managed, prioritised and categorised.
When should Kanban be used?
There are 4 situations in which Kanban should be used:
- In operative environments where priorities change very often
- When changes in requirements can be introduced any time
- When work units are isolated tasks
- When the incremental optimization of an already existing process is pursued.
What are Kanban’s advantages?
- Maximum transparency
- Continuous worflow
- Equating the team’s capacity with the ongoing work
- Focus on the duration of the cycle (how long it takes a task to go from backlog to be completed)
- It allows assigning different WIP maximums to the consecutive stages and redirecting the work to improve the delivery time.
For example, regarding this last point, it’s very normal to have 4 stages within a programming team: To Do, In progress, Code Review and Finished. Allocating a maximum of 2 tasks to Code Review means that In Progress cannot take over more tasks right away. Therefore, programmers must spend some time checking code, a very unrewarding task that is often relegated. Thanks to this, we can avoid the bottleneck of having all the code written, but pending from review.
When teamwork and immediate communication are added to the board, benefits are crystal clear.