Sprint Retrospective as a reflection of the team working on the product

Meaning and Aim of Retrospective

The retrospective aims to analyse what happened during the last sprint. We take into account people and interactions between them, the delivery process, tools and operational systems. Our approach to the process is holistic. It is from a distant perspective that we start to reflect and analyse the events relevant to the process. What does “relevant” mean? It defines all events that have a significant positive or negative impact on the work flow. The events are associated with group dynamics, relationships, praised attitudes and behaviours, conflicts and other difficult situations for the team, cooperation with stakeholders, practices and principles, team values, the current situation and organizational culture.

Thanks to the retrospective, we can look back, but we think about the future. Although we have no influence on the past, we can still change the future!

In order for the sprint retrospective not to turn into a witch hunt or blame game, we must remember that we are all responsible for the goal. It is both our engagement and joint commitment to deliver functionality (Increment). Respect for each other and for our work is essential.

It’s not uncommon to encounter conflicts as well as emotional outbursts at the retrospective meetings, but that’s exactly why we need to have a facilitator who takes care of the team’s comfort, group process and the dynamics of the meeting. They moderate and make sure that the goal of the retrospective is achieved and the team have assigned the selected action items.

Honouring Scrum Values and Pillars

It is worth looking at the retrospective in terms of the pillars and values of Scrum. There are the following Scrum Values: courage, focus, commitment, respect and openness, as well as three Scrum Pillars: transparency, inspection, adaptation. Periodically, after each sprint we focus on the process, that is, we carry out an inspection. Honouring the values, we must have the courage to speak openly about what happened, what we managed to accomplish or what was missing during this sprint. It is important to be honest and transparent. Only then we will be able to identify and analyse areas for further improvement in the process, as well as implement new solutions.

Communication plays the most essential role here. It should be precise, clear, direct, assertive and respectful of different opinions, ideas, attitudes and needs. We can see every Scrum Value and the Pillars on which it is based. The atmosphere is of paramount importance, too. We need to be able to open-up to feedback, learn how to give and receive it.

Improvement Implementation

What is adaptation in relation to the retrospective? When the Scrum Team identifies and analyses the strengths of the sprint and areas for improvement, it explores and provides suggestions for solutions, then selects the ones to be implemented during the next sprint. Here the difficulties begin, because in order for our retrospectives to be effective, it is not enough to determine what has to be changed. People must actually feel that they have an impact on the development of the process and can participate in the decisions concerning the direction these changes go.

For that to happen, we have to follow a few rules. It is important that the proposed activities – action items are assigned to the owners, that is persons responsible for ensuring or implementing the solutions. Once the goals have been set, they must be written down. The aims need to be real, ambitious and adequate. They should be determined in time, that is, they must have their time-boxes. It may take the entire sprint, or if something requires more work, two sprints or release. It is a good idea to prioritize actions in terms of validity, impact and self-implementation. You can use a simpler version of SMART. For each selected action we answer three questions:

• Do I know what to do?
• Can I start doing it right away?
• Will this significantly affect the solution of the problem?

Best practice is to place these goals in the backlog, and the planning should be included in the sprint agenda. These goals will be the first tasks that will appear on the scrum-board with the requirements and tasks to perform. It is advisable that the goals are communicated to the Management by the Scrum Master. The role of the Managers is to support the team and enable it to achieve its goal or goals.

Feedback loops and the Deming Cycle in relation to Kaizen

First of all, let’s define a feedback loop. According to Wikipedia, „Feedback occurs when outputs of a system are 'fed back’ as inputs as part of a chain of cause and effect that forms a circuit or loop.” Agile or Lean (optimization processes) incorporates this concept, however from my perspective, the most important implementation of feedback loop is defined by Kaizen with the PDCA cycle.

Software development is an empirical process that is based on the PDCA – the Deming Cycle. A feedback loop has four basic stages:

• Plan something
• Do it
• Check the result and see if it is what we want
• Based on the result, adjust what we do during the next cycle.

PDCA (plan–do–check–act or plan–do–check–adjust) is an iterative four-step management method used in business for the control and continual improvement of processes and products. Source: https://en.wikipedia.org/wiki/PDCA

