Kanban – More Than a Board

Kanban Engpass

Thirty years ago, Peter F. Drucker stated in his article “The New Productivity Challenge” that the greatest challenge in the future will be to increase the productivity of knowledge workers in order to remain competitive [1]. Since the shift of productivity from classic product areas to knowledge-intensive areas, to which software development belongs, managers have struggled to find the right “lever” that will make knowledge-intensive work faster and more efficient [2]. Indeed, whoever delivers first has an advantage in the market. First come, first serve!

Optimizing the IT Workflow

Here’s where the Kanban board comes into play. The method was developed in 1947 by Taiichi Ohno and Kiichiro Toyoda at Toyota. While trying to find solutions to the problems involved in manufacturing various car models in small numbers, Ohno and Toyoda focused on the movement of a product through the entire production process. They came up with the following:

  1. The goal “Built-In-Quality” can be achieved through “Jidoka”. Jidoka refers to the immediate identification of errors and problems in production, in order to avoid carrying them along the rest of the production chain.
  2. In addition, boards were introduced. A core element in production process control, Kanban boards make bottlenecks and blockages immediately visible. This allows for quick reaction so that appropriate changes can be made to keep everything in flow.

While exploring possibilities for improving software development, David J. Anderson eventually found his way to the Kanban method. Compared to industrial production, where tasks are well-defined in scope, projects in the IT branch are much more multi-faceted. This makes estimating time and work considerably more difficult. However, both branches have one thing in common. Before beginning the next step, it’s necessary to appropriately conclude previous tasks. Here it’s important to define both the task and the goal. This is the only way to avoid wastefulness caused by tasks that use resource but don’t deliver any additional value.

The Kanban Board – stop toiling, start thinking

In order to shed light on the production process and thus recognize possible blockages, processes are modelled with a Kanban board. The first column lists tasks to complete. The other columns can be variously labeled. Taking an example from software engineering, they may be labeled “defined”, “in realization”, “realized” and “accepted”.

Prime directive! To carry out planning transparently in cooperation with the team.

Good teamwork requires a common understanding about what is to be accomplished. Compared to classical approaches, Kanban culture functions best with “thinking” employees. Team members are expected to help with designing processes, share their concerns at short daily meetings and actively work on improvements.

Once a requirement is defined, it can be reviewed and moved to the “in realization” column. At this point, a further Kanban innovation comes into play. Team members don’t get tasks assigned (push principle). Rather, once a team member is finished with the current task, he or she goes and gets another. This “pull principle” ensures a steady workflow so that in the end not only the customer gets added value. Finish one task and then move to another – this method from lean management avoids bottlenecks and is the best way to optimize workflow. Employees are more relaxed and at the same time more productive when they are not overworked and don’t need to waste energy on constantly changing tasks.

Of course, visualizing tasks is also useful outside of software development. Kanban boards can be utilized by the support team for working on tickets, by developers for fixing bugs, and by the test management team for organizing tests. In the upcoming release, objectiF RPM 5.2, it will be possible to utilize Kanban boards for diverse result types:

  • Requirements
  • User stories
  • Use cases
  • Test cases
  • Bugs
  • Risks

Simply create a new Kanban board and  choose which element you want to work with. If you want to use an element that’s not supported by objectiF RPM out of the box, no problem. You can define the element yourself. From support tickets to special tasks, there’s no limit.

Festlegung Elementtyp

Choosing element types when creating a Kanban board

Set WiP Limits– stop starting, start finishing

In the Kanban board, the number of tasks is limited through work in progress limits which are defined in collaboration with the team. This helps prevent team members from working on several tasks in parallel, as it’s more productive from an economic point of view to finish one task than to have ten tasks that are only 10% complete. Parallel work increases time needed for production because team members constantly need to reorient themselves for each task and switching tasks takes time. Unfinished products are tied-up capital and this is something companies want to avoid. In pull systems with work in progress limits, problems in the production process become quickly visible. Team members who find themselves stuck can’t take on any other tasks and the team member from the previous step can’t take on new work because of the work in progress limit. This creates a block in the work flow which must be recognized immediately and can thus be resolved.

The Kanban method also increases customer success. Especially in software development, doing small favors on the side can lead to a large amount of parallel work. This often leads to delays and postponement of delivery dates, to the disadvantage of the customer, or else quality must be reduced to make up the difference. Over time, this leads to dissatisfied customers, errors, complaints and change requests. In Kanban culture, the goal is to only make promises that one can stand by. The introduction of WiPs ensures that one can say “no” when additional work would exceed the limits.

In objectiF RPM 5.2 it’s very easy to define work in progress limits. In the dialog window for creating Kanban boards, simply enter the WiP limit for a state or state group. The limit is displayed in the Kanban board in the column header to the right. If the number is exceeded, the WiP limit turns red, allowing you to react quickly to avoid blockages.

Setting work in progress limits (WiPs) for states

Kanban Culture – experience the difference

Using a board for visualizing workflows and setting task limits (WiP limits) to maintain throughput are just two ways to optimize the production process. Kanban is much more than that. Kanban culture aims at reforming teamwork with simple principles. The team is the cornerstone for all activities. For this reason, it’s important to keep all processes transparent and to discuss rules, such as WiP limits, at daily meetings (daily standup). Comments and suggestions for improving throughput are also carefully considered and implemented at meetings. New situations require new measures. A Kanban board is not something set in stone. Its usefulness consists in constant changes and adjustments made in order to avoid bottlenecks and optimize flow. Experimentation, observation, feedback, and more experimentation – this sequence should be executed again and again in order to react profitably to changes and challenges in the market.

 

Sources:

1) Peter F. Drucker „The new Productivity Challenge“ Harvard Business Review, 1991 Nov-Dec;69(6):69-9.

2) K. Leopold, S. Kaltenecker „Kanban in der IT“, 3. Auflage, Carl Hanser Verlag München, 2018

Stefanie Kuke received a doctorate in chemistry, but after university she immediately began working in communications. A certified tekom technical editor, she was previously active in the analytics sector. As part of the microTOOL public relations team, she contributes blog articles, gives webinars and publishes articles about other interesting topics in project management and software development.

Tags: , ,
EN Subscribe to our newsletter
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *