Scrum Programmer's Look
Hello everyone, for 15 years of work as a programmer, I happened to work in different teams, but I remember the work in one of them most of all. Our team leader was an admirer of the Scrum methodology and also a great entertainer. In this article I will tell you how the processes in the team were organized and what came of it.
Scrum is one of Agile's flexible methodologies and allows you to quickly respond to changing external demands. In Scrum, the basic concepts are iteration and sprint. The entire workflow is divided into time segments, which are called iteration. The iteration includes planning, direct development (sprint) and testing. Iteration has tight time limits. Thus, Scrum is focused primarily on the timing of tasks.
Let's now consider exactly how Scrum was implemented within our team. First, we take a look at the whole process, and then we will look at each stage in detail. Each iteration lasted one month. It began with the planning and evaluation of tasks, then there was a sprint, during which daily five-minute sessions and other meetings were held as needed. At the end of the development was a demonstration of the new functionality and retrospective.
It all started with the fact that the Product manager created a task list based on the goals of the product and user feedback. Then from this list, he chose priorities and gave us an assessment. This list was a little longer than we could actually have done in a month in case a miracle happens. We complained a lot about the fact that all the details were not spelled out in the tasks. But now, I can say for sure that in no other team have I ever seen such a high-quality design of tasks from PM.
')
Further, the team had to evaluate each task and estimated to understand what will enter the upcoming sprint. About the assessment need to tell more. At the first stages, they were evaluated as follows: the team leader assigned each task to each developer and the developer gave an assessment. If the developer's score was very different from the expectations, then they tried to understand the reason for the discrepancies and corrected either the estimate or the task. It took a lot of time from the team leader, and he always wanted to make the system independent, which resulted in 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 rating for each task. The disadvantage of this approach was that the assessment was given by developers at different levels, and if then the task fell into a novice, then of course he did the task longer than that assessment. We tried to introduce coefficients for each developer, but this complicated things even more. As a result, then, with the advent of the new incentive system, they generally abandoned the individual assessment of the tasks, but this will be slightly lower.
After all tasks were evaluated, all tasks were selected by priority, which fit into the sprint length and the development process began. After this point, nothing new PM could not be added to the list until the end of the iteration.
The development process was the longest in the iteration. At this time, every day was held in the morning five minutes. We called it stand up rally. Everyone got up in a circle and everyone told what he was doing yesterday and what he was going to do today.
The purpose of this rally was the synchronization of tasks between team members and the identification of problems encountered. In addition, there was a psychological moment. If a person in the morning made a promise before 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 to this rally. There were so-called “soldiers” - people who understood the essence of the rally, came and reported the situation in a soldier-like manner. There were “rebels” - people who did not want to break away from the monitors and stand in a circle with everyone. But the majority treated it calmly, as part of the work.
An interesting feature of our development was that our team leader was totally against the division into specialties. That is, the programmer had to be able to do any task or fix a bug after another programmer. This approach is quite controversial and if you want it can be discussed in the comments ...
We used the Target Process system as a task scheduler. At first, we didn’t have a real blackboard, just a list of tasks on this system. Later a blackboard appeared, but it was not the 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 on the sprint segment.
Since the team leader had to somehow track the programmer within his task or not, we had the practice of reporting time spent on each task and besides that, every day the programmer had to update the task assessment — how much time did he think was left to spend on this task.
On the basis of these data, management has built burndown diagrams, by which we could see whether we are doing well or not.
We reviewed the code in a special Code Collaborator program. When sending the code to the review, only one reviewer and any number of reviewers could be assigned. Only the reviewer can decide whether to commit this code or not. Reviewers comments were only advisory in nature. Interestingly, if a member of the team was not on the list of reviewers and reviewers, he could not even see this code.
After all the tasks were completed and tested, the time for the rally called “Demo” came. At this meeting, all team members gathered from designers to the technical documentation department and watched the speeches of the developers.
Each developer on the big screen showed what he did for the current sprint. It looked particularly impressive with frontend developers, but the backend developers opened a console on the screen and showed a new cool API request.
The benefit of this rally is that during the five-minute period, people usually say that they are doing something, but then rarely someone from the team sees the result, as each is brewed in his or her set of tasks. So, the demo is a good chance to find out what's new in the product. The demo raises the overall morale and gives the feeling that our ship is sailing, and not standing still.
And then there is a side effect. It often happened that during a demo incidents happened and something went wrong or new interesting case studies 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 the 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 rally to take place in the most relaxed atmosphere, so we bought beer and snacks, sat at the table, marked the end of the iteration and at the same time discussed who liked what in the last iteration and what did not like. There were almost no indifferent people in the team, so this feast usually was very hot and long. Product manager complained to programmers that tasks were not done on time, testers complained to programmers that it was too late to submit tasks to testing and they did not have time to check them before the end of the iteration. But programmers complained that the tasks did not come thought through and we have to spend a lot of time thinking through specific situations.
At some point we noticed that at each retrospective we complain about the same thing and decided to record all the moments. Then we realized that at each retrospective, we are recording the same thing. Then we decided not just to write down, but to assign a solution to each problem to a specific person and he had to report back at the next retrospective. Then we realized that for the time being everyone will report, until they have written down new problems - there is no time left for drinking and decided to separate the retrospective from drinking. After that, it was no longer so interesting, and the retrospective turned into a dry uninteresting rally.
From myself I can note that in addition to its basic meaning, a retrospective bears a very important point - psychological relaxation. This is the time when a person with complete impunity can say everything that he has accumulated over a month and continue to work quietly. Despite the obvious aggression during the rally, after it ended, the team became more cohesive each time.
We also had a “one and one” rally. Once every two weeks the team leader talked to each member of the team, where he could say all the things that cannot be said in retrospect.
There were also informal events outside the office. For example, twice a year we went to the team in a barbecue.
In the life of any team there is an initial period, when everyone is full of enthusiasm and the work is in full swing, but if a team with the same composition has been working for several years, then there will be a period of decline in productivity. And here it’s not only that fatigue accumulates, but also that the product becomes more complicated and more time is spent on its support and expansion.
When our team leader saw that the team had come just such a moment, he decided to change the whole process greatly and introduce additional incentives. His main idea was that the concept of a programmer and a member of a team ceased to exist. The team becomes the minimum indivisible unit. At the end of each iteration, the team determines which set of tasks it assumes for 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. Though not even going to work. Unfortunately, the timlider could not financially stimulate us, therefore encouragement was expressed in free time.
The scheme looked like this:
This shows that two days a month we did not do programming. The whole department was going to the conference room. We took all the tasks that the management gave us and tried to examine all the difficult moments and give an estimate for each task.
I can say that the idea was a failure. We were only able to earn these incentive two days once. Estimates for the tasks were given very high and for each action a separate meeting was created with the participation of the whole team, because all were afraid not to be in time and lose the incentive two days. Overestimations led to relaxation during the implementation of these tasks, and a bunch of meetings prevented us from concentrating on programming, and as a result, the overall productivity of the department fell. By this time, 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 command.
Despite the failure with the introduction of the incentive system before this experiment, the above methodology for several years gave excellent results, the team showed high speed and the product developed very quickly. As a conclusion, I would like to give some advice to novice team leaders.
About Scrum Methodology
Scrum is one of Agile's flexible methodologies and allows you to quickly respond to changing external demands. In Scrum, the basic concepts are iteration and sprint. The entire workflow is divided into time segments, which are called iteration. The iteration includes planning, direct development (sprint) and testing. Iteration has tight time limits. Thus, Scrum is focused primarily on the timing of tasks.
About the process
Let's now consider exactly how Scrum was implemented within our team. First, we take a look at the whole process, and then we will look at each stage in detail. Each iteration lasted one month. It began with the planning and evaluation of tasks, then there was a sprint, during which daily five-minute sessions and other meetings were held as needed. At the end of the development was a demonstration of the new functionality and retrospective.
Planning
It all started with the fact that the Product manager created a task list based on the goals of the product and user feedback. Then from this list, he chose priorities and gave us an assessment. This list was a little longer than we could actually have done in a month in case a miracle happens. We complained a lot about the fact that all the details were not spelled out in the tasks. But now, I can say for sure that in no other team have I ever seen such a high-quality design of tasks from PM.
')
Further, the team had to evaluate each task and estimated to understand what will enter the upcoming sprint. About the assessment need to tell more. At the first stages, they were evaluated as follows: the team leader assigned each task to each developer and the developer gave an assessment. If the developer's score was very different from the expectations, then they tried to understand the reason for the discrepancies and corrected either the estimate or the task. It took a lot of time from the team leader, and he always wanted to make the system independent, which resulted in 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 rating for each task. The disadvantage of this approach was that the assessment was given by developers at different levels, and if then the task fell into a novice, then of course he did the task longer than that assessment. We tried to introduce coefficients for each developer, but this complicated things even more. As a result, then, with the advent of the new incentive system, they generally abandoned the individual assessment of the tasks, but this will be slightly lower.
After all tasks were evaluated, all tasks were selected by priority, which fit into the sprint length and the development process began. After this point, nothing new PM could not be added to the list until the end of the iteration.
Five minutes
The development process was the longest in the iteration. At this time, every day was held in the morning five minutes. We called it stand up rally. Everyone got up in a circle and everyone told what he was doing yesterday and what he was going to do today.
The purpose of this rally was the synchronization of tasks between team members and the identification of problems encountered. In addition, there was a psychological moment. If a person in the morning made a promise before 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 to this rally. There were so-called “soldiers” - people who understood the essence of the rally, came and reported the situation in a soldier-like manner. There were “rebels” - people who did not want to break away from the monitors and stand in a circle with everyone. But the majority treated it calmly, as part of the work.
Sprint
An interesting feature of our development was that our team leader was totally against the division into specialties. That is, the programmer had to be able to do any task or fix a bug after another programmer. This approach is quite controversial and if you want it can be discussed in the comments ...
We used the Target Process system as a task scheduler. At first, we didn’t have a real blackboard, just a list of tasks on this system. Later a blackboard appeared, but it was not the 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 on the sprint segment.
Since the team leader had to somehow track the programmer within his task or not, we had the practice of reporting time spent on each task and besides that, every day the programmer had to update the task assessment — how much time did he think was left to spend on this task.
On the basis of these data, management has built burndown diagrams, by which we could see whether we are doing well or not.
We reviewed the code in a special Code Collaborator program. When sending the code to the review, only one reviewer and any number of reviewers could be assigned. Only the reviewer can decide whether to commit this code or not. Reviewers comments were only advisory in nature. Interestingly, if a member of the team was not on the list of reviewers and reviewers, he could not even see this code.
Demo
After all the tasks were completed and tested, the time for the rally called “Demo” came. At this meeting, all team members gathered from designers to the technical documentation department and watched the speeches of the developers.
Each developer on the big screen showed what he did for the current sprint. It looked particularly impressive with frontend developers, but the backend developers opened a console on the screen and showed a new cool API request.
The benefit of this rally is that during the five-minute period, people usually say that they are doing something, but then rarely someone from the team sees the result, as each is brewed in his or her set of tasks. So, the demo is a good chance to find out what's new in the product. The demo raises the overall morale and gives the feeling that our ship is sailing, and not standing still.
And then there is a side effect. It often happened that during a demo incidents happened and something went wrong or new interesting case studies 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 the 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 rally to take place in the most relaxed atmosphere, so we bought beer and snacks, sat at the table, marked the end of the iteration and at the same time discussed who liked what in the last iteration and what did not like. There were almost no indifferent people in the team, so this feast usually was very hot and long. Product manager complained to programmers that tasks were not done on time, testers complained to programmers that it was too late to submit tasks to testing and they did not have time to check them before the end of the iteration. But programmers complained that the tasks did not come thought through and we have to spend a lot of time thinking through specific situations.
At some point we noticed that at each retrospective we complain about the same thing and decided to record all the moments. Then we realized that at each retrospective, we are recording the same thing. Then we decided not just to write down, but to assign a solution to each problem to a specific person and he had to report back at the next retrospective. Then we realized that for the time being everyone will report, until they have written down new problems - there is no time left for drinking and decided to separate the retrospective from drinking. After that, it was no longer so interesting, and the retrospective turned into a dry uninteresting rally.
From myself I can note that in addition to its basic meaning, a retrospective bears a very important point - psychological relaxation. This is the time when a person with complete impunity can say everything that he has accumulated over a month and continue to work quietly. Despite the obvious aggression during the rally, after it ended, the team became more cohesive each time.
Other events
We also had a “one and one” rally. Once every two weeks the team leader talked to each member of the team, where he could say all the things that cannot be said in retrospect.
There were also informal events outside the office. For example, twice a year we went to the team in a barbecue.
Stimulation
In the life of any team there is an initial period, when everyone is full of enthusiasm and the work is in full swing, but if a team with the same composition has been working for several years, then there will be a period of decline in productivity. And here it’s not only that fatigue accumulates, but also that the product becomes more complicated and more time is spent on its support and expansion.
When our team leader saw that the team had come just such a moment, he decided to change the whole process greatly and introduce additional incentives. His main idea was that the concept of a programmer and a member of a team ceased to exist. The team becomes the minimum indivisible unit. At the end of each iteration, the team determines which set of tasks it assumes for 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. Though not even going to work. Unfortunately, the timlider could not financially stimulate us, therefore encouragement was expressed in free time.
The scheme looked like this:
| 22 days | |||
| 10 days | 8 days | 2 days | 2 days |
| development | testing and bugfixing | assessment | relaxation |
This shows that two days a month we did not do programming. The whole department was going to the conference room. We took all the tasks that the management gave us and tried to examine all the difficult moments and give an estimate for each task.
I can say that the idea was a failure. We were only able to earn these incentive two days once. Estimates for the tasks were given very high and for each action a separate meeting was created with the participation of the whole team, because all were afraid not to be in time and lose the incentive two days. Overestimations led to relaxation during the implementation of these tasks, and a bunch of meetings prevented us from concentrating on programming, and as a result, the overall productivity of the department fell. By this time, 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 command.
Conclusion
Despite the failure with the introduction of the incentive system before this experiment, the above methodology for several years gave excellent results, the team showed high speed and the product developed very quickly. As a conclusion, I would like to give some advice to novice team leaders.
- Be sure to learn different project management methodologies and don't be afraid to experiment.
- Enter the daily five-minute rallies - they are necessary not only for you to understand the situation in the project, but also for the team members.
- Be sure to talk to subordinates. Become for them the second father. May they have no secrets from you or from the team. Retrospectives and one & one are perfect for this. And alcohol can help you with that.
- Enter “Demo”. The team must constantly see how the product develops.
- Do not introduce too many rallies and restrictions. Complex process interferes with effective work.
Source: https://habr.com/ru/post/300662/
All Articles