Part 1. The Beginning

Hi!

In short, I started with the Kanban Method in a large team and got failed. I want to tell you this story and ask for your advice, where I was wrong?

Briefly about us. We make software that allows customers of the bank, being buyers in online stores of household appliances, to borrow goods on credit. In other words, we represent the online service of consumer lending.

Today it is:

• 8 people in the Discovery Kanban (business team);
• 17 people in the System Kanban;
  • 8 developers;
  • 4 analysts;
  • 3 test engineer;
  • 2 DevOps engineers;
• 2 flow masters.

The team includes all the necessary people to implement the end-to-end process of rendering services to the bank’s customers, with the exception of three service teams:

1. Frontend developer;
2. Backend developers;
3. 24×7 Customer Support.

When I joined the team, the alignment of forces was as follows:

• 14 people in the development team:
  • 8 developers,
  • 1 test engineer,
  • 3 analytsts,
  • 2 DevOps engineers.
• 7 people in a business team.

That guys used the Scrum framework. The Scrum-team consisted of developers and testers. Analysts were upstream and did not participate in filling the sprint and working on the tasks of the sprint. DevOps engineers were downstream and also did not participate in the work on the tasks of the sprint. As a result, it was not clear what exactly analysts are doing, how the increment regression proceeds and what about its deployment to the customers. Because of this, the test engineer had to break between testing tasks in the sprint and regression increment. And analysts wanted a separate upstream sprint to also get sprint tasks and prepare a fixed options of work for the developers, and not switch tasks like the Bell operator’s phone plug on the evening of the weekend. In addition, the increased size of the team worsened the speed of communications. Each meeting with a large crowd turned into torture and boredom for half of the participants.

Before my arrival, the team had a solution. They were going to split into two Scrum-teams and thereby eliminate communication problems. Actually, for this, in part, we were hired with the second Scrum-master. It was planned two Scrum-masters and two Scrum-teams.

When I conducted the audit of the processes, I suggested that using the Kanban method is more suitable for solving the existing problems. The hypothesis was that:

• with the kanban method for 20+ people, we will work more seamlessly, transparently, reduce the burden on the team (exclude failure demand);
• the business will get understanding, what we are working on now and what to focus on next, can absolutely fill the queue with new tasks without waiting for the end of the sprint;
• The Kanban method will increase the flexibility and predictability of the team’s work.
• The Kanban method is more economical in terms of meetings. I calculated the cost of the meeting in two Scrum-teams and in the same team using the Kanban method. The ratio turned out to be approximately eleven against four (we are talking about the number of unique meetings).
• As a result, I decided to transfer the team to the Kanban method, and gradually we did it.

Here there was the most epic fail. I made the decision for the team without even consulting them.

UPD. Later, restoring the sequence of steps, I remembered exactly that the consultation was: both with the leader and with the team. The error turned out to be different.

Part 2. Transition from the Scrum-framework to the use of Kanban Method

S.T.A.T.I.K. First was off-line visualisation

The transition to the Kanban method began with visualisation of the general process of work. On a large board, I, from the end, drew a sequence of actions for one of the features. What did we do to bring it to the market? In solving this problem, I used the elements of the workshop S.T.A.T.I.K. Drawing the process, I called the team, so it looked at the result and put in feedback. With these comments in mind, I moved on to JIRA.

JIRA. Let’s move on to online visualisation

The guy who was the Scrum-master in the team before me and who returned to the fold with my arrival, already started this process, having previously created a board in JIRA. There were not enough only the stages with regress testing and deployment. All this we identified in the previous step. Because of this, it was not clear what happens to the tasks after closing. Having supplemented the process with the missing stage, I realised that I made a mistake in developing the current workflow. There were too many stages. We lived a couple of weeks with this, I saw how much confusion appeared in the team instead of the desired relief, and created a new JIRA workflow from scratch.

On the board it looked like this:

I really liked that he had a common process that was also used in the Scrum-board, where the developers worked. (In general, I still admire the systemic nature of this Scrum-master.) I find it difficult to recall a more comfortable transfer of responsibilities. This life-hack I also adopted for a new workflow, in addition creating boards for analysts and testers. The key idea was this: there is a board with a common process from the beginning of the delivery to the end and there are boards for cycles of analytics, development and testing. On the common board we hold on Kanban meetings. On the boards for cycles, the team works during the day.

