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!

The post Kanban for the Delivery Service of 27. Reflection first appeared on Igor Filipyev Kanban School.

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.

The post Kanban for Team of 27. The story of one fail first appeared on Igor Filipyev Kanban School.

Guys, today I want to share the experience of finding a new job using the Kanban method.

Background: in November of last year, I left the walls of the Alfa-Bank with the desire to rest a little and accept a very interesting proposal. Unfortunately, at the final stage of the negotiations something went wrong, and I had to quickly change my plans and look for a new job.

To this end, I published a post on Facebook, where said that I was looking for a new job. Frankly, the result was quite unexpected for me number of proposals. There were so many of them that at some point I lost control of the situation. I couldn’t do:

1. Quickly and deliberately respond to all incoming messages.
2. Remember what I want.
3. Match the proposal to the desires.

As it usually happens, in a stressful situation, we often turn not to new tools and practices, but to familiar and proven habits. My response to stress was the use of the Kanban Method.

This story is about how to use this method practices as a project manager. Also, in my opinion, it will be useful to freelancers, working with a large flow of incoming orders and several customers.

The First visualisation

The first visualisation looked like this (Figure 1) and in my opinion was pretty standard.

I presented the stages through which the employer’s proposal passes:

1. Queue.
2. 1st contact / activation.
3. 2nd contact / personal meeting.
4. 3rd contact / Job offer (proposal).
5. Going to a new place, signing a contract.
6. I got a job, I work.

For myself, I immediately decided that at any stage it might happen that the proposal was withdrawn. I focused only on the most “sweet” options and without regret refused to be unsuitable.

A couple of days later I realised that this approach does not suit me, and erased the boundaries between the stages (Figure 2).

Here I used the visualization reception from KSD training from LKU trainer Aleksei Pimenov: I presented the abscissa (X) as a timeline with deadlines on the ninth of January and the ordinate (Y) in the form of a supply value. I expressed the value in the form of the numbers of the Fibonacci series, where 13 is an out-of-bound proposal that exactly meets all the fitness criteria of the goal.

Why did I erase the boundaries? After a couple of days of using the first version, I realised that the set of stages is too formal and has a low degree of flexibility. It was extremely difficult to follow them. As soon as I removed the borders and posted offers on qualitative characteristics (how much time I had left, and how much I was interested in the proposal), I immediately felt relieved.

Very soon, I combined all the stages into one – “Search” of my “company – In work”, and it went.

Another thing that helped me is ranking the value of incoming sentences to the left of the system (Figure 4).

Look. In the left corner of the photo the cards are already ranked by value. Here in my head for the first time the idea of Discovery Kanban.

The next photo shows the goal in the upper right corner. I wrote it down with a red marker and gave a rather detailed description of the fitness criteria. From that moment on, all visualisation turned into a kind of value stream from sentences that were supposed to lead me to the goal.

Offtopic:

In general, understanding that the Kanban method lives in the service paradigm can greatly advance you in mastering the method. In the Kanban method, you look at everything that surrounds you, as a service. No products, no projects, no departments – there are only services. Each serves a customer. Everyone has criteria, by which we understand that the level of service is optimal for the customer. In this example, I presented a job search project in the form of a service that helps me find a dream job. I was the customer of this service, and I had certain wishes for his work and for the result.

Think about it. What services surround you?

The Discovery Kanban

Let’s move on. I mentioned above about Discovery Kanban. Voila! The next improvement was just the division of visualisation into two stages (Figure 6) with the addition of this:

1. Discovery.
2. Delivery.

At some point, I realised that I want to respond to all new proposals at least twice, consciously and within 24 hours, and during this time for most of the proposals (90%) to decide whether it is suitable or not. For this, I highlight the “Study” stage, where I quickly plunged into the proposal, figured out the details and made a decision. The WIP-limit was floating (five to seven). The task of this stage was to weed out all unnecessary. Look at the next photo (Figure 7).

The second stage included proposals that had passed through a strict initial selection. If the interlocutor kept the silence for too long, the horizons were too vague and the proposal did not fit in the fitness criteria, it moved down. The chances that it would return to work were almost zero (this happened only once). I admit, sometimes it was very difficult to reject an interesting proposal. But I had no other choice. In any case, I wanted to come to the goal (just like Dodo Pizza with their billion :).

In the “Delivery” stage, the WIP-limit was fixed (five). Here I put a deadline in a couple of weeks to find a card in the work. If during this time the offer did not turn into a specific offer, the probability that it would be eliminated increased sharply.

Soon I stopped considering new incoming offers. Before the new year there was a couple of weeks and I wanted to rest. In the photo below (Figure 8) in the “Queue” is empty. I began to pinch the selected proposals and planned, in case of failure, from the new year to resume the search, launching a second iteration.

Outcomes

The result of the search was an offer from Home Credit Bank. There was a dramatic moment, but let this story remain in a narrow circle of initiates. I am grateful to HCFB for showing patience, the opportunity for self-realisation and I hope it was useful there

In the photo (Figure 9), the winner’s card is circled in a red circle. Job offer corresponded to the maximum number of fitness criteria for the goal.

In this project I used all the practices of the Kanban method:

1. Visualisation. To sort out the chaos of working with sentences and present it as a stream.
2. WIP-limits. To respond quickly and intelligently to incoming proposals.
3. Manage the flow. Changing the visualization and WIP-limits, I experimentally looked for the optimal balance between load and bandwidth.
4. Explicit policies. I have outlined the goal, fitness criteria, the rules for switching cards from stage to stage, ranking rules.
5. Feedback loops. Every morning I looked at the board and made a decision on what to work on today. Once in two or three days I looked at the whole stream and understood how to change its direction.
6. Evolutionary development. The latest version of the kanban board became the result of small changes in the original version, which I constantly adjusted to the goal.

As I wrote above, this example will be useful for project managers and freelancers alone. At this point in the post, it seems like it’s time to call them to use the Kanban method, but today I will refuse it.

The Kanban method is really very cool. Every day I use it in different projects and time after time I’m convinced of its survivability. However, today I would like to call you to another.

If you use the Kanban method and want more, look at the world through the prism of services. This is really very important. Once you do this, you will discover many new features in a seemingly familiar tool.

Good luck, friends!

The post How Kanban Can Help You To Find A New JoB first appeared on Igor Filipyev Kanban School.