Kaizen is the Japanese philosophy of continuous improvement. A technique of small steps that help create new standards. It is a continuous process that requires regularity, discipline and conscientiousness. Continuous improvement (Kaizen) is not possible without reflection (Hansei). Hansei is also an element of continuous improvement of processes. In Japan, in the production processes of Toyota, meetings devoted to reflection are frequently organized – Hansei-kai (reflection meeting). Their goal is to discover and diagnose weaknesses in order to be able to sort them out. These meetings take place at the end of each phase of development of a new vehicle. Thus, they are the equivalent of the Scrum Retrospective.

The Deming Cycle is an inherent pattern of iterations in Agile methods. It forms the basis of Scrum. The Check element in PDCA is implemented in Scrum as a Sprint Retrospective. The Deming Cycle in Scrum goes as follows:

• Plan – sprint or release planning,
• Do – iteration, development and tests,
• Check – daily monitoring with daily stand up’s, sprint review and retrospective meetings, inspection, introspection,
• Act – adaptation, action items with retro and implementation.

Stages of the Sprint Retrospective

In the book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen, the authors explain a retrospective as having the following steps:

• Set the Stage: make sure everyone feels safe and is in in the retro.
• Gather The Data: what happened. Make sure everyone has the same picture.
• Generate Insights: analyse the data to find root causes.
• Decide What To Do: which experiments could help us to improve the process.
• Closing by answering the following questions:
  • What will happen after the meeting?
  • What did I learn?
  • What was important/valuable?
  • What am I going to do?
  • How will we evaluate the success of our next steps?

The team constantly adapts itself to find the optimal dynamic in its collaboration. Based on the results and obtained information, the team creates and introduces new standards.

And then the process repeats. Scrum is a continuous loop of planing, building, inspecting, adaptation and repetition.

It is important that the team remembers about the Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Source: Norm Kerth, Project Retrospectives: A Handbook for Team Review

The purpose of the Prime Directive is to assure that a retrospective has the right atmosphere to make it a positive and result oriented event. It makes a retrospective become an effective team gathering to learn and find solutions to improve the way of working.

Source: http://retrospectivewiki.org/index.php?title=The_Prime_Directive

A retrospective helps you sift good things from bad ones, successes from failures. Usually, the improvement of the process is emphasized, and the most important function of the retrospective is that it purifies the team. The effect is known as catharsis. This is a very important moment for the team. Retro is aimed at dropping unnecessary ballast, so that we can move on to a new stage, often connected with leaving the comfort zone. Regarding the team’s maturity, this may be related to entering a higher level – the next stage of team development (Tuckman). The retrospective meeting is a stop in the scrum process, it is time for reflection. We are looking for solutions, therefore it must be developmental and creative. Honesty, inquisitiveness and openness to change are important here. The retrospective is the moment when the team inspects and introspects.

Best Practices for Conducting the Retrospective

