history of service teams

Hello everyone! My name is Kirill Larkov, I am a Scrum Master at VTB Bank and I work with service teams. In this article, I would like to share my experience in forecasting tasks in service teams, who have never even dreamed of the word “forecasts” before. I chose storytelling as the format for this article, as such a step-by-step guide will be useful for beginning teams who are trying to cope with task forecasting on their own.

Also in this article, to shorten the content, I refer to the stages that are well known to Kanban practitioners: F4P (Fit for Purpose), Upstream Kanban. I advise you to briefly familiarize yourself with the material, as this knowledge will allow you to concentrate on the most important before solving the problems that we will encounter when forecasting tasks.

(Leaders): Dear colleagues, we are switching to a service model. Now we need to specify the exact timeframes when the service will be provided, so that clients understand when the work will be ready. So, your team provides service N, in what time frame can you complete it?

(Teams): Based on our experience, we can assume that we will do service N in 2 months (What kind of weird questions about deadlines are these? We worked quietly for 3 years. Now we are asked to set deadlines for all tasks. He must be joking).

(Leaders): Why such a long term? We work in sprints. At the end of each sprint there should be an increment that brings a certain value. Isn't part N a value? (Guys, don't tell me that you sometimes smoked bamboo instead of completing tasks).

(Teams): This is a moot point, depending on what you mean by the service performed. Our activity as a whole does not fit into Agile, and we cannot work in narrow sprints. We cannot reliably indicate the deadline (Because we do not know when it will leave?). The N that comes to us is actually: N1, N2, N3… That is, the tasks are always atypical and individual (We always have circumstances that delay our tasks. We cannot manage subcontractors!).

(Leaders): Show on the board what work you are doing (It seems that the guys periodically smoke bamboo).

*The leaders did not find any unnecessary information on the board. But they noticed that there was clearly not enough information on the tasks.*

(Leaders): Colleagues, what does “Connecting servers” mean? What does this work include? Why aren't our tasks decomposed? How do you even understand what you're doing? (We don't understand anything about what's going on on the boards? It seems like there were never any problems, and our colleagues worked properly.)

(Teams): Each team member is responsible for maintaining their own systems. If you were sitting next to them, you would understand more things. The team shares the ideology that everyone is responsible for themselves. If you have any questions about what is happening in these jobs, we can explain it to you in detail, but it will take us some time to explain it clearly enough. We don’t like this platform for managing tasks at all, we spend extra time on it (a little more and we will tell the leaders what we think about Agile if they don’t stop distracting us from work).

(Leaders): Colleagues, we suggest setting up a meeting to discuss this issue in more detail. We will invite the Scrum Master to help us sort out what we have. Our processes are clearly not adapted to Agile (Leave! Leave!).

Conclusion: The leaders saved their lives, and the teams think they won this discussion and defended their right not to plan work.

The leaders told the Scrum Master about their problem, and he scheduled meetings with each team member.

(SM): Good afternoon! Please share what tasks you perform?

(Team Member): Connecting servers. This is a very complex process that…

(SM): Why are you doing this? What is the purpose of your activity?

(Team member): This is necessary for… (Very complex questions that I have not thought about before. How to explain this information to an ordinary person?)

————————————–(The dialogue then continues via F4P)————————————–

(SM): Let's now move on to what your work on connecting servers consists of.

