A couple of days ago, I talked to the head of an organisation, who was having a hard time to get an overview of the current work of her organisation, and struggling to have enough manpower in order to deliver products in time. This is a common problem, I had talked to other leaders who had the same issue, and in fact I was in a similar situation before myself. As a solution, we introduced Kanban on the organisation level.
The Problems
Before jumping into the middle, let’s have a look at the problems which triggered this introduction in my case:
-
Missing overview of the ongoing work items
-
Not enough manpower to deliver
Why is it hard to get an overview? It is a very good question indeed. Usually the head of an organisation - later on in this article I’m going to refer to her as leader -, has to deal with several things during the day, and it is very easy to lose track of the recent events, which may change on hourly or daily basis. Usually she only gets back into the picture when something turns south, but usually by then it is already too late.
In a healthy organisation, everybody is working on something, but for how long, when will it be finished, how much effort has been spent on it? These are also very good questions, and usually one has to dig quite deep in the organisation to find the answers. These answers are crucial for acquiring new work items into the organisation. Unfortunately, they are very often incorrect, and takes time to get them, so leaders take new work items based on inaccurate data, and then the organisation becomes overburden.
I truly believe that using a Kanban system can help solve such problems. Let’s see how.
Kanban [board] on the Top of the Organisation
Let’s have a look at the top three principles of Kanban:
-
Visualize the workflow - what is the current status of the organisation
-
Limit the work in progress (WIP) - how much work the organisation can do
-
Measure and optimize lead time - how fast the organisation goes
Perfect, it seems that the visualize the workflow principle can solve our missing overview problem, and somehow the limit the WIP correlates with the lack of manpower issue. It seems that the lead time measurement is irrelevant at the moment, but actually it isn’t. WIP limits and lead times have an indirect effect on the resource availability: they can solve our manpower problem.
The following board structure demonstrates the visualize the workflow and limit the WIP principles in case of an organisation:
When the leader looks at the top Kanban board, it is obvious which team is working on which work item at the moment, and more importantly she can also see which phase these items are in. Mind the green numbers on the top each column, these are the WIP limits. They limit the number of the items in a particular column. Limitation ensures that an organisation or a team does not get overburdened. By applying WIP limit on teams, the overburdening can more likely be avoided.
Let’s review the top board, and assume that the customer needs item ‘E’ to be started as soon as possible. ‘Phase 1’ has one item, so we have a free space for item ‘E’, and the leader needs find a team that can start working on it. According to the board, ‘Team 3’ finished item ‘D’, so they are free, and they can start working on ‘E’.
In theory it seems pretty straightforward, but reality usually differs from theory. It may happen that ‘Team 3’ has no idea how to handle item ‘E’, and only ‘Team 1’ is only capable of handling it. This is the point where the lead time comes into the picture. If the board contains information on how long a particular item has been staying in a column, and it is also known how much time for example ‘Team 1’ needs to finish a work item like item ‘A’, then the leader can have a rough idea when item ‘A’ will be finished. If this is within a reasonable time frame, the customers usually accept it, but when it is not or the customer is not satisfied with the answer, then the Kanban system revealed an important deficiency: the exclusive knowledge of ‘Team 1’ is a threat to the organisation.
It is very rare that an organisation can say no to a customer and tell her to come back later when the organisation (internally ‘Team 1’) can take the work item. In real life, ‘Team 1’ will take item ‘E’, but there are things which can be done in order to reduce damage. ’Team 3’ is free to help out ‘Team 1’ finish the remaining work related to item ‘A’. Nevertheless, keep a retrospective and find a way to solve similar situations later.
How To Use The System
Let’s assume that a new work item arrives - item ‘G’ - to the organisation. It can be a feature, a bug, or some kind of enhancement. A very important thing is that on the organisational level, keep every work item as it is, do not split or merge them. The customer or the other organisation who gave the work item does not care about the details, and for the big picture it is enough to track the original work items.
When item ‘G’ can be started, it starts two lives: one on the top board, and one on the board of the team, which is working on it:
‘Team 2’ starts working on item ‘G’ and handles it according to its internal methodology - in this case ‘Team 2’ uses Kanban as well - and splits it into items ‘G1’ and ‘G2’.
Finishing an item is also pretty straightforward. ‘Team 3’ has just finished item ‘B1’, which means that the whole item ‘B’ is done, so it can be moved into the ‘Done’ column of ‘Phase 2’ on the top board. When item ‘B’ can be continued, another team can take it and work on it in ‘Phase 3’.
Finding Bottlenecks
The agile or lean methods won’t help a starting organisation deliver faster, or in better quality. They will expose bottlenecks and problems. Let’s have an example how.
It is very common that one single person is responsible for a very specific task. In the example above ‘Team 3’ is not a team, but a regular guy, who is responsible for translating the texts of the user interface.
Items cannot enter ‘Phase 3’ until everything is ready on the user interface, and this includes the translation. Unfortunately, ‘Team 3’ cannot work more then they currently do - it is physically impossible -, so the whole system is blocked, ‘Team 1’ and ‘Team 2’ became idle. ‘Phase 1’ and ‘Phase 2’ are full, item ‘F’ cannot enter. Even if the WIP limit of ‘Phase 1’ were increased, it wouldn’t help much. The whole flow is blocked in the middle, and in order to earn money, the organisation is supposed to finish items, which is not possible at the moment according to Kanban.
There isn’t any methodology capable of providing a general solution for such problems. Usually, ‘Team 3’ feels bad about the situation and works in their free time in order to finish at least one item, so that the work can be continued either with item ‘A’ or item ‘B’. This isn’t the right solution. With the Kanban approach every information and tool is available, but one should look at it from the correct angle. Here are some possible explanations and solutions:
-
Increase the throughput of ‘Team 3’ by hiring new people, or train ‘Team 2’ or ‘Team 1’ so that they can help out occasionally
-
Maybe ‘Team 3’ could have handled the situation, but ‘Team 2’ and ‘Team 1’ finished almost at the same time. So set the priorities and WIP limits (‘Phase 2’ -> 2), so that they work is kind of shifted
Retrospective
Let’s consider a real life experience. Several months ago, my former boss and I introduced this system in our organisation, and we had serious problems with it so we had to re-think the whole concept. Here are our problems in retrospect:
-
We put every possible task on the organisational board, for example management related work items, which blocked us immediately
-
We had a middle-sized organisation with approximately 40 people, but only 10 of us knew how to work with a Kanban system
-
We had a hard time setting the WIP limits
-
We had an organisational level stand-up twice a week with everybody right after lunch
-
Only the two of us cared about it
What we did differently in the next time (because we tried again):
-
We focused only on work items
-
Explained the process to everybody
-
Had a smaller stand-up before the stand-ups of the other teams
-
We focused only on the visualize the workflow principle
Our first board was filled with small management related work items like creating reports, handling impediments etc. There was hardly any place for actual work items. The teams couldn’t help with them, and they took away precious free slots of our board, so we decided to get rid of them.
This approach was better than the first one. We were able to react faster to changes, management was able to see through the ongoing projects, we could skip a couple of meetings because the information sharing during these stand-up meetings was enough to do our daily work.
A friend of mine pointed out that there is a contradiction between the example above and the last retrospective finding. This is because we didn’t reach the point where we knew, how much work we can do in parallel. The everyday arguments about WIP limits were so frustrating that we decided to postpone the decision on WIP limits. Although I knew and still know that this decision was wrong, I decided to accept the group’s decision.
Would Like to Try It Out?
If you got interested in this approach, here are the steps I recommend to do:
-
Have a physical board, which displays the most important development phases of your organisation
-
Set some WIP limits - you can change them later, of course
-
Collect the actual status of your teams and put it on the board, do not split and leave management related work out
-
Have a daily stand-up meeting in front of this board. Invite at least one person from each team, and discuss every work item from right to left, top to bottom
-
Discuss the daily issues, look for bottlenecks and try to find solutions
-
After this session the different teams can have their own stand-up meetings where they can talk about the issues found during the first stand-up meeting
-
When a team makes progress, update the team’s local board and also the top board so that everybody can recognize that something has changed
-
Start measuring how much time your organisation needs to get an item from the left side of the board to the right
-
Gather your team representatives and try to find a way to shorten this time
This is a very good basis for introduction. Kanban is adaptive enough to be used in any kind of organisation. The teams can work with different methodologies like Scrum, XP, waterfall, DSDM or according to company specific processes.
comments powered by Disqus