Sync command with SCRUM
It seems to me that one of the biggest problems in the scram is a complete dissynchronization between people in a team. I have not yet managed to see a single stable solution to this problem. Of course, there are standard tools, but not always they give answers to all questions and close all holes.
I propose to come visit us and see how the Alfa-Bank online mortgage team is struggling with the problem of synchronization within itself.
The article was prepared by members of our team: Marina , Dima , Nastya , Veronika , Tolya .
Not so long ago (a little more than six months ago), Alfa-Bank launched a new project - “Online Mortgage”. The team for the project was going from scratch. People came to the project different and from different places of work. Everything was right on the guide: DevTeam (JS, Java, QA, Analyst), Scrum Master and Product Owner. None of the ninth has ever worked on a scram framework.
')
So, we all gathered, met and almost immediately got down to business. Ahead of us waited a lot of unobvious (at first glance) ideas. Most of them subsequently became mundane and logical. But what we couldn’t overcome for a long time was the imaginary clarity of the tasks. It often happens that you take a task in a sprint, but it turns out to be not as simple (and sometimes difficult) as it seemed at first glance.
Rassinhron for us was as follows:
The decision came somehow by itself. We took the standard tool and decided to try it out. DOR (Definition Of Ready) allows to reduce the degree of uncertainty in the task and coordinate the actions of the PO (Product Owner) and the ninth before starting work on the task. Using this approach, we can always more or less clearly define the degree of uncertainty that we encounter during development, and take it into account in the assessment of labor intensity.
The experience was extremely successful. We began to act more smoothly and more productively. On the grooming, we kept the DOR in front of our eyes and used it as a checklist for parsing the task. PO almost always found out in advance what the task was missing and tried to clarify the information as soon as possible. Otherwise, such a task simply did not fall into the next sprint.
We had to take spikes (studies) from the top tasks in the general backlog (backlog) in the sprint, but this brought a tremendous result. Uncertainty decreased, and we began to correctly assess the complexity of the problem.
It is worth noting that each team must have its own DOR. The fact is that it should not be a set of clear instructions from the employer. It is rather the command requirements for the minimum description of the task and the elaboration of the pitfalls that must be met for convenience and speed up work.
Very well, when the whole team understands what tasks we can put in the sprint, and which ones are not worth it. After the fulfillment of the DOR conditions, we encountered the following: we take the user story into work, but how can we understand that it is exactly ready?
Of course, we can look at all the sub tasks and assess the readiness of tasks on them. But what if we didn’t get a sub-task for documentation, testing or setting up accesses? Do you need to start such sub-tasks every time?
Oh well. Suppose we ideally start sub-taskki and ideally close them in time. Then it would be logical to close the task immediately after the merge into the master. But the task is not yet in battle! The user will not see the benefits of our work, and everything was in vain.
The first time we argued about the fact of the closed problem. After that, we adopted some not quite formal rules. This greatly simplified the work, but from time to time conflicts did arise. Then we come to the next standard sync step.
DOD (Definition Of Done) solves the problem of acceptance and a common understanding of the finished problem. DOD is very similar to DOR. This is the same set of criteria, but this time for the finished task. Looking at it, we can always say: the task is ready or not.
As a result, we have developed a common understanding of what needs to be done to consider the task closed. Only after all the items have been completed, the task goes to DONE.
Fine! Work has become much easier. We no longer waste time on unnecessary formalities about talking, which task is ready, and which is still to be finalized. On the other hand, we are no longer afraid to take tasks in the sprint. But what happens between these events? Discord, devastation and chaos.
The analyst is not always able to initially check all the tasks in the sprint. One of the developers can make changes (without the ability to roll back) that will affect another developer. In the end, PO is also human, and tasks can change during the sprint, even if it is not much appreciated in the scram.
In fact, there are a whole mass of cases that can lead to conflicts and unproductive work between the stages of taking work and completing a task (for short, DOR and DOD). In any team, you can almost always see the same problem. Someone poured something somewhere, and the second developer is now suffering. This provokes conflicts and negativity. And, of course, this problem almost always occurs when several developers are engaged in the same task.
At first, we tried to find something from an already existing one, like DOR and DOD. Unfortunately, we didn’t find anything similar and suitable to us (maybe we looked badly). Tried 1 work in progress, but the experience failed. Each task consists of disparate parts. Our experience has shown that with this approach, one of the developers always misses, and someone is forced to linger at work and finish his “half”. Not so long ago, we gathered and thought about another intermediate stage:
DOT (Definition Of Test) is a set of criteria for testing a task and assembling it into a single unit on a test bench. We also set the rules that the ninth cannot proceed with further actions (pull requests and so on) until the DOT is completely executed.
Let's look at the drawing and try to make out the idea in more detail. To begin with, imagine that we have only one developer for one task:
Immediately we note here a key feature. We have what needs to be done, and what should not be done before leaving the testing area. This can include the passage of the pull request, merge to the master, rollout and so on.
Immediately it is worth noting the difference from DOR and DOD. When we talk about DOR, we talk about what is needed to solve a problem. When talking about DOD, we say what task can be considered done. In DOT we are influenced by several types of circumstances. On the one hand, the development of the task must be completed. On the other hand, many actions to bring the task to a fully finished look are not worth doing.
The idea of ​​truly developing itself in the case of several developers with one task. Let's look at this case. In our example we will have front and back:
The scheme is very approximate. It is clear that we have one specialist can help (or interfere) with another. The need to refine the task may emerge earlier. A vykatkoy to fight another person can do. The main thing here is different. We have a certain area with clearly defined BEFORE and AFTER. Moreover, AFTER it cannot occur, until all the conditions of DOT are fulfilled. And only after that you can get OK from testing.
What else is important here? As can be seen from the picture, the development may begin at different times. The most important thing here is that several developers enter the testing area at different times, but they can only get out of it together. What they will be busy at this time - you can agree.
After the task is fully tested, all developers get the magic OK from testing, and now they start from one point. Interestingly, the probability of some shortcomings in synchronization is extremely low. The remaining actions take about the same time.
The need for DOT is the need for tight synchronization between developers. In one area includes several developers at different times, but always come out at a single point.
The disadvantage of this approach is additional time to think through the organization of tasks at the stage of formation. But in fact, such costs easily pay off. At the same time, tasks become more structured and predictable.
Of course, DOT is not a new world. This is just how we see synchronization in our team. It is still too early to say how good this practice is and what it will lead to. We understand that each company and even a team in a company has a different workflow and not everyone will do it. We believe in an iterative approach and improvement based on experience. Let's try; get the result; decide what to do next. However, it seems to me that this is an interesting experience. In the near future, we will certainly share with you the results of our experiment. Thanks for attention!
I propose to come visit us and see how the Alfa-Bank online mortgage team is struggling with the problem of synchronization within itself.
The article was prepared by members of our team: Marina , Dima , Nastya , Veronika , Tolya .
Not so long ago (a little more than six months ago), Alfa-Bank launched a new project - “Online Mortgage”. The team for the project was going from scratch. People came to the project different and from different places of work. Everything was right on the guide: DevTeam (JS, Java, QA, Analyst), Scrum Master and Product Owner. None of the ninth has ever worked on a scram framework.
')
First sync point: DOR
So, we all gathered, met and almost immediately got down to business. Ahead of us waited a lot of unobvious (at first glance) ideas. Most of them subsequently became mundane and logical. But what we couldn’t overcome for a long time was the imaginary clarity of the tasks. It often happens that you take a task in a sprint, but it turns out to be not as simple (and sometimes difficult) as it seemed at first glance.
Rassinhron for us was as follows:
- different worlds in which the business and the ninth live,
- different user story readiness for testing,
- different understanding of the completeness of the task.
The decision came somehow by itself. We took the standard tool and decided to try it out. DOR (Definition Of Ready) allows to reduce the degree of uncertainty in the task and coordinate the actions of the PO (Product Owner) and the ninth before starting work on the task. Using this approach, we can always more or less clearly define the degree of uncertainty that we encounter during development, and take it into account in the assessment of labor intensity.
The experience was extremely successful. We began to act more smoothly and more productively. On the grooming, we kept the DOR in front of our eyes and used it as a checklist for parsing the task. PO almost always found out in advance what the task was missing and tried to clarify the information as soon as possible. Otherwise, such a task simply did not fall into the next sprint.
We had to take spikes (studies) from the top tasks in the general backlog (backlog) in the sprint, but this brought a tremendous result. Uncertainty decreased, and we began to correctly assess the complexity of the problem.
It is worth noting that each team must have its own DOR. The fact is that it should not be a set of clear instructions from the employer. It is rather the command requirements for the minimum description of the task and the elaboration of the pitfalls that must be met for convenience and speed up work.
Our DOR
Criteria of readiness of a user story for taking into work
- A clear statement of “What?” - from PO (at least one week before the start of the sprint)
- The top-level description of the logic of the “How?” Task is from DevTeam (before the start of the sprint)
- Ready design (if needed): i.e. approved text and design.
- After the start of the sprint the task conditions do not change.
- The description of the minimum requirements in the jira analyst occurs before the developers start working (at the very beginning of the sprint)
- The task is uploaded and rated
The second synchronization point: DOD
Very well, when the whole team understands what tasks we can put in the sprint, and which ones are not worth it. After the fulfillment of the DOR conditions, we encountered the following: we take the user story into work, but how can we understand that it is exactly ready?
Of course, we can look at all the sub tasks and assess the readiness of tasks on them. But what if we didn’t get a sub-task for documentation, testing or setting up accesses? Do you need to start such sub-tasks every time?
Oh well. Suppose we ideally start sub-taskki and ideally close them in time. Then it would be logical to close the task immediately after the merge into the master. But the task is not yet in battle! The user will not see the benefits of our work, and everything was in vain.
The first time we argued about the fact of the closed problem. After that, we adopted some not quite formal rules. This greatly simplified the work, but from time to time conflicts did arise. Then we come to the next standard sync step.
DOD (Definition Of Done) solves the problem of acceptance and a common understanding of the finished problem. DOD is very similar to DOR. This is the same set of criteria, but this time for the finished task. Looking at it, we can always say: the task is ready or not.
Our DOD sketches
As a result, we have developed a common understanding of what needs to be done to consider the task closed. Only after all the items have been completed, the task goes to DONE.
Summing up the first two steps of synchronization
Fine! Work has become much easier. We no longer waste time on unnecessary formalities about talking, which task is ready, and which is still to be finalized. On the other hand, we are no longer afraid to take tasks in the sprint. But what happens between these events? Discord, devastation and chaos.
The analyst is not always able to initially check all the tasks in the sprint. One of the developers can make changes (without the ability to roll back) that will affect another developer. In the end, PO is also human, and tasks can change during the sprint, even if it is not much appreciated in the scram.
In fact, there are a whole mass of cases that can lead to conflicts and unproductive work between the stages of taking work and completing a task (for short, DOR and DOD). In any team, you can almost always see the same problem. Someone poured something somewhere, and the second developer is now suffering. This provokes conflicts and negativity. And, of course, this problem almost always occurs when several developers are engaged in the same task.
At first, we tried to find something from an already existing one, like DOR and DOD. Unfortunately, we didn’t find anything similar and suitable to us (maybe we looked badly). Tried 1 work in progress, but the experience failed. Each task consists of disparate parts. Our experience has shown that with this approach, one of the developers always misses, and someone is forced to linger at work and finish his “half”. Not so long ago, we gathered and thought about another intermediate stage:
The third sync point is our own idea: DOT
DOT (Definition Of Test) is a set of criteria for testing a task and assembling it into a single unit on a test bench. We also set the rules that the ninth cannot proceed with further actions (pull requests and so on) until the DOT is completely executed.
Let's look at the drawing and try to make out the idea in more detail. To begin with, imagine that we have only one developer for one task:
Immediately we note here a key feature. We have what needs to be done, and what should not be done before leaving the testing area. This can include the passage of the pull request, merge to the master, rollout and so on.
Immediately it is worth noting the difference from DOR and DOD. When we talk about DOR, we talk about what is needed to solve a problem. When talking about DOD, we say what task can be considered done. In DOT we are influenced by several types of circumstances. On the one hand, the development of the task must be completed. On the other hand, many actions to bring the task to a fully finished look are not worth doing.
The idea of ​​truly developing itself in the case of several developers with one task. Let's look at this case. In our example we will have front and back:
The scheme is very approximate. It is clear that we have one specialist can help (or interfere) with another. The need to refine the task may emerge earlier. A vykatkoy to fight another person can do. The main thing here is different. We have a certain area with clearly defined BEFORE and AFTER. Moreover, AFTER it cannot occur, until all the conditions of DOT are fulfilled. And only after that you can get OK from testing.
What else is important here? As can be seen from the picture, the development may begin at different times. The most important thing here is that several developers enter the testing area at different times, but they can only get out of it together. What they will be busy at this time - you can agree.
After the task is fully tested, all developers get the magic OK from testing, and now they start from one point. Interestingly, the probability of some shortcomings in synchronization is extremely low. The remaining actions take about the same time.
The need for DOT is the need for tight synchronization between developers. In one area includes several developers at different times, but always come out at a single point.
The disadvantage of this approach is additional time to think through the organization of tasks at the stage of formation. But in fact, such costs easily pay off. At the same time, tasks become more structured and predictable.
An example of the development process of our template
Conclusion
Of course, DOT is not a new world. This is just how we see synchronization in our team. It is still too early to say how good this practice is and what it will lead to. We understand that each company and even a team in a company has a different workflow and not everyone will do it. We believe in an iterative approach and improvement based on experience. Let's try; get the result; decide what to do next. However, it seems to me that this is an interesting experience. In the near future, we will certainly share with you the results of our experiment. Thanks for attention!
Source: https://habr.com/ru/post/358858/
All Articles