I also created a separate board with epics to represent for business department what we are working on now, what we plan to work later, and what is in the backlog.

Thus, we have a hierarchy of kanban-boards:

1. Board with epics – large projects with a duration of up to three months.
2. A common board with all the tasks is detailed on the epics in the work. The main goal was to understand what we are keeping in focus, what kind of project we are working on now and what we need to do to release the next increment at the desired time.
3. A board with tasks for stages was a working tool for daily tasks.

I showed the final result to the Business owner and the team. The Business owner was satisfied. The team had questions, but for the most part of the innovation was accepted silently.

Team training and refusal of estimation

One of the key decisions was training. We conducted the following workshops with the team:

1. Elephant Carpaccio. Purpose: slicing small User Stories.
2. User Story Mapping. Purpose: decomposition of epics into completed user stories and elements.
3. getKanban. Purpose: use of the six practices of Kanban method in the work of the team.

All this combined allowed us to get away from such rituals such as Product Backlog Refinement or task estimation. The team has long had the feeling that such meetings are time to the wind. We decided to check this by removing the meeting, but agreeing (again as an experiment) that the analysts will discuss the problem with the developer before the task is sent to the development queue.

WIP-limits or limitation of work in progress

Following the WIP-limits was, as always, the most difficult practice to use. Here we with the second flow master introduced filters on the JIRA boards on the tasks assigned to each. And the team began to see that in each stage there were a maximum of twice as many tasks as performers.

The most profitable thing

The most profitable, most insightful solution for me was the introduction of a cadence on delivery planning. Due to the fact that we do not have the explicitly assigned role of the release manager, everything goes very painfully with the releases. The situation was very much complicated if our release was affected by general banking release or the task required integration testing with other systems. The most correct solution in my opinion would be the introduction to the team of the explicit role of the release manager (as an experiment for a month, this role was performed by me), but for lack of it we are working with what is.
So, why did the cadence of delivery planning help us so? At this meeting, together with the business, we began to clearly say what tasks will go into the next release, discuss risks, dependencies and agree who will be responsible for the problematic tasks and with whom communication is required.

For releases, we use the Shipping tab in JIRA. Create a new version on this tab, put the increment number and put the name of the version with the increment in the tasks that will go into the release. As a rule, the next release includes tasks from the stages “Testing is ready”, “Testing in work”, “Ready is ready” or “Development in work”. We agreed to limit the number of elements in the release. Now this limit is equal to ten elements. We have a hypothesis that a small number of elements in the release will allow us to regress faster and with less blood.

So, about once every two weeks, we are planning tasks for two releases ahead and in advance we predict the time when we would like to release the next increment. Business understands that when it goes into the support, it plans communications and feels more confident; the team understand what they need to focus on in order to satisfy the customer’s expectations. Delivery of the release “just in time” – our next experiment.

The Role of Service Delivery Manager

Finally, I will tell you a little about the role of Service Delivery Manager. In this team, I was lucky in practice to try this role on myself. To say that I’m crappy is not to say anything. Initially, I went in as a Scrum-master. But for the reasons described above, I decided to transfer the team to Kanban. What to say? If with the services of the Scrum-master I am more and more less clear thanks to the scram-guide today, then with a similar role in Kanban problems have come out.

Firstly, it is not clear what you are responsible for. The wording “for maintaining the flow” in practice sounds very blurry. Nevertheless, the word “manager” very much helps out in the hierarchical structure. I remember how at the very beginning of my work I had a rather intense conversation with the Business owner. She is a brilliant manager, perfectly versed in the product, expecting me to build and maintain the process, guide people and develop in the team. When I explained to her that I see my duties in another, namely, in order to set up the process and transfer it to the team, we both got stuck. I realised the gap between expectations is very large. And that I can not now give her what she wants. She simply did not understand what I would manage in the team, and the word “flow” did not tell her anything. People – yes, the tasks are yes, the flow is not. As a result, we bargained for task management. It was then that I suggested that she try out herself in the role of Service Delivery Manager, once we move on using Kanban. And when she heard the word “manager”, she immediately felt better.

