Seven Scrum Implementation Problems We Didn't Know About
Hi, Habr! My name is Maxim Lutzau, in Promsvyazbank I work as a product owner. For almost a year, we have been developing a new Internet bank, My Business, using the Scrum framework, and in this regard, I have already managed to fill the bumps. In this post, I would like to talk about the most painful of them, as well as what means we eventually helped. So that you can avoid such troubles.
The scrum framework was adopted in our bank in order to accelerate development and reduce TTM. When the implementation began, it turned out that some employees were not ready for this. They did not understand why this is necessary and what it will give.
“We used to work normally, why do we need this?”, “Why don’t we do otherwise?”, “Who came to teach me, how does he know that this is better?” - such questions constantly poured on their part. And even when these employees received answers, after a while everything was repeated again.
')
The most reasonable solution in this case is to transfer people to other projects. This must be done, because the person emitting the negative, is able to influence everyone. In our history, this is what healed our team - the general tension has disappeared, and everyone is tuned in to the perception of new information.
Negative reaction to changes does not depend on age. The developers we talked about above were a little over 30 years old. At the same time, a person who is already over 50 works well in our team - he had no problems with Scrum.
In any organization, you have to cooperate with people who simply do not work on Scrum. In our case, these are teams from other projects and departments. They usually have much longer stages of project implementation. Honestly, only RBS developers work on Scrum so far.
We decided not to do anything with this problem - not to get into the work of other people with our scram. We just ask them to do what we need. When they return with a solution, we begin to link their tasks. You should not complicate the interaction if the corporate culture has not yet matured by itself. Of course, after the scrum trainings, there is a desire to change absolutely everything, but it is better to stop in time.
Although we do not rush other units, in collaboration with us, they begin to work faster. We invite security guards to our meetings and demo, and now it only takes one day to agree on a fully finished release. Before that, it took about a week to two.
Having implemented Scrum, we switched from monthly reporting periods to two-week sprints. At first, because of the scale of the tasks, they did not want to compress the dates. But adjusting the size of the sprint for what needs to be done is a big mistake. On the contrary, you need to customize the plans for the duration of the sprint. It is quite simple to make it - it is enough to decompose the tasks. When they are reduced in size, they are easier to arrange according to the plan, give them priority. Smaller batches of code are faster to test, check, and coordinate with security guards. In general, I would even recommend, if possible, reduce the duration of the sprint from two weeks to one.
When someone from the team does not have time to do everything planned by the end of the sprint, there is a natural desire to postpone the demo - to come to him fully armed. But in this case, you must still stick to the schedule. In any case, it is worth telling about the results of the work: what they did, what they didn’t do, and why they didn’t, what they did to make it. So we do not run away from problems, but come face to face with them and then we can jointly find solutions.
This approach increases motivation, after unsuccessful planned demos, responsibility for work grows. If earlier the developers prepared the stand for the demo in five minutes, now they do it a day before the demo, and then they polish the remaining irregularities so that everything is super.
At first, colleagues were skeptical about distracting themselves from the usual work at the stand-up meeting every day. Even if they are held online and require only 10 minutes.
To solve this problem, symbolic encouragement from a person who finds a common language with the team helps. Once for fun, I said that I would mark those who come to stand-ups in the calendar and began to put pluses. The result was unexpected, and the effect was noticeable after just one sprint. Not wanting to be mined, the developers themselves came to stand-ups. It even turned into our common joke: now they are already threatening to give me a minus when I cannot come to any meeting.
Many people think that scrum meetings take a lot of time. Here it is enough to calculate whether this is true. We got two hours a week out of 40. This is not so much to organize the work and stay up to date with all the cases.
If the whole team does not want to go to a stand-up meeting, and the meetings themselves are not very active, this is a signal that the work is going wrong. As if the meeting is delayed by more than 15-20 minutes. The story about his classes and plans for a person should not take more than one or two minutes.
We have another rule related to time management. If the discussion of the task takes more than 30 minutes, we stop it. This means that we did not have time to develop a task, that it is poorly decomposed and requires more time. It is worth paying attention to. We set a limit of 30 minutes for ourselves - we need to install our own barrier in each company.
The success of Scrum depends, first of all, on clear planning. It is necessary to determine how many tasks should be evaluated and described, and which so far can simply be postponed. Do not try to cover everything at once. The developer needs to understand what he will do in the next two sprints. For more distant terms, a rough idea is sufficient - the later, the less detail.
What are the developers doing today? And what will happen tomorrow? Sometimes managers ask such questions regularly. We were able to explain to our management that all points of interest can be found on our board or by coming to the daily stand-up. No special reports with tables and monitoring for tasks in Jira. We managed to squeeze this micromanagement to weekly meetings with management, where I report on specific team tasks.
Finally - a clear problem, the mention of which I almost never found. No need to try to combine the scram master and the product owner. The latter is building a business unit, is working backlog, performs KPI. He is interested in the success of the product and tries to penetrate into everything - that is why he starts to make appointments, discuss some details. In general, it loads itself with a bunch of functions, because of which there is simply no time left for backlog.
It happened to me. I organized meetings, stand-ups, solved the problems of team members. Because of this, backlog was not worked out, that is, there was simply no time for the main activity. Now we have found a development manager who has credibility with the team and also began to perform the functions of a scrum master, since he has more experience with this framework. Now I was able to move away from Scrum and fully concentrate on the tasks of the product owner, who, in turn, must think about the requirements. Without good requirements there will be no good product. As a result, backlog began to improve, an understanding came to colleagues as we move on.
At first glance, Scrum seems very simple, but still has many pitfalls. We have been working on this framework for almost a year, but only now have we begun to more or less clearly assess our abilities, have begun to increase the speed of development.
Some employees are fundamentally against change.
The scrum framework was adopted in our bank in order to accelerate development and reduce TTM. When the implementation began, it turned out that some employees were not ready for this. They did not understand why this is necessary and what it will give.
“We used to work normally, why do we need this?”, “Why don’t we do otherwise?”, “Who came to teach me, how does he know that this is better?” - such questions constantly poured on their part. And even when these employees received answers, after a while everything was repeated again.
')
The most reasonable solution in this case is to transfer people to other projects. This must be done, because the person emitting the negative, is able to influence everyone. In our history, this is what healed our team - the general tension has disappeared, and everyone is tuned in to the perception of new information.
Negative reaction to changes does not depend on age. The developers we talked about above were a little over 30 years old. At the same time, a person who is already over 50 works well in our team - he had no problems with Scrum.
Difficult to interact with those who do not live on Scrum
In any organization, you have to cooperate with people who simply do not work on Scrum. In our case, these are teams from other projects and departments. They usually have much longer stages of project implementation. Honestly, only RBS developers work on Scrum so far.
We decided not to do anything with this problem - not to get into the work of other people with our scram. We just ask them to do what we need. When they return with a solution, we begin to link their tasks. You should not complicate the interaction if the corporate culture has not yet matured by itself. Of course, after the scrum trainings, there is a desire to change absolutely everything, but it is better to stop in time.
Although we do not rush other units, in collaboration with us, they begin to work faster. We invite security guards to our meetings and demo, and now it only takes one day to agree on a fully finished release. Before that, it took about a week to two.
"We do not have time for the sprint!"
Having implemented Scrum, we switched from monthly reporting periods to two-week sprints. At first, because of the scale of the tasks, they did not want to compress the dates. But adjusting the size of the sprint for what needs to be done is a big mistake. On the contrary, you need to customize the plans for the duration of the sprint. It is quite simple to make it - it is enough to decompose the tasks. When they are reduced in size, they are easier to arrange according to the plan, give them priority. Smaller batches of code are faster to test, check, and coordinate with security guards. In general, I would even recommend, if possible, reduce the duration of the sprint from two weeks to one.
When someone from the team does not have time to do everything planned by the end of the sprint, there is a natural desire to postpone the demo - to come to him fully armed. But in this case, you must still stick to the schedule. In any case, it is worth telling about the results of the work: what they did, what they didn’t do, and why they didn’t, what they did to make it. So we do not run away from problems, but come face to face with them and then we can jointly find solutions.
This approach increases motivation, after unsuccessful planned demos, responsibility for work grows. If earlier the developers prepared the stand for the demo in five minutes, now they do it a day before the demo, and then they polish the remaining irregularities so that everything is super.
“Why do we need daily stand-ups?”
At first, colleagues were skeptical about distracting themselves from the usual work at the stand-up meeting every day. Even if they are held online and require only 10 minutes.
To solve this problem, symbolic encouragement from a person who finds a common language with the team helps. Once for fun, I said that I would mark those who come to stand-ups in the calendar and began to put pluses. The result was unexpected, and the effect was noticeable after just one sprint. Not wanting to be mined, the developers themselves came to stand-ups. It even turned into our common joke: now they are already threatening to give me a minus when I cannot come to any meeting.
Many people think that scrum meetings take a lot of time. Here it is enough to calculate whether this is true. We got two hours a week out of 40. This is not so much to organize the work and stay up to date with all the cases.
If the whole team does not want to go to a stand-up meeting, and the meetings themselves are not very active, this is a signal that the work is going wrong. As if the meeting is delayed by more than 15-20 minutes. The story about his classes and plans for a person should not take more than one or two minutes.
We have another rule related to time management. If the discussion of the task takes more than 30 minutes, we stop it. This means that we did not have time to develop a task, that it is poorly decomposed and requires more time. It is worth paying attention to. We set a limit of 30 minutes for ourselves - we need to install our own barrier in each company.
Incomprehensible backlog
The success of Scrum depends, first of all, on clear planning. It is necessary to determine how many tasks should be evaluated and described, and which so far can simply be postponed. Do not try to cover everything at once. The developer needs to understand what he will do in the next two sprints. For more distant terms, a rough idea is sufficient - the later, the less detail.
Inappropriate micromanagement
What are the developers doing today? And what will happen tomorrow? Sometimes managers ask such questions regularly. We were able to explain to our management that all points of interest can be found on our board or by coming to the daily stand-up. No special reports with tables and monitoring for tasks in Jira. We managed to squeeze this micromanagement to weekly meetings with management, where I report on specific team tasks.
What almost do not write
Finally - a clear problem, the mention of which I almost never found. No need to try to combine the scram master and the product owner. The latter is building a business unit, is working backlog, performs KPI. He is interested in the success of the product and tries to penetrate into everything - that is why he starts to make appointments, discuss some details. In general, it loads itself with a bunch of functions, because of which there is simply no time left for backlog.
It happened to me. I organized meetings, stand-ups, solved the problems of team members. Because of this, backlog was not worked out, that is, there was simply no time for the main activity. Now we have found a development manager who has credibility with the team and also began to perform the functions of a scrum master, since he has more experience with this framework. Now I was able to move away from Scrum and fully concentrate on the tasks of the product owner, who, in turn, must think about the requirements. Without good requirements there will be no good product. As a result, backlog began to improve, an understanding came to colleagues as we move on.
At first glance, Scrum seems very simple, but still has many pitfalls. We have been working on this framework for almost a year, but only now have we begun to more or less clearly assess our abilities, have begun to increase the speed of development.
Source: https://habr.com/ru/post/420265/
All Articles