Hundreds of tasks, eleven possible states, eleven employees involved, plus various customers…. How are we supposed to stay in the picture? And how are we supposed to structure it all and work through everything in a way that keeps everyone happy? The answer sounds a little like a ritual dance: Kanban.
What is Kanban?
No, Kanban is not a ritual dance. Translated, Kanban simply means “card”. And when you look at a Kanban board, you’ll know exactly why.
Kanban is a method that supports the agile software development process. Its great advantage lies in the very simple visualisation of work progress across all the developments of a team. Kanban thereby helps us keep our eyes on the big picture and is a great tool to use within a team and beyond to talk about planned and completed work.
A short look at the history
There are various stories about how Kanban was invented. The only thing they all agree on is that it definitely came from Japan.
The origin story I love the most, and the one Dr Klaus Leopold (more or less the “father” of Kanban in Austria) always likes to tell, is about a Japanese garden. The operators of the beautiful garden asked themselves how they could keep it from being overrun by thousands of visitors. The solution was simple: They placed a limited number of coloured cards near the entrance. Each visitor took a card before entering the garden. If there were no more cards available, they had to wait until another visitor left the garden and gave them a card. Once that visitor also left the garden, they either gave their card to another waiting visitor, or they put it back into the box at the entrance gate. This very simple “entry system” ensured – long before the invention of the computer – that the garden would never have more visitors than the optimum number set by its operators.
The difference between Kanban and Scrum
Anyone who works with Kanban will very quickly come across the term “Scrum” as well. Scrum means something along the lines of “jostling crowd” and, like Kanban, is a process model for agile software development. Unlike Kanban, however, Scrum has fixed roles and (a few) fixed rules. Scrum is organised around so-called “sprints”, which are predefined periods of time in which executable software versions are developed.
Scrum tends to be well suited for new developments. It is often used in the initial stages of projects, when a software product is being developed in close coordination with the customer. Kanban, on the other hand, is better for situations in which a finished software product already exists and is being gradually developed further.
Another reason why we in the SAP team introduced Kanban and not Scrum is that Kanban, in contrast to Scrum, makes it possible to jump in at the current state of the own software development process and then make changes bit by bit.
Basic principles of kanban
Kanban has four entities:
- Employee
- Task (in our case, a requirement)
- State that a task can assume
- Kanban board
Employee
Every employee who processes tasks is represented on the Kanban board by a 2×2 cm magnet. The magnets are in different colours and each has the person’s initials on it. They are used to establish a connection between the employee and the task. If an employee’s magnet is placed onto a task, this means that the employee is working on the corresponding task.
Task
A task represents a development that can go through different development steps or statuses. A task is represented by a card, which is placed on the Kanban board depending on its status. The card contains the basic information needed to get a brief overview of the task. In our case, priority is particularly important. Cards can be printed directly from the requirements database. To make the cards easy to move, an adhesive magnet is attached to the back.
State
The states that a task can take on are defined unambiguously and specified by a workflow in the requirements database. As long as a task is in the description state (that is, as long as nothing has been developed yet), we call it a Requirement; once development starts, we speak of a Development.
Kanban board
The Kanban board is divided into multiple columns. Each column represents a status that the tasks can take on. On the Kanban board, the tasks are placed into the column that represents their status. When the status of a task changes, the card is moved accordingly. We set ourselves the rule that cards can only be moved during Kanban meetings.
Wofür wir Kanban verwenden
“We”, in this case, means the “SAP Engineering/Cons Finance & Reporting” team. We are responsible for the further development and maintenance of SAP FI/CO for Porsche Holding Salzburg (PHS).
Our activities consist primarily of the following three tasks:
- Project execution (e.g. country launches)
- Ticket processing (error messages)
- Further development of SAP
Projects are usually relatively long assignments and are therefore not particularly well-suited for visualisation on the Kanban board. Tickets, on the other hand, have a very short lifetime – often just a few hours. Thus, they are also not very well-suited for modelling on the Kanban board. We therefore use Kanban exclusively for further development. As a result, the Kanban board does not reflect the entire truth of our activities! It is extremely important to emphasise this repeatedly, since one might otherwise gain the false impression that “nothing is moving forward”.
Why we introduced Kanban
Our team currently consists of eleven men (it may be hard to believe, but they are in fact all men!). Each of these colleagues simultaneously has between one and eight Requirements in progress. That comes to a total of about 40 to 50 tasks that are being processed at the same time. Then there are various Requirements “corpses”, often representing a half-finished product that has fallen victim to a change in priorities. Even long-time employees who have some knowledge of practically every area – let alone their younger colleagues – find it impossible to maintain an overview of this number of development tasks.
Then there is the fact that there are always log jams in certain phases of development, which everyone knew, but could not fully get a handle on. And last but not least, discussions with the departments about the development progress were always difficult, because there were no simple means to get an overall picture of the status of the individual development tasks. For this purpose, we have found exactly the right tool in Kanban.
Various Porsche IT departments have chosen Kanban as their methodology for the agile software development process – always with success. One example like ours has already been documented, and you can read about it in this blog post: https://www.poi-france.fr/das-taegliche-chaos-beherrschen-kann-man-mit-Kanban/
The interesting thing is that you can find various Kanban boards in our halls and open areas – but none resemble the others; they are all different. This is true even though many of them started out very similar, for the simple reason that we naturally exchange experiences between departments, so a lot of knowledge is shared in passing.
The meaning of the board
The Kanban board represents the core of the software development process, which it models for everyone in a visible manner. At a single glance, one gets an overview of the current status of Requirements currently being actively handled.
How we introduced Kanban
Our basic aim during the introduction was to model the actual situation. In other words, no process changes were necessary to introduce Kanban. It was clear that Kanban would allow us to detect weak points or even contradictions in our processes, so that changes and improvements would be made gradually.
About a month before the introduction, there was an internal informational event featuring “Mr Kanban” at Porsche IT, Anton Spitzer, who brought everyone up to date in a very positive way and clarified the topic of Kanban for all involved. This shared view of the topic made the introduction about a month later much easier. Of course, there were some critical voices as well. These primarily focused on the fact that Kanban could never model the whole reality – which is entirely correct. At the end of the event, however, it was clear to everyone that it is better to have transparency and a very well-defined procedure for at least a large part of our activities than to have nothing.
What tasks go onto the board?
About six weeks before the introduction of Kanban, we started holding 14-day prioritisation meetings with the departments. These meetings resulted in 20 prioritised tasks. These priorities correspond to the priorities on the cards. After two weeks, some of these tasks are generally completed. There is a reassignment of priorities and new tasks are added. A backlog is also created for tasks that have not yet been prioritised.
The Kanban meeting
Twice weekly, there is a Kanban meeting in front of the Kanban board. It is attended by all employees. Each employee gives a short (!) comment on his cards and moves the ones that have changed status. If there are any business questions to be clarified, this is NOT done in the Kanban meeting.
Later changes to board and cards
A great advantage of Kanban is that, if weaknesses are found in the process, Kanban can be adapted gradually to the changed process. For example, even in the first two months, we made a number of changes to our process and therefore altered its presentation on the board:
Multiple employees can work on a task
In the very first Kanban meeting, it turned out that it happens relatively frequently that multiple employees work on a task. Modelling this is fairly easy: Magnets for all the employees involved are placed onto the card.
External employees
There are some tasks in which external employees (e.g. people directly from SAP) are involved. There was a general feeling that this should be visible. To do this, some magnets were made with the initials “EXT” and then used exactly as for internal employees.
Start date
If there is a fixed schedule for the start of a Requirement (e.g. due to a change in laws), this should be printed on the card.
Tasks for the base team
Some of the tasks of the base team – which is responsible primarily for making the SAP infrastructure available – are relevant to our team (especially the setup of permissions). As a result, cards are printed and placed on the board for these tasks as well.
Undefined status
It turned out that there are some process states that cannot be modelled. An example of this is when a task has already been marked as successfully tested by the specialist department, but it then turns out that additional changes are required. In this case, the card has to be reset to an earlier status, which is not possible in the requirements database. We mark this kind of task with a red “!” magnet.
Documentation created
A mark on the card (e.g. a yellow stripe with a highlighter) is now used to record the fact that new documentation has been created for the requirement. This makes it very easy to see where documentation is still needed.
Review performed
Another mark on the card (such as a red stripe with a highlighter or simply the initials of the employee in question) then documents that this Requirement has been reviewed by another colleague.
Projects
The states that projects go through are fundamentally different from those of Requirements – this is why we chose not to model them on the board. Many employees were not pleased about this, as projects take up a considerable part of every working day.
We consequently extended the board with another lane (row) called “Projects”. The project name is fastened to the left edge with a Post-it. The associated work packages – even if they do not go through exactly the same states as Requirements – are then also positioned on the board with a Post-it in the status column that best corresponds to their situation. The presentation is not 100% correct and results in a certain distortion, but it does help to provide a better overview of the overall situation – at least, we tell ourselves it does.
Since this change was only introduced recently, we still lack the experience to state a definitive answer.
Along with the introduction of a separate lane for projects, separate lanes were also made for prioritised and non-prioritised projects. This gives the board a fundamentally different appearance:
What has Kanban achieved?
Transparency in all directions
The fact that all the Requirements currently being processed are placed on a single board makes the entirety of the tasks (without the projects or tickets, of course) visible at a glance. One can see immediately the status of important (= high-priority) tasks. One can also immediately see when activities are blocked for different reasons. But that is exactly the basis for improvements.
Detection of process weaknesses
Until now, we were not aware that there are some process states that are actually not possible. We still have no solution to this situation – but at least we know there is a problem and have the opportunity to work on it.
Detection of bottlenecks
In the software development cycle, it happens time and again that things pile up here and there. The problem is that these bottlenecks are often difficult to discern. With Kanban, we can see very quickly where things are getting stuck – and, in many cases, why.
Detection of parallel tasks for employees
Employees complain (justifiably!) that they have to work on too many tasks at the same time – and these complaints often fall on deaf ears. A glance at the board makes the situation visible quickly and impressively.
Detection of parallel states
Ten tasks have to be tested at the same time? That cannot work, and will not work. In every Kanban meeting, we can see very quickly which activities are crowded and, in particular, which activities run the risk in future of being the next bottleneck.
Detection of priority changes
Every two weeks, priorities are redefined together with the specialist departments. Ideally, many tasks prioritised in the last meeting will already have been completed and therefore removed from the list. But when tasks remain on the board, their priority actually needs to be higher than last time. Since we write the priority on the card, when priorities change the old priority has to be crossed out and the new one written next to it, so it is immediately obvious whether or not the series rises continuously (which it actually should). If not, we need to work together with the department to clarify why the task has lost importance.
Downsides
Yes, Kanban also has its downsides! In principle, Kanban can only show problems, not solve them.
In our case, there are two points worth discussing:
- Not everything is on the board
- Large and small tasks
Not everything is on the board
Three large areas initially remained separate and were not modelled on the board:
- Projects (such as country introductions)
- Tickets (troubleshooting)
- Requirements from private retail
The board therefore reflected only part of the working reality in the team. At least for projects and private retail, we have found a solution. Since tickets are so short-lived, we will probably never have them on the board.
Large and small tasks
The size of Requirements varies from a few hours to over a hundred. This is visible on the cards in the “Effort” field – but only when you go into the details. We temporarily solved this issue by marking tasks from “up to 80 h” with a highlighter.
Looking ahead – further possible steps
There are a number of options for getting even more out of our software development process. Below are a few suggestions that have not yet been decided, but which have already been identified by some of our colleagues:
Reports
The transparency of Kanban makes it possible to measure different metrics that permit a historical comparison.
These metrics could include:
- Average process time of a card
- Average waiting times for particular reactions (releases or tests)
- Average time spent in a given status
- Average number of cards in a given status
Limits
A basic principle of Kanban is that there is a maximum number of cards for each status (i.e. for each column) that can never be exceeded. This surprisingly results in a significant improvement in the process time of a card. We have not yet defined limits, but we will do so in the near future, once we have the necessary experience.
Mutual support
The introduction of limits will result in free time for some employees. These can and should be used to help colleagues move their cards further. This will not only accelerate the process time of the card, but will also serve to disseminate knowledge.
Conclusion
Before the introduction of Kanban, there were certainly some critical voices. In particular, these addressed the fact that the board only shows Requirements (and now projects, too) but not tickets. However, the alternative would be to forego the transparency and other advantages of Kanban in the Requirements area as well.
After three months of Kanban, we can definitively say that all the critics have been silenced, and that all our expectations for Kanban have not only been met, but exceeded. Be that as it may, the journey is not yet at an end – and will likely never be. This is simply due to the fact that our software development process is subject to continuous change and must therefore always be adapted to new needs.
