Seven Scrum Implementation Issues We Did Not Know About
Hello, Habr! My name is Maxim Lutzau, at Promsvyazbank I work as a product owner. For almost a year, the development of the new Internet bank “My Business” has been going on with the Scrum framework, and in this regard, I have already managed to fill up cones. In this post, I would like to talk about the most painful of them, as well as about what tools eventually helped us. So that you can avoid such troubles.
Scrum framework was adopted at 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 was necessary and what it would give.
“We used to work fine, why do we need this?”, “Why don't we do it differently?”, “Who came to teach me how he knows it’s better?” - such questions constantly rained 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 necessarily, since a person radiating a negative can influence everyone. In our history, this is precisely what our collective has healed - the general tension has disappeared, and everyone is tuned in to the perception of new information.
A 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 is working perfectly in our team - he did not have any problems with Scrum.
In any organization, you have to work with people who just don't 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 for us on Scrum so far.
We decided not to do anything with this problem - not to get into the work of other people with our scrum. We just ask them to do what we need. When they return with a solution, we begin to link their tasks. Do not complicate the interaction if the corporate culture has not yet matured by itself. Of course, after 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 cooperation with us they begin to work faster. We invite security guards to our meetings and demos, and now agreeing on a fully finished release takes only one day. Before that, it took from a week to two.
Having implemented Scrum, we switched from monthly reporting periods to two-week sprints. At first, due to the scale of the tasks, they did not want to compress the deadlines. But adjusting the sprint size to what needs to be done is a big mistake. On the contrary, you need to adjust the plans for the duration of the sprint. To do this is quite simple - just decompose the tasks. When they decrease in size, they are easier to arrange according to plan, to give them priority. Smaller batches of code are faster to test, verify, negotiate with security guards. In general, I would even recommend reducing the duration of the sprint from two weeks to one, if possible.
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 it fully armed. But in this case, you still need to adhere to the schedule. In any case, it is worth talking about the results of the work: what they did, what and why they did not, what they did in order to be in time. So we do not run away from problems, but come face to face with them and then we can find solutions together.
This approach increases motivation, after unsuccessful planned demos, responsibility for work grows. If before the developers prepared the stand for the demo in five minutes, now they do it the day before the demo, and then they polish the remaining bumps to make everything super.
At first, colleagues were skeptical about being distracted from their usual work at stand-up meetings every day. Even if they are held online and require only 10 minutes.
In solving this problem, symbolic encouragement from a person who finds a common language with the team helps. Once, for the sake of fun, I said that I would mark on the calendar those who come to stand-ups, and began to put pluses. The result was unexpected, and the effect was noticeable after one sprint. Not wanting to be bombarded, the developers themselves came to stand-ups. It even grew into our common joke: now they are threatening to put a minus to me when I can’t attend any meeting.
Many people think that scrum meetings take a lot of time. It is enough to calculate here whether this is actually so. We got two hours a week out of 40. This is not so much in order to organize work and stay up to date with all things.
If the whole team does not want to go to stand-up meetings, and the meetings themselves are not very active, this is a signal that the work is going wrong. As if the meeting is delayed for more than 15-20 minutes. A story about one’s activities and plans should not take more than one or two minutes.
One more rule is connected with 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 the task, that it is poorly decomposed and still requires time. This is worth paying attention to. We set a limit of 30 minutes for ourselves - each company needs to establish its own barrier.
The success of Scrum depends primarily on clear planning. It is necessary to determine how many tasks should be evaluated and described, and which can be simply postponed for now. Do not try to cover everything at once. The developer needs to understand what he will do in the next two sprints. For longer periods, a rough idea is enough - the later, the less details.
What are developers doing today? What will happen tomorrow? It happens that managers ask such questions regularly. We were able to explain to our management that all the points of interest can be found on our scrum board or by coming to the daily stand-up. No special reports with tables and monitoring on tasks in Jira. We managed to squeeze this micromanagement to weekly meetings with the management, where I report on the specific tasks performed by the team.
In the end, there is a clear problem, the mention of which I almost never found. No need to try to combine the scrum master and product owner. The latter builds a business unit, works out a backlog, and performs KPI. He is interested in the success of the product and tries to delve into everything - therefore, he starts making appointments, discussing some details. In general, it loads itself with a bunch of functions, because of which there is simply no time left for the backlog.
This happened to me. I organized meetings, stand-ups, solved the problems of team members. Because of this, the backlog was not worked out, that is, there simply was no time for the main activity. Now we have found a development manager who has authority over the team and also began to perform the functions of a scrum master, since he has more experience working on this framework. Now I was able to move away from Scrum and fully concentrate on the tasks of the product owner, who, in turn, should think about the requirements. Without good requirements, there will be no good product. As a result, the backlog began to improve, the colleagues came to understand how we will 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 we have begun to more or less clearly assess our abilities, have begun to increase the speed of development.
Some employees are fundamentally opposed to change
Scrum framework was adopted at 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 was necessary and what it would give.
“We used to work fine, why do we need this?”, “Why don't we do it differently?”, “Who came to teach me how he knows it’s better?” - such questions constantly rained 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 necessarily, since a person radiating a negative can influence everyone. In our history, this is precisely what our collective has healed - the general tension has disappeared, and everyone is tuned in to the perception of new information.
A 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 is working perfectly in our team - he did not have any problems with Scrum.
It's hard to interact with people who don't live by Scrum.
In any organization, you have to work with people who just don't 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 for us on Scrum so far.
We decided not to do anything with this problem - not to get into the work of other people with our scrum. We just ask them to do what we need. When they return with a solution, we begin to link their tasks. Do not complicate the interaction if the corporate culture has not yet matured by itself. Of course, after 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 cooperation with us they begin to work faster. We invite security guards to our meetings and demos, and now agreeing on a fully finished release takes only one day. Before that, it took from a week to two.
"We will not be in time for the sprint!"
Having implemented Scrum, we switched from monthly reporting periods to two-week sprints. At first, due to the scale of the tasks, they did not want to compress the deadlines. But adjusting the sprint size to what needs to be done is a big mistake. On the contrary, you need to adjust the plans for the duration of the sprint. To do this is quite simple - just decompose the tasks. When they decrease in size, they are easier to arrange according to plan, to give them priority. Smaller batches of code are faster to test, verify, negotiate with security guards. In general, I would even recommend reducing the duration of the sprint from two weeks to one, if possible.
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 it fully armed. But in this case, you still need to adhere to the schedule. In any case, it is worth talking about the results of the work: what they did, what and why they did not, what they did in order to be in time. So we do not run away from problems, but come face to face with them and then we can find solutions together.
This approach increases motivation, after unsuccessful planned demos, responsibility for work grows. If before the developers prepared the stand for the demo in five minutes, now they do it the day before the demo, and then they polish the remaining bumps to make everything super.
“Why do we need daily stand-ups?”
At first, colleagues were skeptical about being distracted from their usual work at stand-up meetings every day. Even if they are held online and require only 10 minutes.
In solving this problem, symbolic encouragement from a person who finds a common language with the team helps. Once, for the sake of fun, I said that I would mark on the calendar those who come to stand-ups, and began to put pluses. The result was unexpected, and the effect was noticeable after one sprint. Not wanting to be bombarded, the developers themselves came to stand-ups. It even grew into our common joke: now they are threatening to put a minus to me when I can’t attend any meeting.
Many people think that scrum meetings take a lot of time. It is enough to calculate here whether this is actually so. We got two hours a week out of 40. This is not so much in order to organize work and stay up to date with all things.
If the whole team does not want to go to stand-up meetings, and the meetings themselves are not very active, this is a signal that the work is going wrong. As if the meeting is delayed for more than 15-20 minutes. A story about one’s activities and plans should not take more than one or two minutes.
One more rule is connected with 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 the task, that it is poorly decomposed and still requires time. This is worth paying attention to. We set a limit of 30 minutes for ourselves - each company needs to establish its own barrier.
Incomprehensible backlog
The success of Scrum depends primarily on clear planning. It is necessary to determine how many tasks should be evaluated and described, and which can be simply postponed for now. Do not try to cover everything at once. The developer needs to understand what he will do in the next two sprints. For longer periods, a rough idea is enough - the later, the less details.
Inappropriate micromanagement
What are developers doing today? What will happen tomorrow? It happens that managers ask such questions regularly. We were able to explain to our management that all the points of interest can be found on our scrum board or by coming to the daily stand-up. No special reports with tables and monitoring on tasks in Jira. We managed to squeeze this micromanagement to weekly meetings with the management, where I report on the specific tasks performed by the team.
Something almost never written about
In the end, there is a clear problem, the mention of which I almost never found. No need to try to combine the scrum master and product owner. The latter builds a business unit, works out a backlog, and performs KPI. He is interested in the success of the product and tries to delve into everything - therefore, he starts making appointments, discussing some details. In general, it loads itself with a bunch of functions, because of which there is simply no time left for the backlog.
This happened to me. I organized meetings, stand-ups, solved the problems of team members. Because of this, the backlog was not worked out, that is, there simply was no time for the main activity. Now we have found a development manager who has authority over the team and also began to perform the functions of a scrum master, since he has more experience working on this framework. Now I was able to move away from Scrum and fully concentrate on the tasks of the product owner, who, in turn, should think about the requirements. Without good requirements, there will be no good product. As a result, the backlog began to improve, the colleagues came to understand how we will 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 we have begun to more or less clearly assess our abilities, have begun to increase the speed of development.