FYI: the original version of this post was published in old 2018.

Friends, hello everyone!

Today I want to tell you how the story of the twenty-seven-person Kanban team ended.

Part 1. First to the conclusions

After posting a failure post and asking for help figuring out where I went wrong, I got a lot of responses. I am very grateful to those who responded. To be honest, after the feedback, two thoughts were spinning in my head:

1. I know absolutely nothing about Kanban.
2. Everything I knew before was wrong.

Of course, this is a slight exaggeration, but this feedback really helped me to look at things I’ve known for a long time in a different way and suggested where I might have made a mistake. Here and now I would like to share my experience and conclusions, so that the scrum masters who follow or are going to follow the same path as me — using the Kanban method in the development team-avoid my mistakes. Guys, this post is for you.

Service Delivery Manager Role

The first and biggest error is an incorrect understanding of the Service Delivery Manager role (hereinafter referred to as SDM). I used to think that this role is a kind of analog of the role of a scrum master from the Scrum framework. But later, in practice and after consulting, I became convinced that this is the role of a manager. A real leadership role.

In the service paradigm, Kanban is the role of the service manager. And since in our case we were talking about the delivery of developed software, the role also corresponded to the name-delivery service manager. So don’t expect that you, as a scrum master, will just call yourself something else, do the same thing as in scrum, and you will be happy. Most likely, this will not work.

The second mistake was taking on this role. My experience confirmed the above — when you are in this role, you accept the obligations of a manager. If you don’t do this, the quality of the service decreases. If you do, it grows. I checked it out. My mistake was to make commitments that I didn’t want to fulfill. I didn’t realize that they were part of the responsibilities of this role, which I unknowingly accepted. Hence the cognitive dissonance. So if you don’t want to become a manager overnight, avoid this role.

In Kanban, there is another role — Service Request Manager (hereinafter referred to as SRM) or Request Service Manager. This role is paired with the SDM. If there is a partnership between them, then it is highly likely that there will be a high-quality level of interaction between the request service and the delivery service. But if there is no role in any of the services, the second role will have to get into the “alien” garden and correct the situation (if it is of course “burning with the soul” for the cause).

In the first post, I described the head of the business team. She is a perfect example of the role of SRM. But due to the fact that I always failed to perform the SDM role, it did not find support and partnership in the delivery service, and because of this, it actually worked for two services. It was probably hard for her (although she didn’t admit it); she always spoke honestly and openly about how she lacked an IT manager.

Cadences

The third mistake was an incorrect understanding of the essence of cadences. In the post with the failure, I described that meetings for twenty people seemed terribly inefficient to me, and I wondered how to scale Kanban, bypassing the limit of 7-9 people, and at the same time maintain flexibility?

It turned out that there is exactly one team cadence in Kanban — a daily kanban rally. All other cadences are managerial. How do you like it? ME-NOT-JERKY! Period. In other words, managers go to meetings to fill out the delivery service queue (when the delivery service undertakes to deliver software, and the request service undertakes to accept what is delivered), to plan delivery (when the software ready for delivery is transferred to the request), and to review the service. SDM, SRM, team representatives if necessary, but not the entire team.

Also, a service review is not an analog of a retrospective. This is an overview of the service with a discussion of metrics such as cumulative flow chart (CFD), control chart, run-time distribution chart, and so on. A retrospective — it is with other goals and for another. So be prepared to work with managers on these cadences.

Role of the Scrummaster

Separately, I want to say a few words about the role of the scrum master. From the consultation, I came to the following conclusion — this role is still important and necessary in the organization, but more like the role of a team coach or coach for a team (group of people) of the service. If you want — the role of the change agent.

I will give you an example – conducting a restrospective. An important event that helps the group draw conclusions about the past time period and decide what can be improved in interaction both internally and externally in the future. A scrum master as a coach is a very important participant in the process of developing people and organizations, but he has completely different goals than SDM. Avoid my mistake.

Management

Finally, I want to reflect on the importance of the word “management” in Kanban and the fashionable trend for self-organisation. If we look at the Kanban method training, we will find the word “management” in the name of the trainings dedicated to Kanban System Design – Kanban Management Professional I — and cadences — Kanban Management Professional II.

The fourth mistake was to exclude this word from the attention zone and focus only on the self-organisation of the team. The result was a complete disregard for the importance of at least some managerial activity in the team and an unwillingness to do one very important thing when the team comes to a dead end — to take responsibility for what is happening. In other words: “Let’s do something about it”. I was afraid that managerial influence (read “ego”) would kill initiative and self-organisation in the team.

Now that I understand the value of the SDM role, I would like to test in practice that encouraging leadership at all levels and managing work, not people, with giving people the opportunity to organise around it, following the values of Kanban will create in the organisation what I so loved the principles of the agile manifesto.

I understand that today, more than ever, we need good, experienced IT managers to even out the skew caused by rampant “self-organization” without understanding how to introduce it. As a business executive said: “Yes, we have enough of this self-organization. We have plenty of it. Take at least the cucumber autotests, which the developers wrote themselves to help testers. We need a manager!”

Part 2. And now, how did it end

After the consultation, I met again with the head of the business team. My goal was to share my insights and honestly admit where and how I screwed up, transferring the team to use Kanban with the understanding of the method that I had. After discussing the errors and listening to the service’s suggestions once again, we realized that we don’t need a strict division into three teams, but there is a need to create a manager function and divide it into three service classes, according to the business areas.

We agreed on what needs to be changed in the daily kanban meeting, how to focus the work of the students so that all three classes receive the necessary service now, how the level of service will adjust to changes in the load later, and who will perform the function of a manager in each class (so far, yes). With the results, we went to the guys, and the general meeting, in my opinion, went very well. Now the team is working according to plan, and both services have entered a productive channel of interaction. Although, of course, there is still a lot of work ahead.

Recommendations

Finally, I want to give a number of recommendations.

1. Attend Kanban training sessions.
2. Read books on Kanban.
3. Describe cases, ask questions, and share your experience in the kanban community.*

* – required. It was the description of the case in the community and questions about it that helped me find answers and form the next steps in solving the problem.

Good luck, friends!