Kanban in IT? Really and truly?
Today, I should like to give you a brief insight into the working procedures and methods we are using in our teams. So I thought I would tell you how we in Information Management are working with the kanban method.
When during a coffee break I told a colleague from another department that I had attended a basic training course on “Understanding kanban”, he immediately asked: “Why? Are you moving to the production team?” “No, I’m not – as of now, we’re using it ourselves” was my answer, and the guy I was talking to was very astonished. After all, kanban is generally known as a method of production process control and you think immediately of production and manufacturing and the Japanese automaker Toyota (acknowledged as the inventor of the kanban method) – and not in the slightest of IT.
However, kanban is also ideal as an agile project method for use in IT departments, and that’s precisely what I shall now be explaining in more detail.
In IT work, there are not only major projects that are planned and controlled using project methods, and managed and visualised using appropriate software programs. There are also lots of small task packages (e.g. changes), for which this procedural approach would be overdimensioned, since, for example, there are no milestones, and they are often – seen in isolation – not particularly complex. But due to the multiplicity of these minor activities, it is essential that these, too, are tackled in a coordinated manner, which in best case will even reduce the throughput time.
This is why the first step is to visualise the existing process. For this purpose, a presentation board with cards or post-it notes is used and the stations involved are depicted as columns – and what’s called the kanban board has already been created. Each card symbolises a task, and moves from left to right as the process progresses.
The next step is to quantify the maximum number of tasks to be performed simultaneously, which is called the WiP limit (WiP= Work in Progress). This restriction prevents too many things being tackled in parallel but none of them being completed. So it’s assured that concentrated work can be done on each individual task, enabling them to be completed faster. So a new task cannot be accepted until an existing task has been completed, freeing up the requisite capacity. And it’s also important to ensure that the completed task cannot be simply transferred to the next column – and thus shoved off onto someone else. This is because here, too, there are limits, and each task has to be “fetched” proactively by the employee concerned on his/her own responsibility.
The aim of kanban is to achieve a steady flow in the process, to reduce waiting times, and thus ensure a faster throughput time. Thanks to simple visualisation on the board, there is transparency for everyone involved regarding distribution and status of the tasks and any existing bottlenecks. Regular analyses of the board help to detect weak points and initiate appropriate countermeasures, thus ensuring continuous improvement of the process.
Well, that was almost an overdose of theory. And now what do things look like in practice?
Several teams in Information Management have now been working with a kanban board for approximately 4 to 9 months. As an example for all the other boards, I’ve chosen to spotlight the kanban board for the Logistics & Transport department. Here, a weekly team meeting is held, in which the kanban board with its ongoing tasks is discussed with all team members.
Once a month, the board management and the representatives from the specialist department hold a review meeting. This is where it gets particularly exciting. They jointly discuss what issues are placed in the inbox with what priorities. In our case, for example, only eight cards may be posted in the inbox, and the importance of the issues involved can be seen from top to bottom. Then each card is discussed in the following columns (RoC = Rise of Change, PoC = Planning of Change, DoC = Development of Change and EoC = End of Change*). Delays are immediately visible – whether on the part of the development people or when a task had been passed quite a long time ago to the specialist department for acceptance-testing, for example, and is not being processed there. Also, it may occasionally happen that a card located in the middle of the process no longer has any priority due to unforeseen circumstances. This card then moves downwards into what is called the “graveyard” or, as is the case with this board into the “Trash”.
Thanks to this coordinatory meeting, both sides – client and processor, in our case the specialist department and IM – always have the same knowledge regarding the status of the tasks. This transparency is for us an important step towards more specialist-department satisfaction, since with the previous methods it was not possible for us to visualise our processes. Also, the specialist department (meaning our colleagues from Logistics & Transport) exerts a direct influence on what tasks are implemented first. However, the representatives of the specialist departments are also obligated to assume responsibility: for example, business processes have to be clarified before prioritisation, and prioritising tasks requires appropriate prerogatives.
It’s early days as yet for using the kanban method, but our experience so far has been highly encouraging, and we hope that it will help to establish a culture of continuous improvement.