Kanban Nightmares

I’ve mentioned in my previous post that I have less time for coding nowadays. I’ve started to lead a new team with the intention to introduce Kanban in their way of working. In this post, I’m going to share the result of this introduction.

In these last few years I’ve had opportunities to observe coaches and consultants how they help teams and organizations. I’ve been reading about how it should be done in the proper way. In most of the cases, the person who helps the teams asks questions, points out certain areas of improvement, keeps general coding sessions, but does not get involved in the teams’ life. No offence, but I don’t see how someone can help without taking responsibility. The intention he has is loud and clear: make the teams self-aware, self-organizing and independent. But there is a fair question, though: “H**ow can a team be self-organizing if, before agile was introduced, they had been told what to do for years? How can they make decisions?” After these years, I can state that this approach is not really effective for novice teams. It is very good for advanced teams, who might miss some improvement opportunities occasionally, but are able to react if that missing piece comes to light by a coach or external advisor.

Another common mistake and myth is that the ScrumMaster should not be involved in the team’s decision making process and daily work. In novice teams, no matter what experts say, the team members want to follow the ScrumMaster, they want to hear what he thinks and they want to follow his lead. This may sound non-agile, but if someone wants to be successful with agile methodologies, he shouldn’t ignore this fact. The ScrumMaster should coach the team like the managers at Toyota in TPS, he should give background information, and show examples on how to make decisions and how to be agile, and not just do agile. This cannot be done without the involvement of the ScrumMaster in the beginning. Teaching by example is very important. If done properly then, based on my experience, teams won’t be lost when the ScrumMaster is no longer with the team. They will continue their work, they will start being agile, and won’t depend on the ScrumMaster. There is going to be a slight setback in their work, because the team will have less new ideas due to the absence of the ScrumMaster. Fortunately, they will have learnt from the ScrumMaster how to be agile by then - and not just do agile -, so someone will start driving the changes, others will follow, and a real agile team will start forming.

Patrick Kua once said: “you had to make your hands dirty”. I really like this idea, and I’m following it. I know about somebody else with the same attitude, but he is not working in the software development industry: Gordon Ramsay. He divides people, but one has to admit that he is doing a pretty good job with kitchen staffs in his TV series Kitchen Nightmares. In the episodes, Gordon visits a restaurant in need of help and stays with them for about a week. He joins the staff, gives them energy during their daily work. He looks for bottlenecks and improvement opportunities, and tries to improve the staff members to be better at their job with face-to-face or group discussions. The show usually has a happy ending, but Gordon revisits a couple of the restaurants after a while. Some of them perform very well, but some of them have already been closed or have gone back to the old way of working. One very important thing: Gordon always emphasizes that customer satisfaction is very important. All of his actions are driven by this: the restaurant shall serve good quality food for the customer in a reasonable time. I’ve seen this approach in a very different document: in the agile manifesto.

I prefer this kind of coaching over the “question asking” type, however, the yelling and swearing is not really my area - Gordon swears a lot during his shows. He works with kitchen staff in a way very similar to how I’m working with teams new to agile, so in the next part I’m going to write about what and how I did in certain cases.

The team I temporarily joined sits next to my team, so I had some time to observe how they are doing. They don’t have a close customer relationship, but they have to work with other teams on a daily basis. They did their work, but due to their position in the organization, they received a lot of criticism. Recently, they got a very important task which needed to be done, but finishing this task would have come at the expense of their weekly duties. I always thought that they could do it, because they have the technical skills, but they could have been organized better. So I asked the management whether I could join, and they said yes.

I started the work with changing their board. They had a Kanban-like board, but it wasn’t really updated, it was in the wrong place, and it was really hard to find out what the team was doing at any given moment, what kind of problems they had, and what their overall state was. A board is similar to a restaurant’s menu. Gordon always changes the menu without asking for the staff’s opinion. There is always resistance, but it is one of the key moments of the show, this is the “kick-off”.

So I drew a completely new Kanban board for the team in a place where the entire team could see from their workplaces. Previously, the board had been around the corner, so the team members had to stand up and go there if they wanted to do something with the board. After a quick explanation, the basic Kanban rules were clear for the team. I was surprised, because there was no resistance, and I got the impression that the team liked the new place and the new Kanban board. The WIP limits of the columns were changeable, but I insisted that the global WIP limit remain the same. I calculated how much parallel work the individuals could do in the team, summed it up, and got the global WIP limit. Additionally, I wanted to know the actual output of the team, without putting them under unnecessary pressure. Therefore I needed a quite fair global WIP limit.

I didn’t plan and didn’t do another major change in the team. From this point on I started to work with the team on an organizational level. Usually, Gordon starts cooking with the staff, but in my case, I did not interfere with their technical work. I was - and still I am - sure that their problem can be solved on an organizational level.

I supervised the daily stand-up meetings during the first weeks. In Kitchen Nightmares Gordon is very rigorous about the cleanness of the kitchen, so am I with the boards and stand-up meetings. People won’t get focused if you ask them to be focused. This skill can be thought by closer supervising and setting an example from the beginning. Every time the board was used in a wrong way, or somebody had a question about how to handle a certain situation, we took the time and discussed it. If at a later time the same thing happened again, I pointed it out and we did the discussion again. There is nothing wrong with pointing out problems. Usually, people don’t like this, but if the situation is solved right at the spot, they will accept it and learn from it. Fortunately, there was no need for yelling.

