Geekly Articles each Day
📜 ⬆️ ⬇️

Managing Retrospective or Looking Into the Past: Gov.uk Handbook

Analysis of the team’s work and how it was done




The basic principle of agile development is fast feedback cycles: you demonstrate something to users as quickly as possible, and thus see how much the changes meet their needs. A review of what was done to correct the deficiencies discovered is a method that we apply to our own teams to find out what works and what does not, so that the team can constantly improve.

Retrospective


A retrospective is a meeting at the end of the sprint, at which your team has the opportunity to express what went well and what went wrong, and take any measures to improve the situation. This event may cover a longer period of time - for example, you can hold a meeting on the results of the entire project.
')
The retrospective consists of the following steps:

  1. collection of information;
  2. generation of insights;
  3. deciding what to do next.

This is an opportunity for every member of your team to participate in process improvement / productivity improvement.

Lead (Facilitator)

Retrospective - a meeting that you need to lead. The role of the presenter is to give everyone a chance to express their point of view on what is happening and give a positive response.



At the same time, the presenters are responsible for ensuring that the meeting remains structured, productive, and the mood during the discussion does not become too negative. Ideally, if someone not from your team is leading, she will be able to participate in the meeting in full, but this is irrelevant.

The facilitator must:


Working arrangements

Retrospective involves some working arrangements. If necessary, they can be fixed, for example, during the first retrospective of your team.

The essence of the working arrangements is that:


Retrospective results

During the discussion, you will be able to discuss both your successes and problems that you can eliminate, as well as what you can improve.



For each of these questions make a list of actions. Strive to perform these actions no later than the next sprint or iteration. To solve some problems, you need more time: in this case, try to take at least some actions to eliminate them by the next retrospective.

Actions must:


The retrospective should be accompanied by a discussion of what was done following the results of the previous meeting. If the tasks are not performed regularly, they will accumulate too much.

Template


You can use the template for a retrospective. This template is suitable for a team of 8-10 people working within a 2-week sprint.

The suitable meeting duration for such a number of participants and the amount of work is 90 minutes. Each of the actions continues for a set time, to monitor this - the work of your lead.

Allocate about 10% of the time to switch from one action to another and keep the time limit under control.

Preparation: 00:00 to 00:05 (5 minutes)

Explain the scope of the tasks, and if necessary, the purpose of the meeting. If team members are not familiar with each other, and / or are embarrassed, briefly introduce them.

Work done on the results of the previous retrospective: from 00:05 to 00:10 (5 minutes)

Make sure it is complete. If not, ask:


Achievements: from 00:10 to 00:20 (10 minutes)

Give your team about 10 minutes to write down all the good things that have been done in the previous 2 weeks on sticky sheets.

If, in order to express thoughts more freely, team members need anonymity, first collect leaflets from everyone, and then self-paste them onto the wall. Otherwise, let the team members attach themselves to the wall of the record, and, if possible, say a few words about each project participant.

Do not allow discussions to develop at this stage - now you are simply collecting information.

Discussion: 00:20 to 00:30 (10 minutes)

Group stickers on common topics. If there are too many topics to discuss everything at once, ask the team to select the most priority ones, for example, by voting.

Discuss each of the selected topics in the following areas:


Dips: 00:30 to 00:45 (15 minutes)

Give the team 15 minutes to write everything that went wrong.

Discussion: 00:45 to 01:05 (20 minutes)

Group the stickers again, prioritize them, if necessary, and discuss the main areas:




Actions: from 01:05 to 01:20 (15 minutes)

Spend some time evaluating the proposed actions; assign tasks to those present and provide realistic deadlines for completing them.

Total: 80 minutes + 10% on switching between tasks.

It is good to finish the meeting a little earlier than the specified time, if everyone has time to speak out during this time. It’s bad when the deadlines are exceeded - if the team needs too much time to discuss all the topics, ask them to prioritize the questions and discuss the most important ones, and / or next time take more time for the retrospective.

Why is it necessary


Regular retrospectives mean that you can:


Agile development methods will help you work better, and retrospectives will help you better tailor the process and working conditions to your needs.

Additional reading


These resources may be useful to you:


We discussed this material with a number of startups of the 4th and 5th Accelerator sets of the IIDF and Accelerator employees:

Glory to Arkharov, Accelerator FRIA tracker:

During a retrospective session there will always be a farce, and it is almost impossible to pack it up. Therefore, one should not think that if you rigidly set aside 5 minutes for a retrospective session and 5 minutes for feedback, the team will tell about their problems in 5 minutes, and then the listeners will take turns to express their opinion without interrupting. It will not be so.

Everyone will chat, bicker, insert their opinions in the middle of a phrase, etc. precisely because people are born ideas at the moment when another person speaks - and not according to a schedule. But if you forbid people to express thoughts at once, then they will stop thinking in principle, they will stop expressing ideas and start agreeing on everything - and the retrospective session will lose effectiveness and meaning.

The principle of combating this is: you should always have a short list of final questions that need to be answered as a result of the discussion of retrospectives. For example, "how do we improve sales next week?" And the presenter should give a lot to many, not necessarily on schedule and strictly on the topic - but he should constantly return everyone to this issue and at the end of the session formulate a common answer to it by joint efforts.

