Little about the retrospective
For the development team, it is important to regularly conduct a retrospective in order to constantly improve. But what should it be?
For several years we used only some of the standard practices on our retro. In others, they did not see the point, because the positive result was: processes improved, problems were solved. Everything was good. Not really:
We considered the first and second problems a given, what to do with the third did not understand, but I did not even know about the last.
')
Last spring, I went to Okademy from ScrumTrek. This is an extensive course that includes many useful things for the scrum master, but for me the most useful part was how to conduct retrospectives more effectively. I want to tell you how it helped us.
Initially, we did not have formal rules. We simply met, expressed problems and discussed in a free form, until we came to a solution. Therefore, retrospectives took so much time.
After listening to Okademy all sorts of different things about retrospectives, the first thing I suggested to the team was to work out retro rules that would reduce the time for not useless disputes. Most of the rules were proposed not by me, but by other members of the team. Among the proposed rules were both standard and those that I would not have thought of:
For each of the proposed rules, we voted with our thumb:
For each of the proposed rules, we voted with our thumb:
Thanks to this set of rules, we reduced the retro time to an hour, although the number of problems discussed and decisions made has not changed. Moreover, the rule of the raised hand, we began to use outside of retro.
After some time, the development teams reshaped and in the new team there were three people who did not participate in the discussion of these rules. For everyone to accept the rules, we have re-arranged the same discussion. As much as the old team members did not like the rules worked out jointly, not all of them were accepted by the new participants. The extended rule of the raised hand had to be dropped, and the standard rule was no longer applied - it simply did not need the new team.
Before you conduct retrospectives, agree with the team about the rules. It is important that the team itself invented and adopted these rules (although the Scrum Master himself may offer some rules). If you just come up with ready-made rules, the “not invented here” effect will arise - the team will not take these rules to heart. Any new team member must accept the rules. If he doesn't accept any of them, discuss these rules again. If the team is changing a lot, discuss the rules from scratch.
Retrospective can be divided into the following stages:
Each stage can be carried out in different ways: there are game activities, there are serious ones. Determine which ones are best for your team. Some people, without question, agree to any retro format. Some important to understand why we need each of the activities. It is better to explain the purpose of each stage and activity in case you have people of the second type.
To increase team engagement, it is useful to periodically change activities. With this help cards retrospectives .
More information about the different activities for each of the stages, you can see here .
This stage is needed to engage the team in the work. For mature teams, it is usually omitted - everything gets drawn into discussions without any problems. Since we have a lot of experience with retro, there wasn’t much benefit from the discovery. But if you see that some people do not take part in discussions, perhaps you just lack opening.
At the stage of data collection it is necessary to find out what the team hurts.
Previously, we always used Glad, Sad, Mad activity for this: each participant writes on stickers that he was pleased, upset or angered over the last sprint. This activity is good in that it includes emotions (as opposed to simple division into positive and negative) and therefore fulfills also the role of discovery: it involves everyone in the work. Also, such activities are forced to recall not only the problems, but also all the positive moments that occurred during the sprint. It is important to consolidate effective practices. In addition, the fact that some evaluate positively, others may evaluate negatively. It is important to discuss such differences in assessment.
Additionally, during the sprint, we collected problems on a special batthurt board. It helps not to forget about them by the time of retro. It also gives people who are not members of the team the opportunity to share their pain (to discuss such stickers, you need to call on the authors' retro). But in the end, we have accumulated a large number of problems that we did not have time to disassemble.
This is where ranking comes to the rescue. Do not discuss all the problems that people can remember. Rank them in order of importance and discuss only the highest priority. Pre-consolidate similar problems into clusters. Dot voting is well suited for ranking:
Problems for which no one voted, you can not discuss. Do not even need to transfer them to the next retro. If this is an important problem, then it will be remembered as it is. If you do not remember, it means that you should not spend time on it.
After selecting important problems for each of them, you need to generate solutions. If there are several mutually exclusive solutions to one problem, then it is necessary to choose the most appropriate of them. It will also help dot voting.
It is important that all decisions made are SMART:
A few years ago, when we were just starting to conduct retrospectives, some agile coaches offered to divide solutions into two boards:
I don’t know if there are teams for which Decisions Board works, but in my practice this approach always ended like this:
And this despite the fact that we tried to reduce most of the decisions to SMART.
It is impossible to remember such a pile of small decisions. Even remembering what each of these cards means is not possible for everyone. Check whether the benefits of these decisions can not be. We can say that if you hang a card on the Decisions Board as a result of the discussion, then the time for discussion is wasted.
Developing a SMART solution for any problem discussed is difficult. We still do not always succeed. Nevertheless, I can offer a few ideas for improvement in this regard:
For example, recently we drew empty squares on a Kanban board to remind ourselves to pre-pull stories.
In a month, let us estimate whether it helped. If it does not help, we will write a bot that will scold us if we are unaware of the ticket.
Closing is also necessary in order to assess how well retro has gone and how it can be improved.
Previously, we did not close. At the same time, I was sure that our team was pleased with our standard retro format and would negatively perceive any gaming activities. If we hadn’t started closing, I wouldn’t have learned that some members of the team were bored and they are not averse to trying any new activities. Since we started closing, I have received useful feedback on almost every retro.
Feedback on the retrospective is necessary to the scrum master not only to improve, but also not to burn out. Remember that you are not iron, and at least sometimes you need praise for your hard work.
For several years we used only some of the standard practices on our retro. In others, they did not see the point, because the positive result was: processes improved, problems were solved. Everything was good. Not really:
- spent on retro for 2 hours and very exhausting
- discussions periodically went into protracted useless disputes
- some minor problems did not have time to solve and constantly transferred to the next retro
- individual team members were bored with retrospectives due to the monotony
We considered the first and second problems a given, what to do with the third did not understand, but I did not even know about the last.
')
Last spring, I went to Okademy from ScrumTrek. This is an extensive course that includes many useful things for the scrum master, but for me the most useful part was how to conduct retrospectives more effectively. I want to tell you how it helped us.
Decide on the rules
Initially, we did not have formal rules. We simply met, expressed problems and discussed in a free form, until we came to a solution. Therefore, retrospectives took so much time.
After listening to Okademy all sorts of different things about retrospectives, the first thing I suggested to the team was to work out retro rules that would reduce the time for not useless disputes. Most of the rules were proposed not by me, but by other members of the team. Among the proposed rules were both standard and those that I would not have thought of:
- The time limit for retro hour.
- Each retro activity is also limited in time.
- The raised hand rule (standard): if you want to interrupt and say something, raise your hand.
- The raised hand rule (extended): if several people raised their hand when you speak, then you have gone from the topic and must stop.
- We denote the problem: during any discussion, it is necessary to clearly identify the problem in order not to deviate from it.
- Use parking lot: if an important question unrelated to the current topic pops up during the discussion, write it onto a sticker and glue it on a special place (parking lot) to discuss later.
- Outside - out the door: if someone called or someone came on an urgent matter, you just have to go out so as not to disturb the rest of the team.
For each of the proposed rules, we voted with our thumb:
For each of the proposed rules, we voted with our thumb:
- All show thumb:
- up - for,
- down - against
- horizontally - anyway.
- If there are votes for and there are no votes against - the rule is adopted.
- If there are no votes for - the rule is not accepted.
- If there are votes both for and against - we discuss, until we come to a consensus.
Thanks to this set of rules, we reduced the retro time to an hour, although the number of problems discussed and decisions made has not changed. Moreover, the rule of the raised hand, we began to use outside of retro.
After some time, the development teams reshaped and in the new team there were three people who did not participate in the discussion of these rules. For everyone to accept the rules, we have re-arranged the same discussion. As much as the old team members did not like the rules worked out jointly, not all of them were accepted by the new participants. The extended rule of the raised hand had to be dropped, and the standard rule was no longer applied - it simply did not need the new team.
Before you conduct retrospectives, agree with the team about the rules. It is important that the team itself invented and adopted these rules (although the Scrum Master himself may offer some rules). If you just come up with ready-made rules, the “not invented here” effect will arise - the team will not take these rules to heart. Any new team member must accept the rules. If he doesn't accept any of them, discuss these rules again. If the team is changing a lot, discuss the rules from scratch.
Retrospective structure
Retrospective can be divided into the following stages:
- Opening
- Data collection
- Generation of ideas
- Decision making
- Closing
Each stage can be carried out in different ways: there are game activities, there are serious ones. Determine which ones are best for your team. Some people, without question, agree to any retro format. Some important to understand why we need each of the activities. It is better to explain the purpose of each stage and activity in case you have people of the second type.
To increase team engagement, it is useful to periodically change activities. With this help cards retrospectives .
More information about the different activities for each of the stages, you can see here .
Opening
This stage is needed to engage the team in the work. For mature teams, it is usually omitted - everything gets drawn into discussions without any problems. Since we have a lot of experience with retro, there wasn’t much benefit from the discovery. But if you see that some people do not take part in discussions, perhaps you just lack opening.
Data collection and ranking problems
At the stage of data collection it is necessary to find out what the team hurts.
Previously, we always used Glad, Sad, Mad activity for this: each participant writes on stickers that he was pleased, upset or angered over the last sprint. This activity is good in that it includes emotions (as opposed to simple division into positive and negative) and therefore fulfills also the role of discovery: it involves everyone in the work. Also, such activities are forced to recall not only the problems, but also all the positive moments that occurred during the sprint. It is important to consolidate effective practices. In addition, the fact that some evaluate positively, others may evaluate negatively. It is important to discuss such differences in assessment.
Additionally, during the sprint, we collected problems on a special batthurt board. It helps not to forget about them by the time of retro. It also gives people who are not members of the team the opportunity to share their pain (to discuss such stickers, you need to call on the authors' retro). But in the end, we have accumulated a large number of problems that we did not have time to disassemble.
This is where ranking comes to the rescue. Do not discuss all the problems that people can remember. Rank them in order of importance and discuss only the highest priority. Pre-consolidate similar problems into clusters. Dot voting is well suited for ranking:
- Each participant can put n points (usually 2-3) next to the cluster, with important problems for him
- You can put all the points in one cluster or distribute them between different
- The more points placed next to the cluster, the higher its priority
Problems for which no one voted, you can not discuss. Do not even need to transfer them to the next retro. If this is an important problem, then it will be remembered as it is. If you do not remember, it means that you should not spend time on it.
Idea generation and decision making
After selecting important problems for each of them, you need to generate solutions. If there are several mutually exclusive solutions to one problem, then it is necessary to choose the most appropriate of them. It will also help dot voting.
It is important that all decisions made are SMART:
- S - Specific - accurate and specific
- M - Measurable - measurable (it should be possible to answer the question whether the decision helped or not)
- A - Achievable - attainable
- R - Relevant - relevant (in the heat of discussion, do not forget what problem you are solving)
- T - Time bound / framed - with a limited implementation period (it is desirable that they can be completed before the next retro)
A few years ago, when we were just starting to conduct retrospectives, some agile coaches offered to divide solutions into two boards:
- Actions Board - SMART Solutions
- Decisions Board - solutions that do not have a time limit (all possible rules and changes in the process)
I don’t know if there are teams for which Decisions Board works, but in my practice this approach always ended like this:
And this despite the fact that we tried to reduce most of the decisions to SMART.
It is impossible to remember such a pile of small decisions. Even remembering what each of these cards means is not possible for everyone. Check whether the benefits of these decisions can not be. We can say that if you hang a card on the Decisions Board as a result of the discussion, then the time for discussion is wasted.
Developing a SMART solution for any problem discussed is difficult. We still do not always succeed. Nevertheless, I can offer a few ideas for improvement in this regard:
- Leave yourself only two options - either come to a SMART-solution, or you do not have a solution for the problem. As long as you leave yourself the opportunity to make a non-SMART decision, you will take them. If you are using the Decisions board, discard it. Totally. Half-measures do not work here.
- Be sure to figure out how to check whether your decision has benefited. If you can't come up with a quantitative metric, at least ask people if it’s better.
- If the decision is a change in your processes, then within the SMART solution you need to fix a new rule so that it is difficult to forget:
- change your physical board with tickets so that it fixes this rule
- enter it into the bugtracking system
- or write a bot that will remind you when you deviate from the new process.
For example, recently we drew empty squares on a Kanban board to remind ourselves to pre-pull stories.
In a month, let us estimate whether it helped. If it does not help, we will write a bot that will scold us if we are unaware of the ticket.
Closing
Closing is also necessary in order to assess how well retro has gone and how it can be improved.
Previously, we did not close. At the same time, I was sure that our team was pleased with our standard retro format and would negatively perceive any gaming activities. If we hadn’t started closing, I wouldn’t have learned that some members of the team were bored and they are not averse to trying any new activities. Since we started closing, I have received useful feedback on almost every retro.
Feedback on the retrospective is necessary to the scrum master not only to improve, but also not to burn out. Remember that you are not iron, and at least sometimes you need praise for your hard work.
Source: https://habr.com/ru/post/347780/
All Articles