Employee<\/strong><\/p>\n 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\u2019s initials on it. They are used to establish a connection between the employee and the task. If an employee\u2019s magnet is placed onto a task, this means that the employee is working on the corresponding task.<\/p>\n Task<\/strong><\/p>\n 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.<\/p>\n State<\/strong><\/p>\n 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.<\/p>\n Kanban board<\/strong><\/p>\n 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.<\/p>\n \u201cWe\u201d, in this case, means the \u201cSAP Engineering\/Cons Finance & Reporting\u201d team. We are responsible for the further development and maintenance of SAP FI\/CO for Porsche Holding Salzburg (PHS).<\/p>\n Our activities consist primarily of the following three tasks:<\/p>\n 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 \u2013 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 \u201cnothing is moving forward\u201d.<\/p>\n 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 \u201ccorpses\u201d, 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 \u2013 let alone their younger colleagues \u2013 find it impossible to maintain an overview of this number of development tasks.<\/p>\n 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.<\/p>\n Various Porsche IT departments have chosen Kanban as their methodology for the agile software development process \u2013 always with success. One example like ours has already been documented, and you can read about it in this blog post: https:\/\/www.digilabitalia.com\/das-taegliche-chaos-beherrschen-kann-man-mit-Kanban\/<\/p>\n The interesting thing is that you can find various Kanban boards in our halls and open areas \u2013 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n About a month before the introduction, there was an internal informational event featuring \u201cMr Kanban\u201d 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 \u2013 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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:<\/p>\n Multiple employees can work on a task<\/strong><\/p>\n 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.<\/p>\n External employees<\/strong><\/p>\n 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.<\/p>\n Start date<\/strong><\/p>\n 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.<\/p>\n Tasks for the base team<\/strong><\/p>\n Some of the tasks of the base team \u2013 which is responsible primarily for making the SAP infrastructure available \u2013 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.<\/p>\n Undefined status<\/strong><\/p>\n 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 \u201c!\u201d magnet.<\/p>\n Documentation created<\/strong><\/p>\n 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.<\/p>\n Review performed<\/strong><\/p>\n 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.<\/p>\n Projects<\/strong><\/p>\n The states that projects go through are fundamentally different from those of Requirements \u2013 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.<\/p>\n We consequently extended the board with another lane (row) called \u201cProjects\u201d. The project name is fastened to the left edge with a Post-it. The associated work packages \u2013 even if they do not go through exactly the same states as Requirements \u2013 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 \u2013 at least, we tell ourselves it does.<\/p>\n Since this change was only introduced recently, we still lack the experience to state a definitive answer.<\/p>\n 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:<\/p>\n Transparency in all directions<\/strong><\/p>\n 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.<\/p>\n Detection of process weaknesses<\/strong><\/p>\n 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 \u2013 but at least we know there is a problem and have the opportunity to work on it.<\/p>\n Detection of bottlenecks<\/strong><\/p>\n 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 \u2013 and, in many cases, why.<\/p>\n Detection of parallel tasks for employees<\/strong><\/p>\n Employees complain (justifiably!) that they have to work on too many tasks at the same time \u2013 and these complaints often fall on deaf ears. A glance at the board makes the situation visible quickly and impressively.<\/p>\n Detection of parallel states<\/strong><\/p>\n 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.<\/p>\n Detection of priority changes<\/strong><\/p>\n 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.<\/p>\n Yes, Kanban also has its downsides! In principle, Kanban can only show problems, not solve them.<\/p>\n In our case, there are two points worth discussing:<\/p>\n Not everything is on the board<\/strong><\/p>\n Three large areas initially remained separate and were not modelled on the board:<\/p>\n 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.<\/p>\n Large and small tasks<\/strong><\/p>\n The size of Requirements varies from a few hours to over a hundred. This is visible on the cards in the \u201cEffort\u201d field \u2013 but only when you go into the details. We temporarily solved this issue by marking tasks from “up to 80 h” with a highlighter.<\/p>\n 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:<\/p>\n Reports<\/strong><\/p>\n The transparency of Kanban makes it possible to measure different metrics that permit a historical comparison.<\/p>\n These metrics could include:<\/p>\n Limits<\/strong><\/p>\n 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.<\/p>\n Mutual support<\/strong><\/p>\n 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.<\/p>\n 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. Hundreds of tasks, eleven possible states, eleven employees involved, plus various customers…. How are we supposed to stay in the […]<\/p>\n","protected":false},"author":2,"featured_media":2021,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[24],"tags":[192,69,191,195,70,190,108,105],"class_list":["post-2040","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-collaboration","tag-kanban-en","tag-methods","tag-sap","tag-scrum-en","tag-software-development","tag-team","tag-verbesserung-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/posts\/2040","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/comments?post=2040"}],"version-history":[{"count":0,"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/posts\/2040\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/media\/2021"}],"wp:attachment":[{"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/media?parent=2040"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/categories?post=2040"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.digilabitalia.com\/en\/wp-json\/wp\/v2\/tags?post=2040"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/www.digilabitalia.com\/wp-content\/uploads\/2018\/09\/image1.png\")
<\/p>\n![\"\"](\"https:\/\/www.digilabitalia.com\/wp-content\/uploads\/2018\/09\/image2.png\")
<\/p>\nWof\u00fcr wir Kanban verwenden<\/h3>\n
\n
Why we introduced Kanban<\/h3>\n
The meaning of the board<\/h3>\n
![\"\"](\"https:\/\/www.digilabitalia.com\/wp-content\/uploads\/2018\/09\/image3-1024x805.png\")
<\/p>\nHow we introduced Kanban<\/h3>\n
What tasks go onto the board?<\/h3>\n
The Kanban meeting<\/h3>\n
Later changes to board and cards<\/h3>\n
![\"\"](\"https:\/\/www.digilabitalia.com\/wp-content\/uploads\/2018\/09\/image4.jpeg\")
<\/p>\n![\"\"](\"https:\/\/www.digilabitalia.com\/wp-content\/uploads\/2018\/09\/image5-1024x520.jpeg\")
<\/p>\nWhat has Kanban achieved?<\/h3>\n
<\/p>\nDownsides<\/h3>\n
\n
\n
Looking ahead \u2013 further possible steps<\/h3>\n
\n
Conclusion<\/h3>\n
\nAfter 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 \u2013 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.<\/p>\n","protected":false},"excerpt":{"rendered":"