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.
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 :).
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.