The first row of our Lean Development Method-Board


Hi, my name is Thomas and I am currently working as a software application engineer for the Business Unit Hybrid Electric Vehicle (HEV). To be more specific I am working for the Mildhybrid eDrives (MHD) segment, implementing electrical machine control functions. My team is using the KANBAN development method and I want to give you a little introduction into the subject and show benefits for new employees.

A little bit about myself. I studied electric engineering at the OTH Regensburg, Germany with a focus on electrical machines and I always wanted to work within this field. For my master thesis I switched to HEV Central Engineering and I wrote about electrical machines with six phases. As a subject for my thesis this was perfect, because it was my main focus during my studies and overall just an extremely interesting subject.

After I got my degree, I got the opportunity to join HEV, this time as a software application engineer, working for segment. I am lucky to still have contact with the supervisors of my thesis and my former colleagues. Because of my background with electrical machines I am responsible for the Electrical Machine Application (EMA). KANBAN helped me get introduced to other components (like safety related topics, requirements or diagnosis) and structure the start of my new job.

So what is KANBAN and how does it work?

The word KANBAN is a combination of two Japanese words: KAN (meaning signal) and BAN (meaning card). One big part of KANBAN is the visualization of the current task progress, which is usually represented by cards. Bigger tasks of the project are divided into smaller tasks or features and are being written onto cards. These cards are being hung onto a whiteboard with different columns. Each column represents a certain state in which the task can be in, e.g. “in work”, “under test”, “review” or “done”. The cards then start on the right side of the board and make their way through the columns to the left side. This cycle is called iteration or sprint. The duration of a sprint in my team is usually two weeks. At the beginning of a sprint the current tasks are distributed. The goal of KANBAN is to maximize the degree of completion of these tasks and guarantee continuous incremental improvements (flow). Therefore, they should be kept as small as possible.

Close up of a cell of the board. The note says “Please estimate all stories”.

Another important aspect of KANBAN is the fact that the number of tasks is limited according to the available team capability and the necessary effort to complete them. KANBAN therefore relies on a pull system in which the developers can decide when they realize a task. This is in contrast to a push system in which tasks are simply given to the next station once they are done. The definitions of the already mentioned states, for example “in work”, need to be clear beforehand. Also it needs to be known when someone is allowed to pull a card to the next column. These definitions can be decided by the individual teams according to their needs. A controlled workflow can therefore be achieved and problems can be determined. This can be crucial in software development, when the customer expects incremental software release at a certain date. A big help for the technical project leader is provided. Every participant of KANBAN is encouraged to give feedback of the current workflow and input for improvements. This is called “Acts of Leadership”.

Lastly one important aspect of KANBAN is the so called “Daily”.

This is a daily reoccurring standup-meeting in front of the KANBAN board. The duration of this meeting is 15 minutes, which should not be exceeded. In this meeting every participant gives a short status report about his current tasks. So typically the following question are answered: What did I do yesterday? What am I doing today? What problems/blockers can occur? It is important to have someone to remind you not to give too many technical details. Only a short status report should be given. This part is taken over by a Scrum Master. Snacks always help keeping the motivation up during the daily :).

The most important column on the board.

As a new employee KANBAN helped me get to know quickly the typical task relevant for my field. Especially since the tasks are kept in a manageable granularity. In addition, I was able to broaden my horizons in a short time and get to know neighboring areas such as safety, requirements, diagnosis and testing. I also learned how to structure one’s own work and which steps are necessary to get incremental improvements in one’s software releases.

Since there is a whole philosophy behind LDM/KANBAN there is more behind the subject than I can manage to cover in a single blog post. For now I hope I could give you a small introduction about the process.



Hi, my name is Thomas Zieglmeier and I am a Software Application Engineer working for powertrain. To be more precise I'm working for the Hybrid Electric Vehicle business unit in the mild hybrid segment. I started working for Continental as a working student for interior (test engineering CFT 211). For my master thesis I switched to powertrain and then had the chance to join Continental.

Mehr Artikel von Thomas

2 thoughts on “Introducing the Agile Development Method KANBAN

  1. Thank you for your article and detailed explanation.
    I have a question, what differe Kanban from Scrum? because they look quite the same.

    1. Hi Farah,
      thank you for your comment. You are actually quite right, both methods are similar. But the devil is in the detail.
      Basically you can say, that you have more freedom working by the KANBAN process.
      This can be shown by the continuity of KANBAN. Let’s say a certain task is not finished during a sprint, this task can stay on the board. This would not be the case in Scrum. Here after every sprint the board must be erased and build from the ground up. The sprint duration can be changed when working by KANBAN.Furthermore roles need to be defined working by Scrum. Your team must be crossfuntional. This is in contrast to KANBAN where expert teams are allowed.
      These are just a few examples. But I think you get the idea, that with KANBAN you can be more flexible and adjust the process to your needs.

Leave a Reply to Zieglmeiert Cancel reply

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