We must prepare very well for retrospective sessions. The data, materials, conclusions should be correct - and they should be checked with experts before the start of a retrospective discussion. Otherwise, the work on the retrospective will turn into a job of finding errors in the presentation, and this will also reduce its effectiveness.

It is always necessary to record retrospective arrangements with the previous sprint and consider them and their results at the next retrospective sessions. For example: “Last week you agreed that you would make five calls to a customer a day, and you make two. Why? ”Otherwise, people will not develop a serious attitude towards this tool - because many of them are inclined not to do what they agreed on and to work in the old way. Therefore, it is necessary for them to constantly show that the goal of a retrospective session is an improvement, and not just a discussion of how bad things are.

1. Do you use a methodology for discussing the work done in retrospective format or is it a waste of time?

Konstantin Maslennikov, CEO of the project takebus.ru
There are questions (for example, the development of particularly important functions on the site or in the application), which we discuss in the format of a retrospective. We analyze what we wanted to achieve and what we came to. We use this when we meet with our mentor, and during the preparation of the reporting letters to the stakeholders. But we use this approach in relation to a limited range of issues, not more than 3 (often 1) - since the analysis of all the hypotheses in retrospect takes an awfully long time.

Andrey Valiev, Founder and CTO of the Moymehanik.rf project
Yes, we hold meetings in retrospective format. In essence, these are our daily meetings in the core of the team and weekly “extended meetings” with the participation of those involved in the project less intensively. The core of the team is a small well-coordinated team of 3 people who can afford to follow the regulations less formally. We discuss what was done in a day / week, draw conclusions about what was good / bad, formulate a plan for the week / next day. There is no dedicated facilitator, this role is simply played by one of the team members.

Andrei Shevelev, founder of the project Turbazar.rf
Yes, we do a rally every week, we analyze the metrics based on the results, we plan the following actions.

Georgy Kozhin, co-founder and art director of the project Kartadoma.ru
We try to use agile in our work. We realized that the weekly iteration is optimal for us, following which we conduct a retrospective. In the weekly sprint we put both programmer tasks and product ones.

Anatoly Sharifulin, CEO of the project AppFollow.ru
Despite the fact that our team is small (3 people), there is still a desynchronization, and without retrospectives, we would quickly come to chaos. Every week we are discussing who did what in a week, what results, if we failed deadlines or did not cope with the task, then why. It is very important to understand the failures and scheduling errors in order to prevent them further.

2. If you use this approach: how long does the discussion traditionally take? Do you keep timing of such meetings? Maybe you have your own techniques and "chips" in organizing retrospectives?

Konstantin Maslennikov, CEO of the project takebus.ru
There is no hard timing retrospective, but there is a timing of meeting with a mentor, most of which is retrospective. We use the "starting deck" where the sheets are painted all our original desires for the product in different cuts (even there are pictures), we spent a couple of days writing it out, and sometimes with a smile, sometimes we take seriously what we have written there, it is surprising that Some of the features that we invented there (for example, analytics for carriers) looked easy - but we didn’t realize this until now, and some seemed fantastic to us (for example, registering through social networks), and we’ve already implemented them.

Andrey Valiev, Founder and CTO of the Moymehanik.rf project
This is probably not "chips", but there are some rules that we try to follow: a conversation not on a given topic - at the end of the discussion, if there is time; the result of the meeting should sound like a list of tasks to be performed (what / who / when); Do not take on what you can not manage to do. It is better to do what I did not promise, in addition to what I promised.

Andrei Shevelev, founder of the project Turbazar.rf
Each member of our team has the right to express and defend their opinion on any issue. It is accepted in the team to form a unanimous opinion on the decisions made, but the last word always remains for the CEO.

Georgy Kozhin, co-founder and art director of the project Kartadoma.ru
Previously, we had 6 programmers and retrospectives were especially useful, but sometimes they took half a day, which is very wasteful. After such a long retrospective, the team has already "talked", the overall tone falls, and the discussion is no longer so active.

Then the number of programmers decreased, and the retrospectives took less and less time and boiled down to a brief discussion of some of the problems that the team had to face during the sprint. Such discussions took 15-20 minutes. In the same product sprints, retrospective has not lost its relevance. It helps to increase efficiency and allows you to "run faster."

Summarizing, if you have several programmers in a team, you shouldn’t make a half-day discussion, it’s better to just fix the problems in the process and move on. If you have a large team, retrospectives are required. The main thing in retrospect is not to go into discussions of new features and not to engage in planning, and things that have been agreed upon at the end of retrospectives, to observe and implement in subsequent sprints.

Anatoly Sharifulin, CEO of the project AppFollow.ru
Usually, each is given 5-10 minutes. There is no hard timing, now we don’t need it. From experience, I can say that in large teams there is no hard timing. If the rally takes more than an hour, then this file is also antiproductive.

I can not say that this is my own "trick", but every day and / or every 2-4 hours I clarify the status of the progress of work on the tasks. It takes 1-2 minutes, but allows you to quickly respond to the "departure" and adjust the progress of tasks. Fortunately, we work in uncertainty and cannot afford to explore this uncertainty for too long. It is necessary to move quickly, make mistakes, invent new solutions and move on, otherwise we are doomed to failure.

Our publications based on Gov.uk materials:

Source: https://habr.com/ru/post/286216/

More articles:


All Articles