Avoiding problems, Customers, Office

Retrospective. Just do it!

August 27, 2017
Retrospectives in software engineering

In software engineering, retrospectives are always linked do Scrum alliance’s practices, since they have summarized the main goals very well. Rishi Devendra states the main steps of the retrospective as:

  • What went well during the sprint cycle?
  • What went wrong during the sprint cycle?
  • What could we do differently to improve?

Following the steps above you will easily have an output with next steps, things to improve and great successful things. That should even be shared with the rest of your team or company, so everyone can learn from that moments.

Retrospective output Example of output after a retrospective in a common perspective.

 

A fast guide

I’ve learned and got a lot of experience during many years of project retrospectives. It can easily follow this simple and objective recipe:

      1. First of all, the environment
        1. Try to make it happen outside your regular formal environment. It will make people more likely to speak what they really think, and be less resistant to any different opinion that may come around;
        2. Mix it with a meal. Starting at lunch time or finishing with a dinner will help on team’s personal connection;
        3. Why not allow people to have a beer meanwhile? It depends on how your company deals with that. But it’s not a bad idea;
      2. Ice breaker
        1. It’s very important if you have a team that never participated of a retrospective (some nice ice-breaker examples here);
        2. Try some activity that make people laugh and talk about each other at the same time;
        3. The intention here is to make people feel comfortable talking about work outside office and understand the objective of the activity;
        4. Make the main goal of the activity very clear to everyone. Why we are here? What’s the objective? What will we take from this moment?
      3. Now it begins
        1. At this time everybody must speak their mind;
        2. Set up a time limite, like 10 minutes;
        3. Give post-its and pens to everybody;
        4. Write everything that have been happening, both on good and bad ways;
        5. Write about your project, your tasks, your mates, your coampany’s environment;
      4. Let’s discuss!
        The main goal here is to split the good and bad opinions into two different visual areas and, during that, discuss about everything. The whole team must discuss about the topics and it’s everyone’s responsibility to understand the message.

        It’s very common to use some analogies. As an instance, a balloon (where the bad things are the sand bags, that pushes the balloon down, and the good things are the air, which pushes the balloon up). It can also be a rocket (in the same way of the balloon), or even a boat: the good things are the wind that gives speed to the boat, and the bad things are the anchor.

        Activities analogy with a boat
        1. Starting by a volunteer, everybody must speak the post-its that have written and the whole group must discuss about it.
          1. If it’s positive, it’s placed over the wind (on the image above);
          2. If it’s negative, it’s placed over the anchor;
        2. During this activity, when someone is speaking about their post-it, everyone that may have a similar opinion about that subject can interrupt and contribute to the subject and place their post-it also;
        3. The team should discuss about all the topics and understand how does that affect them;
        4. This activity will probably take the majority of your time, and will depend on the number of people who’s involved;
      5. The most important part: action plans!
        1. Now that everybody knows about everything that the team have been facing, it’s time to create the next steps;
        2. For the good things, the compliments FOR THE TEAM are free. It’s not time for feedback sessions;
        3. Regarding the bad things, the team must bring up the most important topics, and create an action plan for each of them. It must contain:
          1. What’s the problem? Eg: The bugs report have been hard to understand and track;
          2. What will be done to solve? Eg: We will set up a new storytelling way to describe the bugs in a way that everybody understands and group it all using a new open source tool;
          3. Who will be responsible? Eg: The main QA professional;
          4. What’s the deadline? Eg: One week starting from next monday, September 1st;
        4. It’s important that everybody leave the retrospective having a mission to accomplish. It will improve the sense of ownership inside the project;
      6. Feedbacks among the team

        The retrospective can get deeper depending on the team’s maturity to discuss about the project and about themselves. If you have an under-construction team, that doesn’t has a strong relationship yet, don’t worry about including this practice. It can be added while your team develops itself.

        But if you already have a mature team, that knows each other and are feeling free to give each other straight feedbacks, it will be very important! A well given feedback among the team will increase the confidence within it, and will make people to work better on that group. Be careful not creating a conflict here. You, as the retrospective leader, must know the limits.

 

You’re done

After your retrospective you probably will have an action plan for every point of problem. It was you goal, right? It’s very important for your organization and for your way to get the work done for that specific customer.

But the team also gets very important benefits from that. With this practice you will ensure that your team is under a continuous improvement process, and their trustship, ownership sense, and team work are growing.

 

You can find more useful content about retrospectives, from Scrum.org.

You Might Also Like

No Comments

Leave a Reply