(Team member): Well, it all begins… (I'll tell you how it is. In all the details. Let the person understand how difficult my work is).

(SM): Can we divide this into stages of work?

(Team member): Well, let's try.

We managed to define the stages of completing the task. The only thing we agreed not to define was the task tossing between stages (the task could return back to the previous stage). We agreed to make intermediate zones when the task was in the zone of uncertainty.

After several days, the dialogue with the Scrum Master continued.

(Team member): Hey, I thought about the stages. Between the stages “Analysis” and “Work with the vendor” there is another stage – “Create a document”.

(SM): Sure, let's add it. Are there any changes to the other stages?

(Team member): No, I don't think so. The situation there is complicated in general…

(SM): Let's try to determine in which case we undertake to carry out tasks?

(Team Member): This happens when…

—————————————————Upstream Discussion———————————————-

(SM): Can we do this in the format of criteria or a checklist, according to which the task 100% gets into the “Analysis” stage?

(Team member): Well that's easy… These criteria are: x1, x2, x3. In other cases we don't work (Good question, I should probably write these criteria down because, in fact, I don't always follow them).

(SM): Let's make the same checklists for the other stages (So, we are forming DoD1, DoD2…).

After a long time and resolution of dysfunctions, we managed to set criteria for each stage. Now our task has become more controllable.

(Team Member): Look, we did such a big job. I still don't understand why. Explain why we drew this board?

(SM): This makes it easier to understand what processes are happening. Now we can control the task. Tell me, how many tasks do you have at each stage now?

(Team Member): 10 on “Analysis”, 20 on “Document Creation”, 5 on “Working with Vendor”, 10 on “Execution”, and 8 on “Testing”.

(SM): Tell me in more detail why there are so many tasks at each stage. And why are there more tasks at the “Document Creation” stage than at others?

(Team member): Yes, of course… Regarding the “Create document” stage, it's quite simple – vendor 1 rarely responds, so our tasks are not completed on time. But it's understandable, he is overloaded.

(SM): Are there any deadlines for working with vendor 1?

(Team member): We need to get the documents and read them. Yes, it seems like we have an SLA with him. We need to remind him about it and set up a meeting.

(SM): Do I understand correctly that at the “Working with the vendor” stage you also have your own SLA with vendor 2?

(Team member): Yes, we have our own SLA with vendor 2. But we need to discuss this with…

*After working through many issues and correcting visible dysfunctions, we got the following view of our board with a different average number of tasks that a team member worked on.*

(Team member): Listen, life has actually become easier. It's interesting. I was told that we build all these dialogues to discuss deadlines, and we resolve some problems (It's so good that now at least someone understands my work. Now I have a witness who will confirm that my work is not planned).

(SM): I am very glad to hear that. All our actions have led to the fact that now we can calculate the time it takes for tasks to complete at each stage.

(Team member): Why is this necessary?

(SM): Based on statistics, we can collect the necessary information that will allow us to determine your deadline for completing the task.

(Team member): Hmm… Let's try. They still require numbers from us, it will be good if we can collect them.

(SM): Just let's agree that we won't exceed the number of tasks you're currently working on. If one column, for example, “Execution” is full, then you won't take on new ones and will close the current ones. Is that a deal? Our main goal is to complete the tasks that are closest to completion first.

(Team member): It's coming! (A strange rule, as if something will change, but you can try).

We collected statistics for each stage during the month. The example shows the stage "Analysis". This type of distribution of time for solving problems in the Lead Time format seemed to be the most convenient. We saw that a similar picture with the distribution of tasks was observed at all stages. Thus, we established that each stage is controlled by time. — We collected statistics for each stage during the month. The example shows the “Analysis” stage. This type of distribution of time for solving tasks in the Lead Time format seemed the most convenient. We saw that a similar picture with the distribution of tasks is observed at all stages. Thus, we established that each stage is controlled by time.

(SM): Look, we have data that we've been collecting together for a month. Now we can determine that 95% of your work is completed within 4 days.

(Team member): Well, I think so.

(SM): For all the stages in total you got about 10 days with the same percentage of work.

(Team Member): Cool! So now I can set a 10 day SLA?

(SM): If there are no force majeure situations, then yes. This is one way to calculate your task.

Conclusion: In total, it took about 2 months with each team member to define the SLA for a situation like this. In this example, I skipped some steps that I had to go through with each member. Often, colleagues had to think about the processes they were working with for several days, and in some cases, everything had to be started over and the steps described again. It is worth noting that most of the time, the participants had to work with various kinds of blockers that were previously unnoticed and ignored, but thanks to the board, they became visible.

It is worth noting that most of the time the participants had to work with various types of blockers that had previously been unnoticed and/or ignored.

This article was greatly influenced by the following works:

How to predict task completion time

Actionable Agile Metrics for Predictability: An IntroductionDaniel S. Vaca