• Scrum Master is the organizer of the Retrospective. This person does not always have to lead retro, he/she facilitates, but does not have to moderate. It is important that the Scrum Masters don’t do the job for the team. Instead they let the team feel co-responsible and develop its self-organization. It is worth looking for individuals who are willing to take initiative and encourage people to prove themselves in moderating meetings. Let the team develop new competences.
• If you are a new Scrum Master and need support, ask your colleagues, senior SMs or Agile Coaches, to lead a retro for you, and you will be able to observe.
• Invite people to a meeting. How would they benefit? Make people want to come out of curiosity, commitment, sense of responsibility.
• Send an invitation to the meeting early enough for everyone to be able to attend it. If you have a team locally, do not agree to a remote retrospective.
• Always ask the team if they would like to invite someone to a retrospective.
• If you know there is a need, encourage Product Owner to participate in retro. Invite this person if the team needs their presence, especially in situations when you know that you will be discussing issues related to requirements and communication with the customer.
• When you start working with a team, find out if they have had retrospectives before and how they were run. Set up a working agreement for retrospective, build rules and a list of values as guidelines for the retro process (these may be Scrum values, or your own).
• Observe the team and its work every day! Ask, talk, gather information as to any obstacles or work impediments. Thus, conclusions and ideas will be born spontaneously.
• In every retro, after the Generate Insights stage, do a summary of the previous retro actions (evaluate previous retro).
• Praise people for what they do well! Not all retrospectives must end with improvements. The team can create, work out rules and update them. Retrospectives can be used to celebrate achievements, motivate the team by strengthening best practices and behaviours, by pointing out the strengths, resources and values of the team, as well as by acknowledging people who have significantly contributed to success.
• Try to provide people with the right work conditions. Look for a comfortable place, where the team will be able to work in a calm atmosphere, without interruptions.
• At the beginning of the retrospective, diagnose peoples’ feelings. Create an atmosphere of cooperation and open people to mutual discussion.
• It is worth to give individual team members the opportunity to introspect. Build space for the development of individual interpersonal competences. It is a good idea to propose a test that will help people discover their strengths and identify the area for development (for example – the Belbin test). Such practices help develop the team by building its potential.
• Experiment, but do not improvise! Be prepared. Pre-plan the meeting scenario and agenda. Interesting techniques for retrospective meetings can be found here http://www.funretrospectives.com/
• If you start working with a new team, work out with them the principles of working on a retro. It is worth defining with people the common values that a team has, and then referring to them in difficult situations.
• Supervise yourself! Ask a colleague or Agile Coach to be present at your retrospective to make notes, and give you feedback. Work out your best practices and implement them!
• Look for a mentor, developmental group, go to meet-ups, conferences and trainings. One of the basic tasks of SM is continuous development. Whenever you have the opportunity to read, listen, browse the internet, look for inspiration and solutions.
• Remember that the level of knowledge about the Scrum may be different. You need to check your team’s knowledge about Scrum beforehand. It is worth to run a short scrum workshop.
• Show trust and build relationships with the team and individual members. Ask for feedback after retrospectives, check not only a ROTI for your meetings (Return on Time Investment), but also how the team perceives you.
• Deepen reflection, provoke thinking, motivate to learn!
• Scrum Master has a very responsible role, you have to be bold, vigilant, assertive. When the Scrum Master sees that the team may not be able to achieve the goal, he/she must react as quickly as possible. It may happen that we cannot wait for a retrospective, so you need to react just in time. Remember that SM is not the only person to solve problems. They have the whole staff to tackle problems 🙂 What it means in fact, is that you are looking for someone who can deal with that.
• Try to make each retrospective different. Remember that diversity is the spice of life.

Conclusion

We already know what conditions must be met for the retrospective to succeed. Faith and commitment of the scrum team to work efficiently is a must. Each Scrum Team member should personally care about the team and do their best to create a valuable Product Increment.

A retrospective with inspection and adaptation is aimed at developing a better quality product in the spirit of continuous improvement. This is a major advantage from the customer’s point of view. We have a working product, but with each retrospective and iteration it gains in quality. This is possible due to the fact that we care about people, processes and tools. We acknowledge the Agile Manifesto:

Individuals and interactions over processes and tools.
Responding to change over following a plan.

It is important to us that after the end of the sprint and a short break, the empowered team could enter the next iteration. A retrospective is not looking back and crying over spilled milk. It’s thinking with a vision of the future. If you have came to a poor team, you have to change it. You have to focus your energy on searching for solutions and appeal to the value of openness.

Sometimes a retrospective can be carried out outside the company if, of course, decision makers approve of such an idea. It can be held in a place with a separate room, flip-chart, or access to multimedia. Such retrospectives work especially when the team has delivered some important functionality. It is very important to stop in the scrum process and give the Scrum team time to celebrate success. This can of course be done at a special party with managers. We can also combine retrospective with the celebration of achievements. The Scrum team will remember this retro better. Such retrospectives are intended to show the strengths of the team, strengthen positive behaviors, and indicate the owners of successes, or real stars, They increase motivation in the team, teach people how to accept praise and compliments, integrate the team and build its identity, strengthen the focus on goals, develop the team’s maturity.

In many IT teams it is still necessary to reinforce the conviction about the need to conduct retro. It is a great asset for teams, organizations and customers.

Retrospective is a practice that has been implemented more and more often in other industries. It has proved to work successfully outside the IT world.

Sources:

• https://assets.uits.iu.edu/pdf/Agile-Manifesto.pdf
• https://www.scrumalliance.org/community/articles/2015/march/the-power-of-feedback-loops
• https://www.atlassian.com/agile/scrum/retrospectives
• https://blog.procognita.com/

Books:

• https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
• Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen
• Project Retrospectives: A Handbook for Team Review by Norman L. Kerth
• Scrum. About agile project management by Mariusz Chrapko
• The Toyota Way. 14 Management Principles from the World’s Greatest Manufacturer by Jeffrey K. Liker