In the beginning, the stand-up was very similar to a daily scrum meeting. Everybody answered the three questions, but it wasn’t that effective, so I asked the team to change the meeting style and talk about the ongoing tasks in a priority order: starting from the top right and going backwards to the left. With this approach, the meeting went faster, and the information exchange was more effective, because

there were less discussions about irrelevant personal topics
we found tasks which weren’t on the board because colleagues wanted to talk about more than what could be seen on the Kanban board. Since these topics weren’t represented on the board, it was really hard to discuss them. So new items showed up, making the daily work more visible and transparent
we almost finished the meeting in 15 minutes, which was rare before

Although the meeting was better and more effective, we did not manage to talk about items in the parking lot and blocking issues. The next change we made was that we started with the parking lot, talked about only those items which were blocked or had problems. The philosophy behind this idea is to make the flow clear in the value stream. This was my last idea for the daily stand-up, which the team enhanced: they decided they would talk about the technical details during an optional discussion after the daily stand-up. Unfortunately, there were several hamsters in the team, but it was a small issue compared to the others.

The former team leader - who became the technical team leader for this period - and I had a lot of face-to-face discussions - similarity to the “do you have two minutes” from the show. During these “two minutes” we discussed what, why and how to do in a certain situation. My goal was to share as much information and technique as possible with the team leader so that he can continue the work without me. We even agreed that he would read the Kanban book from David J. Anderson, so that he would have the lexical knowledge for successfully working with his team. He got one and a half hours every day for reading. After that, we discussed the topics he read, and clarified the details still unclear to them. Fortunately, there were only a few of these.

The content of the Queue, the prioritization, and keeping the basic rules of Kanban required attention almost on an hourly basis. By default, I was the only one allowed to change the contents of the Queue. I explained every prioritization move, gave background information about why we had to do something the way we did, and why today’s situation is different from yesterday’s. Despite my efforts and explanations, new items showed up at wrong places (like bad food coming back to the kitchen in Kitchen Nightmares after Gordon’s help and insights), even in the Queue. In each case we suspended the work, or took some time during the daily stand-up, and discussed the situation of that particular item. After a month, this started to improve: items were almost at the place where they ought to have been. This was the time when I silently gave up my authority over the Queue, and let the team leader organize it and finish this improvement.

The Queue was not the only problematic part of the Kanban board. Every single column - every phase of our work - required daily discussions and improvements. There were a lot of conflicts, because every time something was at the wrong place, we discussed it - sometimes even the technical background as well - until the team had all the information and practice to use the board in the proper way.

After a while, the team no longer needed me for introducing new things in their daily work. We had three retrospectives so far, and all the change proposals came from members. This made the team a bit better each time. During these retrospectives, I tried to move the team’s focus towards fair work distribution. In other words; everyone shall do the same amount of work.

I mentioned the Kanban board before. Now, after these changes, the board looks different, both the team and I think that it is better than the one they started out with. In order to reach this point, the team needed the “kick-off”. The only task I had was to keep them on the right track, by pointing out situations, that needed to be discussed. What happened is not a miracle or a fairy tale. We are very far from a highly efficient and successful agile team. I would say that the team’s work is more transparent for the management and for the team (the workflow and the current state is clear for everyone), and there is less context switching than at the beginning (the WIP limit is working). The team feels better, the management feels better, the next task is to stabilize the current situation, and after that, to speed up the process (decrease the current lead time).

The interactions described above took a lot of time, but I spent most of my working hours defending the team from external sources (management, other teams), who came by all time with new work items, questions and requests. They ignored our new way of working, made the colleagues exhausted and angry with unnecessary and unhealthy direct interruptions. Teams should interact a lot, this is beyond question, but when it turns unhealthy, meaning a lot of RTFM questions and “top-top-top priority issues”, it has to be stopped. Learning and performing cannot be done under such pressure, so I did everything in my power to stop these interruptions and allow the team learn this new way of working, instead of having to handle external sources. After me leaving the team, this pressure will still be there, and somebody - or the whole team - has to stand up and take over the task of defending themselves. I had an ambition to find out what the real output of the team is. Now it is clear, well published, and hopefully accepted by the external sources, so the pressure should start to decrease. I think I got my hands dirty, time will eventually tell how this turns out.

I know that a couple of the readers won’t agree with this methodology, and ask: “Where is the self-organizing team in this way of working?” In my experience, self-organization rarely happens immediately and by itself, so I have no problem with a small or larger external “kick-off”. If it is done properly and the team learns the necessary skills from this external entity - in my example, this is me, in the Kitchen Nightmare example, it is Gordon -, then it will work fine. This external entity doesn’t necessary have to be the ScrumMaster or the team leader, it can be an experienced agile developer or tester. The point is to bring the principles and dynamism into the team, show an example, be there for answering questions and for discussions, do mentoring **properly**, but most importantly: after a while, let the team do things on their own. This time can be a week, or a month. In Gordon’s case it is a week, in my case it is two months.

To sum up, here are the key moments from the study:

Bring dynamism into the team’s life
Visualize the workflow and take care of the global WIP limit
Teach the team how to handle blocking items
Introduce new techniques, and do not forget to explain them in detail
Do not push more work on the team, let’s have a clear picture of their real output
Take care of fair work distribution
Mentor everybody on the team even if you have to tell things multiple times

We are in the “letting go” phase at the moment. I’m going to leave them completely alone, and revisit them in 1 or 2 months. This period will tell me how much influence I had, and how much the team can achieve on its own. I’ll keep you updated in the comments about the progress.

Share on