Flexible methodologies. Retrospective

    Retrospective (from lat. Retrospectare, "look back") - a look into the past, an overview of what was in the past.

    In flexible methodologies there is such a thing as “retrospective”. At first glance, it may seem that this is a completely unnecessary element. But I know for sure that using retrospectives improved the development process on my team.
    So, a few definitions:

    A retrospective is a meeting held by a project team at the end of each iteration to discuss what we learned as a team and make plans for the next iteration, based on lessons learned.
    Retrospective is a team activity of reviewing the nearest time period for a team to improve the process of working with the same team in the same project.

    Everything sounds pretty simple and logical, but our team managed to make retrospectives useful and effective far from immediately.

    What is needed for retrospective?
    1. Team (Agile advises to gather everyone, including customers, but only developers gather here)
    2. Room for the meeting - it’s desirable that it be a separate room, for example, a meeting room (so as not to bother anyone, and no one didn’t interfere)
    3. A board for drawing or sheets fixed for drawing
    4. Markers (preferably several colors)
    5. Time from half an hour to two (the duration depends on the frequency of the retrospectives, the number of people in the team, the formation of the team itself)

    How is the retrospective going?
    There are several stages:
    1. Survey of opinions (what was good and what was bad in the past iteration?) And fixing them on the board
    2. Voting
    3. Highlighting and discussing the main topical problems (Gained the majority of votes)
    4. Determining ways to solve the selected problems responsible for them
    5. Recording of achieved results (Discussion of tasks that were solved by the results of past retrospectives)

    Each retrospective must have a presenter: “a person with a marker.” In the description of the methodology, it is not recommended that the leader be such a leader. Our team came to the method of “relay stick”: i.e. Leaders change from retrospective to retrospective. The most important thing that the facilitator should do, or rather DO NOT do, is not to overshadow the words and statements in their own way, because this can distort the meaning of the statement.

    Opinion polls can be conducted openly, or anonymously (then the facilitator collects leaflets with paragraphs written on them). The most important thing in the opinion poll is not to slide into a discussion of this problem, but only to fix it.

    And we never forget about the “good” items, they should be asked first of all.
    “What did you like in the last iteration?”, “What positive points could you note?”, “What would you like to write in the“ good ”section?” - exemplary questions asked by the lead team members. Similarly, in the "bad" section.

    By the way, the number of points, their “seriousness” and the prevalence of any section, quite clearly shows the “formation” of the team, the “set-up” of processes, etc.

    Voting can take place in many ways. It is possible to identify “prioritization” of a task for a person (raising 5, 4, 3 fingers, etc.). Our team has chosen the way to limit the number of votes. Everyone can vote for only a third of the points. (If the “good” section has 12 points, then a person has 4 votes and that means raising his hand and voting for any 4 points out of 12).
    The host counts the votes and writes a number opposite each item. The most “popular” topics in each of the sections are highlighted. Usually 3-4 of them, this is the most exciting problems for the team and marked by all the "amenities".
    (This is where the colored markers will be needed - to separate the numbers of votes from the numbers of points and for the stroke).
    Items from the “good” section are simply captured in a retrospective report. (The team must remember their achievements!)
    But with the items from the "bad" section, we still have to work. It is very good if the team having discussed it comes up with a solution to these problems, or at least the initial path along which it is necessary to move to solve it. Here, the person responsible for the task is selected, who should do everything possible to solve it.
    For the convenience of tracking retrospective tasks, we set them up in Jira and act like normal project tasks.

    At the very end of the retrospective, the results of past retrospectives are briefly discussed, those responsible tell about what has been done. (“But now we have it! And now we are doing so-and-so. This is the last time we came up with it.”) Sometimes we correct the past tasks and reassign the responsible ones.

    Starting to write an article, I realized that the topic is quite extensive. If the community will be interested to know further, then I will write a sequel, where I will talk about emerging issues and the ways we fought with them.

    Also popular now: