Scrum. Programmer's Look
Hello everyone, for 15 years of working as a programmer, I had the opportunity to work in different teams, but I remember the work in one of them the most. Our team leader was a fan of the Scrum methodology and also a big fanatic. In this article I will tell you how the processes were organized in a team and what came of it.
Scrum is one of Agile’s agile methodologies and allows you to quickly respond to changing external requirements. In Scrum, the main concepts are iteration and sprint. The whole workflow is divided into time periods called iteration. The iteration includes planning, direct development (sprint) and testing. Iteration has hard time limits. Thus, Scrum is focused primarily on the timing of tasks.
Let's now look at exactly how Scrum was implemented inside our team. First, we will take a general look at the whole process, and then consider each stage in detail. Each iteration we had lasted one month. It began with planning and assessment of tasks, then there was a sprint during which daily five-minute minutes and other meetings were held as necessary. At the end of the development, there was a demonstration of new functionality and a retrospective.
It all started with the fact that the Product manager created a list of tasks based on the goals of the product and user feedback. Then from this list he selected the priority tasks and gave us for evaluation. This list was a little more than we could really do in a month in case a miracle happens. We complained a lot that the tasks were not spelled out to the smallest detail. But now, I can say for sure that in no other team have I seen such a high-quality design of tasks from PM.
Further, the team had to evaluate each task and evaluate what was included in the upcoming sprint. About assessment it is necessary to tell in more detail. At the first stages, they evaluated it like this: the team leader assigned each task to each developer and the developer gave an assessment. If the developer's assessment was very different from expectations, then they tried to understand the cause of the discrepancies and corrected either the assessment or the task. This took a lot of time from the team leader, and he always sought to make the system independent, which ultimately led to the use of Planning poker. Each developer evaluated all the tasks of the team for the upcoming sprint, and then the team leader calculated the average score for each task. The disadvantage of this approach was that developers of different levels gave an assessment, and if later a task fell on a beginner, then of course he did the task longer than this assessment. We tried to introduce coefficients for each developer, but this made things even more complicated. As a result, then, with the advent of the new incentive system, they completely abandoned the individual assessment of tasks, but more on that below.
After all the tasks were evaluated, all tasks were selected by priority, which fit into the length of the sprint and the development process began. After this moment, PM could not add anything new to the list until the end of the iteration.
The development process was the longest in the iteration. At this time, a five-minute period was held daily in the morning. We called it a stand up rally. Everyone stood in a circle and each told what he did yesterday and what he was going to do today.
The purpose of this meeting was to synchronize tasks between team members and identify problems that arose. In addition, there was also a psychological moment. If a person in the morning made a promise to the team to do something, then it was already more difficult for him not to keep this promise. The team members had a very different attitude towards this rally. There were so-called “soldiers” - people who understood the essence of the rally, came and soldierly reported the situation. There were also “rebels” - people who did not want to break away from the monitors and stand in a circle with everyone. But most took it calmly, as part of the job.
An interesting feature of our development was that our team leader was categorically against division into specialties. That is, the programmer had to be able to do any task or fix the bug after another programmer. This approach is quite controversial, and if you want, it can be discussed in the comments ...
As a task scheduler, we used the Target Process system. At first, we did not have a real board, only a list of tasks in this system. A board later appeared, but it was not a central part of the process and five-minute rallies were not built around it. Rather, it was just a visual representation of where the task is in the sprint segment.
Since the team leader had to somehow keep track of whether the programmer is in time within his task or not, we had practice reporting on the time spent on each task and, in addition, every day the programmer had to update the task’s estimate - how much time in his opinion was left to spend on this task.
Based on these data, management built burndown diagrams, according to which we could see whether we were doing well or not.
We conducted the code review in the special Code Collaborator program. When sending a code to a review, only one reviewer and any number of observers could be assigned. Only the reviewer decided whether to commit this code or not. Comments by observers were only advisory in nature. Interestingly, if a team member was not on the list of reviewers and reviewers, then he could not even see this code.
After all the tasks were completed and tested, the time came for a rally called “Demo”. At this rally, all the team members from designers to the technical documentation department gathered and watched the developers ’speeches.
Each developer on the big screen showed what he did for the current sprint. This was especially impressive for frontend developers, but backend developers also opened the console screen and showed a new cool API request.
The benefit of this rally is that during five minutes usually people tell that they are doing something, but then rarely someone from the team sees the result, since each is cooked in his own set of tasks. So, the demo is a good chance to find out what's new in the product. The demo raises the general morale and gives the feeling that our ship is sailing, and not standing still.
There is also a side effect. It often happened that during the demo incidents happened and something went wrong or new interesting cases of behavior were invented and therefore the testing team always left with a full notebook of bugs.
A retrospective is a rally that is held after the completion of an iteration in order to identify current problems and improve the process for the future. In our team, this rally was called Post mortem. Our team leader wanted this meeting to be held in the most relaxed atmosphere, so we bought beer and a snack, sat down at the table, celebrated the end of the iteration and at the same time discussed who liked what happened in the iteration and what did not like. The team was almost indifferent, so this feast was usually very hot and long. The product manager complained to the programmers that the tasks were not completed on time, the testers complained to the programmers that the tasks were submitted too late for testing and they did not have time to check them before the end of the iteration. And the programmers complained
At some point, we noticed that in each retrospective we were complaining about the same thing and decided to record all the moments. Then we realized that in every retrospect we record the same thing. Then we decided not just to record, but to assign a solution to each problem to a specific person, and he had to report on the next retrospective. Then we realized that while everyone will report, while they will write down new problems - there is no more time to drink and decided to separate the retrospective from the booze. After that, it was no longer so interesting and the retrospective turned into a dry uninteresting rally.
On my own behalf, I can note that, in addition to its basic meaning, retrospective carries a very important point - psychological relaxation. This is the time when a person can utterly with impunity express everything that he has accumulated over a month and continue to work quietly. Despite the obvious aggression during the rally, after its completion, the team became each time even more united.
We also had a rally “one and one”. Once every two weeks, the team leader talked with each member of the team, where he could say everything that cannot be said in retrospect.
There were also informal events outside the office. For example, twice a year we rode a team for barbecue.
In the life of any team there is an initial period when everyone is enthusiastic and work is in full swing, but if a team in the same team has been working for several years, then a period of decline in productivity will begin. And here the matter is not only that fatigue is accumulating, but also that the product is becoming more complicated and more time is being spent on its support and expansion.
When our team leader saw that the team had just such a moment, he decided to change the whole process and introduce additional stimulation. His main idea was that the concept of a programmer and a member of a team ceases to exist. The team becomes the minimum indivisible unit. At the end of each iteration, the team determines which set of tasks it takes on the next sprint. And performs these tasks. If the tasks are completed and tested two days before the end of the sprint, the team can use these remaining days at its discretion. Even if you don’t even go to work. Unfortunately, the team leader could not stimulate us financially, so the promotion was expressed in free time.
The diagram looked like this:
This shows that two days a month we did not do programming. The entire department gathered in the conference room. We took all the tasks that management provided us and tried to consider all the difficult points and give an assessment for each task.
I can say that the idea was a failure. We were able to earn these incentive two days only once. Estimates for the tasks were very high and a separate rally was created for each action with the participation of the entire team, as everyone was afraid not to be in time and lose the encouraging two days. Overstated estimates led to relaxation during the implementation of these tasks, and a bunch of rallies prevented focus on programming and as a result, the overall productivity of the department fell. At this point, the team already understood that it was necessary to take a step back and return to the previous system, but did not have time. The department was closed for reasons beyond the control of the team.
Despite the failure with the introduction of the incentive system before this experiment, the methodology described above for several years gave excellent results, the team showed high speed and the product developed very quickly. In conclusion, I would like to give some advice to beginner team leaders.
About the Scrum Methodology
Scrum is one of Agile’s agile methodologies and allows you to quickly respond to changing external requirements. In Scrum, the main concepts are iteration and sprint. The whole workflow is divided into time periods called iteration. The iteration includes planning, direct development (sprint) and testing. Iteration has hard time limits. Thus, Scrum is focused primarily on the timing of tasks.
About the process
Let's now look at exactly how Scrum was implemented inside our team. First, we will take a general look at the whole process, and then consider each stage in detail. Each iteration we had lasted one month. It began with planning and assessment of tasks, then there was a sprint during which daily five-minute minutes and other meetings were held as necessary. At the end of the development, there was a demonstration of new functionality and a retrospective.
Planning
It all started with the fact that the Product manager created a list of tasks based on the goals of the product and user feedback. Then from this list he selected the priority tasks and gave us for evaluation. This list was a little more than we could really do in a month in case a miracle happens. We complained a lot that the tasks were not spelled out to the smallest detail. But now, I can say for sure that in no other team have I seen such a high-quality design of tasks from PM.
Further, the team had to evaluate each task and evaluate what was included in the upcoming sprint. About assessment it is necessary to tell in more detail. At the first stages, they evaluated it like this: the team leader assigned each task to each developer and the developer gave an assessment. If the developer's assessment was very different from expectations, then they tried to understand the cause of the discrepancies and corrected either the assessment or the task. This took a lot of time from the team leader, and he always sought to make the system independent, which ultimately led to the use of Planning poker. Each developer evaluated all the tasks of the team for the upcoming sprint, and then the team leader calculated the average score for each task. The disadvantage of this approach was that developers of different levels gave an assessment, and if later a task fell on a beginner, then of course he did the task longer than this assessment. We tried to introduce coefficients for each developer, but this made things even more complicated. As a result, then, with the advent of the new incentive system, they completely abandoned the individual assessment of tasks, but more on that below.
After all the tasks were evaluated, all tasks were selected by priority, which fit into the length of the sprint and the development process began. After this moment, PM could not add anything new to the list until the end of the iteration.
Five minute
The development process was the longest in the iteration. At this time, a five-minute period was held daily in the morning. We called it a stand up rally. Everyone stood in a circle and each told what he did yesterday and what he was going to do today.
The purpose of this meeting was to synchronize tasks between team members and identify problems that arose. In addition, there was also a psychological moment. If a person in the morning made a promise to the team to do something, then it was already more difficult for him not to keep this promise. The team members had a very different attitude towards this rally. There were so-called “soldiers” - people who understood the essence of the rally, came and soldierly reported the situation. There were also “rebels” - people who did not want to break away from the monitors and stand in a circle with everyone. But most took it calmly, as part of the job.
Sprint
An interesting feature of our development was that our team leader was categorically against division into specialties. That is, the programmer had to be able to do any task or fix the bug after another programmer. This approach is quite controversial, and if you want, it can be discussed in the comments ...
As a task scheduler, we used the Target Process system. At first, we did not have a real board, only a list of tasks in this system. A board later appeared, but it was not a central part of the process and five-minute rallies were not built around it. Rather, it was just a visual representation of where the task is in the sprint segment.
Since the team leader had to somehow keep track of whether the programmer is in time within his task or not, we had practice reporting on the time spent on each task and, in addition, every day the programmer had to update the task’s estimate - how much time in his opinion was left to spend on this task.
Based on these data, management built burndown diagrams, according to which we could see whether we were doing well or not.
We conducted the code review in the special Code Collaborator program. When sending a code to a review, only one reviewer and any number of observers could be assigned. Only the reviewer decided whether to commit this code or not. Comments by observers were only advisory in nature. Interestingly, if a team member was not on the list of reviewers and reviewers, then he could not even see this code.
Demo
After all the tasks were completed and tested, the time came for a rally called “Demo”. At this rally, all the team members from designers to the technical documentation department gathered and watched the developers ’speeches.
Each developer on the big screen showed what he did for the current sprint. This was especially impressive for frontend developers, but backend developers also opened the console screen and showed a new cool API request.
The benefit of this rally is that during five minutes usually people tell that they are doing something, but then rarely someone from the team sees the result, since each is cooked in his own set of tasks. So, the demo is a good chance to find out what's new in the product. The demo raises the general morale and gives the feeling that our ship is sailing, and not standing still.
There is also a side effect. It often happened that during the demo incidents happened and something went wrong or new interesting cases of behavior were invented and therefore the testing team always left with a full notebook of bugs.
Retrospective
A retrospective is a rally that is held after the completion of an iteration in order to identify current problems and improve the process for the future. In our team, this rally was called Post mortem. Our team leader wanted this meeting to be held in the most relaxed atmosphere, so we bought beer and a snack, sat down at the table, celebrated the end of the iteration and at the same time discussed who liked what happened in the iteration and what did not like. The team was almost indifferent, so this feast was usually very hot and long. The product manager complained to the programmers that the tasks were not completed on time, the testers complained to the programmers that the tasks were submitted too late for testing and they did not have time to check them before the end of the iteration. And the programmers complained
At some point, we noticed that in each retrospective we were complaining about the same thing and decided to record all the moments. Then we realized that in every retrospect we record the same thing. Then we decided not just to record, but to assign a solution to each problem to a specific person, and he had to report on the next retrospective. Then we realized that while everyone will report, while they will write down new problems - there is no more time to drink and decided to separate the retrospective from the booze. After that, it was no longer so interesting and the retrospective turned into a dry uninteresting rally.
On my own behalf, I can note that, in addition to its basic meaning, retrospective carries a very important point - psychological relaxation. This is the time when a person can utterly with impunity express everything that he has accumulated over a month and continue to work quietly. Despite the obvious aggression during the rally, after its completion, the team became each time even more united.
Other events
We also had a rally “one and one”. Once every two weeks, the team leader talked with each member of the team, where he could say everything that cannot be said in retrospect.
There were also informal events outside the office. For example, twice a year we rode a team for barbecue.
Stimulation
In the life of any team there is an initial period when everyone is enthusiastic and work is in full swing, but if a team in the same team has been working for several years, then a period of decline in productivity will begin. And here the matter is not only that fatigue is accumulating, but also that the product is becoming more complicated and more time is being spent on its support and expansion.
When our team leader saw that the team had just such a moment, he decided to change the whole process and introduce additional stimulation. His main idea was that the concept of a programmer and a member of a team ceases to exist. The team becomes the minimum indivisible unit. At the end of each iteration, the team determines which set of tasks it takes on the next sprint. And performs these tasks. If the tasks are completed and tested two days before the end of the sprint, the team can use these remaining days at its discretion. Even if you don’t even go to work. Unfortunately, the team leader could not stimulate us financially, so the promotion was expressed in free time.
The diagram looked like this:
| 22 days | |||
| 10 days | 8 days | 2 days | 2 days |
| development | testing and bug fixing | assessment | recreation |
This shows that two days a month we did not do programming. The entire department gathered in the conference room. We took all the tasks that management provided us and tried to consider all the difficult points and give an assessment for each task.
I can say that the idea was a failure. We were able to earn these incentive two days only once. Estimates for the tasks were very high and a separate rally was created for each action with the participation of the entire team, as everyone was afraid not to be in time and lose the encouraging two days. Overstated estimates led to relaxation during the implementation of these tasks, and a bunch of rallies prevented focus on programming and as a result, the overall productivity of the department fell. At this point, the team already understood that it was necessary to take a step back and return to the previous system, but did not have time. The department was closed for reasons beyond the control of the team.
Conclusion
Despite the failure with the introduction of the incentive system before this experiment, the methodology described above for several years gave excellent results, the team showed high speed and the product developed very quickly. In conclusion, I would like to give some advice to beginner team leaders.
- Be sure to learn the different project management methodologies and don't be afraid to experiment.
- Enter daily five-minute rallies - you need them not only to understand the situation in the project, but also to the team members.
- Be sure to talk with subordinates. Become their second father. Let them have no secrets from you or the team. Retrospectives and one & one are great for this. And alcohol can help you with this a little.
- Enter “Demo”. The team must constantly see how the product develops.
- Do not enter too many rallies and restrictions. A complex process interferes with efficient operation.