Secondly, you’re still a manager. And this, sorry for my free interpretation of the Agile manifesto, is no longer a self-managed team, if it has a manager. And as the manager in charge of the supply, I could no longer just say: they will do it themselves. Naturally, I started to connect. And at that very moment I cussed for the second time: I suddenly realised that the operational management had ceased to be of interest to me. For ten years I worked as a project manager and administrative manager, I talked with different stakeholders, customers and teams with pleasure, proudly closed projects and saw myself as a great leader. And then suddenly, as my grandmother whispered. So it goes.

Perhaps the most important conclusion I have made for myself after this is that Kanban is a very cool tool for a manager with a dedicated team (as for management 3.0). It was hard for me to get over myself and take the lead in the development process, and I did not have the strength, energy, knowledge and experience to transfer the release management process to the team, but I clearly understood that if you have the desire to control, a tool like Kanban will be today the best help. Especially since two years ago I started the journey in Kanban from Eric Brechner’s book “Agile Project Management with Kanban”.

Part 3. Final. Results and questions

Let me remind you of the current alignment of forces. There are twenty-seven of us.

Today we use the general kanban-board, visualising all the work. The work is divided into epics. Epics are presented in the form of swim-lines. For each epic we see progress and understand the scope of work. Once every two weeks, we fill the queue and plan another delivery. On the board, we filter the release tasks, which helps us to focus on the main and seemingly to satisfy the customer’s wishes.

And then, after two and a half months, the business came and offered to us to be divided into three mini-teams in accordance with the directions:

1. new features;
2. conversion;
3. connection of new partners.

Each direction will have the Business owner. The visualisation of the whole work gave them an understanding that the whole development team was busy in one direction. Because of this, the other two owners have to beg the guys to work on their tasks; the work moves slowly, and they fake the set goals.

Another reason for this separation is the desire to solve the problem with deployment and integration testing. The business agreed to take on this function, appointing it to the owner of the direction. But in return he asked for the division into three teams, so that each owner of the direction would deal with his tasks and probably with his releases (here I’m thinking out).

This idea seemed to put it mildly strange as for me, and everything inside me was against such a separation. It seems to me that we decided to conduct this next experiment too early, not yet completely completing the scheme with the delivery planning. However, since in the development team we did not find anybody wishing to permanently manage the releases (I refused this role after the experiment), and the business can not now release the increment “on their own”, they decided that this would be better. My remark that we are doing what they tell us (that they say that we are doing 100% of one direction is your own decision), until it was heard. It seems to the business that if it clearly divides the flows and explicitly assigns an analyst, developers and a tester to each direction, it will defend itself from itself – from reinforcing one direction at the expense of the other. One last argument from business, with which I find it difficult to argue – in small teams is faster communication. And also business believes that in small teams the level of responsibility for the result is higher.

Friends, tell me what I did wrong? Why have not we gone? I checked four hypotheses, about which I wrote in the first part, qualitatively and quantitatively I can say for sure that three out of four have been confirmed:

• the business got understanding, what we’re working on now and what to focus on next, can absolutely fill the queue with new tasks without waiting for the end of the sprint;
• The Kanban method increased the flexibility and predictability of the team’s work.
• The Kanban method proved to be more economical in terms of meetings.

Unfortunately, we have not eliminated the processing yet. But I associate this with two things:

• there was a previously accumulated pool of tasks in the system, which we are now diligently digesting.
• we still “push” tasks into the system instead of “pull”.

Where did I failed? I do not want the team to be divided into three teams, and the guys are clearly assigned to a separate direction. I see here the following problems and questions that scare me:

1. What to do when someone gets sick or goes on vacation? We have one test engineer and an analyst for the direction. We’ll have to somehow move people.
2. What to do when there are no tasks in the team? When is the load below the bandwidth?
3. Will there be a blockage in the direction? These are tasks not from our direction, we do not want to do this?
4. What to do, when in one of the directions it is necessary to accelerate sharply? We will still transfer people.
5. What to do with communications between teams? All for one meeting and divide? The guys are already talking about the division of the Kanban meeting, as they are not interested in knowing what is happening with the others. And on the general board to make a meeting on a weekly basis.

All this begins to resemble a scaled Scrum, and I do not understand what I did such that it became a natural need of the team? After all, the guys also talk about the division. It is also difficult for them to work with a large crowd. It’s all about the size? Or is it that I made a decision for them?

I understand that now the most correct decision will be to trust the team, as previously they trusted me. Therefore, of course, I will help them all what I can. How to avoid this fail next time?

The continue of the story.