Retrospectives are essential and the key to any team’s success. Retrospectives have become a bigger deal as more teams begin to implement Scrum, and are utilizing the Agile mindset to become better, effective teams. However, as we incorporate Retrospectives regularly into our projects, we should ask ourselves – are we using retrospectives efficiently and effectively? What should our mindset be when conducting a Retrospective?
A Retrospective generally occurs at the end of the sprint, or at the end of a project as point of reflection upon the team regarding their successes, struggles, achievements, and pain-points. A lot of data and information points will reveal themselves during a Retrospective, and taking a business analyst, analytical mindset can add a lot of value to these meetings. This article will reveal the value gained from taking a Business Analyst approach to Retrospectives, and how it can lead to a transformative experience for your team and project productivity.
How can a business analyst mindset transform the practice surrounding good retrospectives, create an engaging meeting, and promote active change across their team? There’s no tried and true formula to a Retrospective, but I have found the ones that are the most successful rely on the characteristics and practices of good BAs. Thus, conducting Retrospectives that are data driven, clear, honest, creative, and experimental. Why? This the same mindset a BA uses to uncover and resolve complex issues throughout an enterprise system, workflow, or software. Utilizing the same processes can allow these meetings to uncover patterns throughout the team, reveal root causes, allow for creative solutioning, and properly handle inter-personal conflicts.
To create this empowering environment, I’ve added own twist with a Business Analyst focus from Esther Derby’s approach to Agile Retrospectives:
1. Establish a focal point: What are we trying to achieve here?
- For the first few meetings, familiarize your team with what a Retrospective is and the purpose of the meeting. Establish a team goal. Attempt to answer the following questions: What is the team trying to resolve? What are our successes? Where are our failures? How can we get better?
- Define the meeting in your own relatable terms to get team buy-in. Avoid making the meeting feeling like another formal, bureaucratic meeting.
2. Set an agenda
- Always, always set an agenda with the larger themes that you’d like to accomplish throughout your Retrospective. Let the team know when we’ll be gathering data, discussing, and solutioning. Be clear and honest about what you want to accomplish and how. This can be written on the white board, sheet a paper, or verbally announced throughout the meeting.
- Allow time for fruitful team discussions, but try to avoid tangents. We want to be respectful of everyone’s time and ensure we are still productively working towards our end goal. If you feel a tangent arriving, be a BA, handle conflict or inter-personal conflicts professionally, but thoughtfully. Politely interrupt, let them know that what they are saying will be included when we are solutioning, and that the team will respect how they are feeling about the subject/person/item.
3. Review the previous retrospective
- Take some time to review the previous Retrospective with the team. Discuss what did they do, what could they have done differently, and if something could not be accomplished the previous sprint.
- Summarize the main points and write them on a white-board, you may need to reference them again throughout the meeting if you start to see similar patterns emerge.
4. Gather Data
- Collect data about the Sprint and project experiences. Avoid typing people’s experiences into an excel document. Be creative and experimental! Think like how a BA may capture data from key-stake holders or users. For example: Color-coding good and bad experiences throughout the Sprint and project is a clear way to identify what we went well, and what went wrong. Ask every teammate to write positive experiences on green post-it notes for successes/wins, and negative experiences on red post-it for challenges/loses/pain points. Ask them to bring up as many points as they can in a specified amount of time (i.e. 5-7 minutes writing all good experiences, repeat for bad experiences) Have team post thoughts onto a board.
- Read the post-its out loud. As you do, internalize the information and analytically group the points. If the same comment emerges multiple times this may highlight an occurring issue, strength, or problem. Group post-it as: areas of growth, failures, and successes, giving a clear pathway and visual towards tangible solutions that the team can utilize.
5. Generate Insights
- What does the data mean? Do we see specific patterns emerging? This is the opportunity to use the Business Analysis mindset and begin to identify root causes and influences. Once the entire team sees and visualizes the data, it may be clear what are the issues that are impacting the team. If similar patterns keep emerging, bring in data from previous retrospectives to highlight team behaviors and actions.
- Highlight to the team patterns that you see for both successes and failures. Tools such as a Fishbone (Ishikawa) diagram or the tools of 5 Whys? Can help with identifying key issues or root causes.
6. Establish Deliverables and Close-Out the retrospective
- Once the analysis is conducted, decide what actions can be taken within the next Sprint. Write down simple 3 words sentence or quick phrases the team discusses on a different colored sticky note. Stick it next to the issue/problem the team noted. Don’t develop the entire plan in the Retrospective, decide what can be done, and determine in a separate time where a detailed plan of action can be created. We want to focus on solutioning more so than planning.
- Categorize the solutions by level of Impact, Effort, and Energy within groups of High, Medium, and Low. By clearly seeing the information, it is easier to see what items can easily be completed, what may take more time, or could be an overall team effort.
- Close out the retrospective. Decide who will do what. Ensure that everyone knows what they are responsible for.
- Document, document document. Use that inner-BA, and take photos of the white boards and start documenting the information. Don’t lose the data-points collected from this meeting.
A Retrospective can be conducted in a multitude of ways. Thinking like a Business Analyst can allow for a productive, prolific Retrospectives. Utilize a Business Analyst’s analytical mind, sound communication skills, and creative solutioning. Be mindful, thoughtful, and engaged throughout the Retrospective process to grow and challenge your team to be the best they can be.
Author: Qarina Mannaf
I am a Senior Business Analyst, Project Manager, and Professional Scrum Master at Improving, an Agile Software Consulting Company, based in Houston, Texas. I’m heavily involved setting up good Agile and Scrum practices for many of our clients. I’m actively engaged in client assessments and understanding ways we can incorporate Agile and Scrum practices into their software and product development needs. I lead cross-functional teams and help companies reach their project and product goals and deadlines. Outside of work, I am a long-distance runner, weight-lifter, scuba-diver, and traveler.