January 25, 2013 at 14:43Scrum - real experience in methodology
In this article I give an overview of the organization of the software creation process in the team in which I work. My goal is to share the experience of developing and managing a development team.
To organize the process of work on the project, we decided to choose the popular Scrum methodology. Partly this is a tribute to fashion, partly a large number of publications on the Internet on the theme "Scrum did everything for us!"
Where does software development usually start? From the idea: “How wonderful it would be if I had some kind of software that would do something like this. It would be just super! ” The person who will represent this idea on the team is called Product Owner (PO) or Product Owner. A Product Owner is one who sees the goal of the product or who thinks he sees the goal of the product, but what matters is that he can formulate it and begin the process of moving towards achieving it. He forms the goal in the form of a list of his wishes (Wishlist). This list is called Product Backlog Items (PBI). It is constantly being modified depending on the market situation or on the growing appetite of Product Owner.
Command. According to Scrum, it is believed that the greatest development efficiency is achieved if the team itself will decide on how it will move towards the goal. Therefore, the main requirement for the team - it must be self-organizing and self-governing. Provide this requirement alone, and this will be enough for the success of the project. Since the requirement is serious, the role of ScrumMaster is introduced into the team, which ensures that the rules of Scrum are respected.
ProductOwner formulated his goal as a certain point B, which you need to achieve by starting from point A. But point B is not a point that you can reach by simply drawing a straight line between it and point A. Actually, point B is a neighborhood points, and its radius can vary.
To get into this neighborhood, it is best to develop software in short steps (more precisely, in races): sprints. At the end of the sprint, everyone evaluates what happens and adjusts the direction of movement. ProductOwner is always aware that his ideas are correctly understood (and if not, this can be corrected already at the next sprint), and is calm. The team knows what they are doing and is satisfied with their work.
The team sprint lasts 2 weeks. For a week, nothing is done, for a month everything is forgotten. Therefore, 2 weeks is the best option for us. The first day of the sprint is planning. In the early stages, planning took even 2 days. Planning is a process in which a team takes the highest priority from a list of requirements and breaks it down into tasks that allow achieving a result. Each task is rated in hours. It is advisable that the task does not take more than 4 hours. If a team member says that he will do the task in 5 days, then he has no idea what needs to be done.
The total number of hours in the sprint for each person is calculated from the fact that the sprint lasts 2 weeks or 10 working days. This is 80 hours minus one day for planning. Total 72 hours. But this is a perfect watch. This means that a person is not distracted by anything, does not eat, does not drink, does not get up from his place, but only works and does not get tired. During planning, tasks are evaluated in ideal hours. But it’s not 72 hours, but 72 hours multiplied for a person, multiplied by a certain coefficient called team productivity. This is usually 0.5. Surprisingly, this is some kind of magic number, it was with him that the entire sprint surrenders successfully. Someone from the great said: "Take the time that the developer called you, multiply it by two and add a little more and get the time period for which the programmer will give you the result." And indeed it is.
Scrum has several recommendations on how the performer estimates the time for a task. For example, play poker. But we do not sin. Whatever they say, but if someone started to do some module, then he will continue to build it from sprint to sprint. And only he can estimate how much time he needs to complete the task. The only ones who can prevent him from overstating are his conscience (remember about self-organization) and ScrumMaster.
There is a list of requirements. But how to check whether this requirement was achieved during development or not? To do this, you need to write tests that will describe in detail what to consider achievement of the requirement. Simply put, they describe which button to press, and what happens. Analysts write tests in the team. And these tests should be ready by the time the next sprint is launched. Our team of analysts and designers are working ahead of the development team by 1 sprint.
The main requirement is that tests should be very detailed.
The sprint execution process begins. Its main goal is to ensure that the requirements for the requirements are completed by the end of the sprint.
For a united movement of the team towards the goal, Scrum offers to make daily rallies. A rally is when everyone, standing at the blackboard with a marker, crosses out what he did yesterday and writes what he is going to do today.
This is a very powerful practice. Thanks to her, everyone knows where the project as a whole is going. Moreover, when a person tells what he will do today, he automatically coordinates his actions with other participants. Other participants can immediately offer the best solutions to the problem. And the task written on the board, but in fact it is a promise to all his colleagues, motivates the artist himself very well. The only thing ScrumMaster should not forget to announce that the rally has begun.
Rallies should be held preferably while standing and lasting no more than 15 minutes. We start rallies at 9 in the morning.
The long-awaited end of the sprint comes, usually this is Friday at 4:00 p.m., and the team passes the sprint to Product Owner and everyone else who is interested in the product. Each reports on the tasks that he performed and talks about what successes he achieved, and also explains the reasons why he failed to achieve the goal. The main rule is never to postpone the sprint.
Sometimes after passing the sprint, an analysis is made of why something is happening or not happening, and what needs to be done to correct the situation.
And on Monday everything repeats all over again.
We have developed several rules for ourselves, non-compliance with which led to the failure of the sprint:
• Sprint must be planned in detail, not sparing it. If one of the requirements is not clear, then the requirement needs to be clarified. If this cannot be done, then it is not necessary to take the task into the sprint, but send the requirement for revision.
• Under no circumstances to take additional tasks that go outside the sprint. And if you still "imposed", then agree with Product Owner'om that other tasks will be removed from the sprint.
• The number of people in the team should not exceed 5-6 people. When our team grew to 16 people, the rally began to drag out for 2 hours. We entered a fixed performance time for everyone and stood with a stopwatch. But then the man did not have time to convey his thought, and the rally turned into a formality. Therefore, we just split up. At first they were divided into clients and nuclear experts, and then they began to share according to tasks. Those. each team makes its own feature, and in this subcommand there are both clients and nuclear specialists. This approach is still used, and for us it is most effective.
Scrum can be a good starting point to start moving. In the process, some rules may evolve or disappear as unnecessary. This will be decided by the team, team relationships and life itself. But the rules that will be formed on the basis of Scrum will serve as a good springboard for the team to achieve the desired result.
The team I work for is called Uniclaud Labs. This is a friendly team of interesting people, really rooting for their job.
Varikov Andrey VAndrey
Technical Director of Uniclaud Labs LLC
If you are interested in what we do - Welcome
To organize the process of work on the project, we decided to choose the popular Scrum methodology. Partly this is a tribute to fashion, partly a large number of publications on the Internet on the theme "Scrum did everything for us!"
What roles are there in Scrum
Where does software development usually start? From the idea: “How wonderful it would be if I had some kind of software that would do something like this. It would be just super! ” The person who will represent this idea on the team is called Product Owner (PO) or Product Owner. A Product Owner is one who sees the goal of the product or who thinks he sees the goal of the product, but what matters is that he can formulate it and begin the process of moving towards achieving it. He forms the goal in the form of a list of his wishes (Wishlist). This list is called Product Backlog Items (PBI). It is constantly being modified depending on the market situation or on the growing appetite of Product Owner.
Command. According to Scrum, it is believed that the greatest development efficiency is achieved if the team itself will decide on how it will move towards the goal. Therefore, the main requirement for the team - it must be self-organizing and self-governing. Provide this requirement alone, and this will be enough for the success of the project. Since the requirement is serious, the role of ScrumMaster is introduced into the team, which ensures that the rules of Scrum are respected.
What is sprint and why is it needed
ProductOwner formulated his goal as a certain point B, which you need to achieve by starting from point A. But point B is not a point that you can reach by simply drawing a straight line between it and point A. Actually, point B is a neighborhood points, and its radius can vary.
To get into this neighborhood, it is best to develop software in short steps (more precisely, in races): sprints. At the end of the sprint, everyone evaluates what happens and adjusts the direction of movement. ProductOwner is always aware that his ideas are correctly understood (and if not, this can be corrected already at the next sprint), and is calm. The team knows what they are doing and is satisfied with their work.
How is the sprint task list formed
The team sprint lasts 2 weeks. For a week, nothing is done, for a month everything is forgotten. Therefore, 2 weeks is the best option for us. The first day of the sprint is planning. In the early stages, planning took even 2 days. Planning is a process in which a team takes the highest priority from a list of requirements and breaks it down into tasks that allow achieving a result. Each task is rated in hours. It is advisable that the task does not take more than 4 hours. If a team member says that he will do the task in 5 days, then he has no idea what needs to be done.
The total number of hours in the sprint for each person is calculated from the fact that the sprint lasts 2 weeks or 10 working days. This is 80 hours minus one day for planning. Total 72 hours. But this is a perfect watch. This means that a person is not distracted by anything, does not eat, does not drink, does not get up from his place, but only works and does not get tired. During planning, tasks are evaluated in ideal hours. But it’s not 72 hours, but 72 hours multiplied for a person, multiplied by a certain coefficient called team productivity. This is usually 0.5. Surprisingly, this is some kind of magic number, it was with him that the entire sprint surrenders successfully. Someone from the great said: "Take the time that the developer called you, multiply it by two and add a little more and get the time period for which the programmer will give you the result." And indeed it is.
Scrum has several recommendations on how the performer estimates the time for a task. For example, play poker. But we do not sin. Whatever they say, but if someone started to do some module, then he will continue to build it from sprint to sprint. And only he can estimate how much time he needs to complete the task. The only ones who can prevent him from overstating are his conscience (remember about self-organization) and ScrumMaster.
How to verify that ProductOwner’s requirement is met
There is a list of requirements. But how to check whether this requirement was achieved during development or not? To do this, you need to write tests that will describe in detail what to consider achievement of the requirement. Simply put, they describe which button to press, and what happens. Analysts write tests in the team. And these tests should be ready by the time the next sprint is launched. Our team of analysts and designers are working ahead of the development team by 1 sprint.
The main requirement is that tests should be very detailed.
What happens during the sprint
The sprint execution process begins. Its main goal is to ensure that the requirements for the requirements are completed by the end of the sprint.
For a united movement of the team towards the goal, Scrum offers to make daily rallies. A rally is when everyone, standing at the blackboard with a marker, crosses out what he did yesterday and writes what he is going to do today.
This is a very powerful practice. Thanks to her, everyone knows where the project as a whole is going. Moreover, when a person tells what he will do today, he automatically coordinates his actions with other participants. Other participants can immediately offer the best solutions to the problem. And the task written on the board, but in fact it is a promise to all his colleagues, motivates the artist himself very well. The only thing ScrumMaster should not forget to announce that the rally has begun.
Rallies should be held preferably while standing and lasting no more than 15 minutes. We start rallies at 9 in the morning.
What happens at the end of the sprint
The long-awaited end of the sprint comes, usually this is Friday at 4:00 p.m., and the team passes the sprint to Product Owner and everyone else who is interested in the product. Each reports on the tasks that he performed and talks about what successes he achieved, and also explains the reasons why he failed to achieve the goal. The main rule is never to postpone the sprint.
Sometimes after passing the sprint, an analysis is made of why something is happening or not happening, and what needs to be done to correct the situation.
And on Monday everything repeats all over again.
Accumulated experience
We have developed several rules for ourselves, non-compliance with which led to the failure of the sprint:
• Sprint must be planned in detail, not sparing it. If one of the requirements is not clear, then the requirement needs to be clarified. If this cannot be done, then it is not necessary to take the task into the sprint, but send the requirement for revision.
• Under no circumstances to take additional tasks that go outside the sprint. And if you still "imposed", then agree with Product Owner'om that other tasks will be removed from the sprint.
• The number of people in the team should not exceed 5-6 people. When our team grew to 16 people, the rally began to drag out for 2 hours. We entered a fixed performance time for everyone and stood with a stopwatch. But then the man did not have time to convey his thought, and the rally turned into a formality. Therefore, we just split up. At first they were divided into clients and nuclear experts, and then they began to share according to tasks. Those. each team makes its own feature, and in this subcommand there are both clients and nuclear specialists. This approach is still used, and for us it is most effective.
Conclusion
Scrum can be a good starting point to start moving. In the process, some rules may evolve or disappear as unnecessary. This will be decided by the team, team relationships and life itself. But the rules that will be formed on the basis of Scrum will serve as a good springboard for the team to achieve the desired result.
Who are we?
The team I work for is called Uniclaud Labs. This is a friendly team of interesting people, really rooting for their job.
Varikov Andrey VAndrey
Technical Director of Uniclaud Labs LLC
If you are interested in what we do - Welcome