Dwelling On The Past: The Importance Of Project Retrospectives (Part 1)

Retrospectives do not require intense resources to plan or conduct. Some costs are associated with retrospectives, particularly with getting your team together to work on something that will pull them away from their projects. You will need to budget expenses for time if you work with contractors on your team. You will need to consider when to hold the retrospective; you don’t want to pull members away from other work at critical times or to disrupt their productivity.

The rewards of running effective retrospectives outweigh the costs. Effective retrospectives require a commitment to maintain an open mind and open communication with your team, as well as a willingness to be vulnerable. If you engage in retrospectives with these commitments, you can expect your team members to grow individually and as a group. You can expect your team and each member to better understand how to improve their process.

What Isn’t A Retrospective?

Project retrospectives are an important component of healthily functioning teams. In order to fully benefit from retrospectives, you should keep in mind some limitations and guidelines:

• Retrospectives do not replace communication or action taken to fix team or project issues at the time of occurrence.
• Retrospectives are not an excuse to spend an hour complaining (although it is important to let some venting happen during the session).
• Retrospectives are not an opportunity to lecture your team on what they could have done better. Ideally, you would be proactively coaching your team throughout the project.
• Retrospectives should not be a huge burden on your time and resources. I recommend 60 to 90 minutes for reflection if you have a team of 5 or 6 people. This gives everyone ample time to discuss each of the broad themes we’ll cover later. This also forces people to be wise with the time they have during the retrospective.

Why Conduct A Retrospective?

Your team would benefit greatly from properly planned and executed retrospectives. We learn something new about ourselves, our product and our team in every project. We also risk losing this knowledge or failing to incorporate the lessons if we don’t engage in retrospectives. You codify the lessons learned when you conduct retrospectives. You solve team issues as a team.

Researchers have identified many benefits from software design and development teams engaging in project retrospectives (see the links at the bottom for references). Some of these benefits include:

• ensuring that team members recognize and remember what they’ve learned,
• allowing team members to share their experiences with each other,
• identifying opportunities for the team to improve,
• providing an opportunity to initiate change,
• acknowledging what went well during a project.

Project retrospectives are a means to show your commitment to your team. When you engage in retrospectives, you are signalling to others that you take learning from experience seriously. You are telling the team that you understand that perfection isn’t possible; there is always something to learn from experience. You are prioritizing growth and learning over pushing out a product and moving on to the next challenge. Team morale and performance improve when you reflect these values.

Planning A Retrospective

Allow for sufficient time to plan your retrospective. Whoever is facilitating the session should have an idea of how the project went. They should have a few talking points for each area to be discussed, in case the conversation needs prompting.

I have participated in retrospectives facilitated by project managers, by team or project leaders and by managers. Appoint someone who has training in facilitating conversations. If you have a team member trained in agile methods, they are likely to have some training on running retrospectives. Regardless of who facilitates the session, they should have a neutral stance towards all of the information that members of the team present. They should be fair in how they run the meeting. They should not be someone in a position of power who might intimidate any team members from speaking up.

Team members should know, preferably at the beginning of the project, that a retrospective will be taking place. You can suggest to team members to keep logs or make diary-type entries in a notebook or online in order to keep track of how they feel about the project as it unfolds. It’s difficult to recall specific things that worked well or that needed improvement at the end of a project. Proactively logging one’s experience helps to avoid this.

Your team’s logs could look similar to the prompts used during a retrospective:

Project Name and Date

What’s working well?	Notes
We are all on the same page with the work being done.	We frequently meet internally to discuss who is doing what. We are keeping our sprint backlog up to date.
What isn’t working well?	Notes
The client has complained that communication isn’t streamlined.	We were given multiple points of contact (PoC) at the kickoff meeting. We have had trouble getting replies from one of them. Maybe this is why.
How could we improve?	Notes
Reduce the number of people we are going through to get permission. Determine who needs to be contacted and what we need to contact them about.	We need to determine a single PoC for our team and their team. The client feels that not all of their team needs to be involved in our communication.

Most retrospectives require very few resources to be planned. At a basic level, you can conduct a retrospective with a comfortable meeting room, a whiteboard, dry-erase markers (at least three different colors), a conference-call line, and screen-sharing software or video (for remote team members to participate). Finding a time that works for all team members can be the most difficult part of planning a retrospective.

Below are some specific steps to take to plan your retrospective. Incorporate others as relevant.

Preparing as a Facilitator

Determine your list of participants; make sure everyone involved is invited (even remote folks!). Your retrospective is only as good as the people you include. It would be more effective if everyone who has been involved in the project is invited to attend. Perhaps one designer took over for another designer halfway through the project — invite them both. You would benefit from understanding how the transition went, from the viewpoint of both the designer who started on the project and the one who took over. You would benefit from a deeper understanding of the bumps along the road if you include people who were a part of the process in unique ways. However, including some people might not be necessary if their role was extremely limited.

Remote staff are critical to a project retrospective. These team members have a unique perspective. You’ll want to know whether they felt included and actively engaged with their on-site colleagues. You’ll also want to know whether they have suggestions to make their lives easier as remote staff. Likewise, your on-site staff should have a voice regarding what it felt like to work with remote staff and any suggestions they have to improve collaboration with remote team members. We often include video options such as WebEx or FaceTime on iPads to give our remote staff a greater presence at retrospectives.

Ask your team to review their notes and come with the following input:

• What went well
  For example, “Good communication between research, design and development throughout the project.”
• What didn’t go well
  For example, “Finalization of deliverables felt rushed throughout the project.”
• How to fix it
  For example, “Clearly state deadlines throughout the project; have frequent progress check-ins; build in time to review deliverables so that changes can be made.”

Have your team do this prior to the retrospective. You don’t want to put your team on the spot in the meeting. Be clear in the invitation about what the topics of discussion will be. Also, be clear that everyone attending is expected to participate in the discussion.

Reach out to see who is going to say what. You don’t want to get blindsided during the retrospective. You need to know whether something major happened that is going to lead to a longer discussion, in which case you’ll need to plan the right amount of time for that discussion. You also want to try to defuse anything that might seem personal prior to the session. Likewise, if you find that no one has anything critical to say about the project, then you might encourage them to think of some things they could mention.

Important: The point here is not to reach out to argue with team members you don’t agree with, but to have an idea of what folks are going to bring up. Take action prior to the retrospective only if absolutely necessary. You aren’t doing it right if team members feel shut down prior to the session.

Determine your assessment of the project. You should know where the project succeeded and where the project fell short, according to your expectations and performance indicators. You can use these to focus the conversation and to support any arguments made for or against certain issues in the project.

Make the retrospective a celebration of your team. Provide food and drink or some type of treats. Team members will appreciate the effort to create a positive atmosphere, and it will reduce the potential distractions of hunger and thirst.

Preparing as a Participant

A retrospective participant shouldn’t have to invest much time preparing. But coming to the session prepared is important. I’ve suggested keeping a log or journal noting how the project unfolded. You can use this yourself as part of your preparation for the retrospective. Come up with a list of three or four things that went well in the project, and three or four things that could have gone better.

Once you’ve refined the list, make sure you haven’t created a list of gripes and personal complaints. Those are valid, but they don’t serve to create a positive retrospective. Resolve any personal issues you’ve had with team members in a more appropriate setting than a retrospective. Convert gripes into problem statements that you can then use to identify solutions in the retrospective.

Conducting A Project Retrospective

Many resources are available for conducting a retrospective. Esther Derby provides a five-step approach for retrospectives in Scrumpedia. Although the focus is on two-week retrospectives, you can use the same steps for a post-project retrospective. Derby’s steps include: (1) set the stage, (2) gather data, (3) generate insights, (4) decide what to do, and (5) close the retrospective.

Elise Keith presents a three-step process on the Lucid Meetings Blog: (1) review the project, (2) discuss what worked well and what didn’t, and (3) action planning: identify specific ways to improve future work.

Norman Kerth’s handbook on project retrospectives provides four questions to guide a retrospective: (1) What did we learn? (2) What should we do differently next time? (3) What did we do well? (4) What still puzzles us?

There isn’t one right way to do a retrospective. A quick search on Google yields dozens more articles on how to conduct a retrospective. Below, I discuss some key features that every retrospective needs to include.

Managing Discussion

Time management is critical for a successful retrospective. You run the risk of having to cut people off if you don’t schedule enough time. You run the risk of people losing interest if your meeting is too long.

Allow discussion to occur when necessary, but with a focus on the solution. You will often find that people agree in a number of areas. For example, everyone might think the project’s timeline was too tight. You can save time by asking people to indicate their agreement with something stated and not bring it up again when it’s their turn.

Be aware of the order you expect people to speak. You can determine the order at random by assigning everyone a number and drawing from a hat. You might want to use a predetermined order based on your awareness of the reality. For example, you might want to encourage junior staff to contribute their own ideas and ask them to go first to discourage them from echoing what senior staff say.

Create a Safe Atmosphere for Sharing

This is the most important step. Your retrospectives are worthless if people are not comfortable sharing their true thoughts and feelings. The facilitator should make it immediately clear to participants that everyone’s viewpoint needs to be respected. Ground rules should be set: no confrontational comments or personal attacks, but also no sugarcoating problems.

There will be situations in which specific aspects that need improvement are related to the attitude or skills of an individual team member. I encourage managers or team leads to find ways to have this discussion individually, outside of the retrospective.

On the other hand, if there is an issue related to an individual making decisions that didn’t work out, that’s appropriate to discuss as a group. You can approach these types of situations in a less threatening way by referring to the group rather than the individual. For example, rather than saying, “Victor dragged his feet with starting to recruit people to participate in research, so we fell behind schedule,” you could say, “We thought it would be a good idea to hold off on identifying our research participants, but this led to us falling behind schedule.” This allows the discussion to lead to the conclusion that the person in charge of recruitment should be more proactive about scheduling in the future.

Your retrospective should take place in a comfortable setting, with ample time set aside for attendees to provide feedback. You could consider holding the retrospective off site, in order to put participants at ease.

Create Ownership

The project team owns the result of the project. They also own the quality of the retrospective and the ideas coming from it. Challenge your team to constantly improve. You are the facilitator, but the team is tasked with solving issues that arose during the project.

Don’t excuse areas where improvement can be found. For example, if your team struggled with fitting in all the project tasks in a timely manner, don’t provide the excuse that many team members were busy on multiple projects. Instead, push for how to better provide a balance among team members’ duties and other obligations.

Document Everything, Even If Only One Person Says It

Ensuring that everyone has a voice is a part of the purpose of a retrospective. You don’t need to gain a consensus on every item someone brings up. You show respect for the individual experience when you acknowledge everyone’s thoughts. You gain buy-in and trust when you do this. Documenting thoughts on the white board allows everyone to see what was said and enables you to track what has been said.

Celebrate the Good

Everyone should have something positive to say, even if it’s just “Hey, everyone is alive!” Your team likely contains a mix of personalities. You help to create a positive vibe for the whole group when you call out people for jobs well done and congratulate those who made progress and accomplishments over the course of the project. You also increase team members’ receptiveness to criticism when you provide positive feedback in a retrospective. Did anyone get a promotion during the project? Celebrate that. Did anyone gain a new skill or tool? Celebrate that. Find things to celebrate.

Discuss What Worked Well

Do you want the good news first or the bad news? My preference is the good news. We often have much longer discussions about what didn’t work so well for our projects. You don’t want to run out of time and not talk about what worked. Discuss what worked before discussing what your team could have done better.

Discuss What Didn’t Work

You’re rarely perfect. Even in a feel-good project, you can find areas to improve. Often, you’ll identify areas around communication that could use tweaking. At one point during an otherwise smooth-running project, I called a meeting to review how we were incorporating research findings into our design concepts. My managing director said something like, “Now let’s hear what development has to say.” I had forgotten to include anyone from development in the meeting, so there was no response. Actually, I hadn’t even thought of the need to include development — we were talking about design and research, right? I had become complacent at that point in the project, forgetting to include key team members in a meeting. We discussed why this happened and the need to invite people to our retrospective throughout the duration of the project.

Identify a Specific Path to Improvement

Your team should engage in dialogue to identify possible remedies for the areas in need of improvement. The solutions should be as specific as possible. For example, instead of saying “Invite everyone relevant to each meeting,” say “Invite representatives from every discipline (research, design, development and engagement) to each meeting.” Instead of saying “Begin the process of recruiting research participants earlier,” say “Draft the recruitment screener and email prior to the kickoff meeting, and send the recruitment email immediately following the kickoff meeting, or earlier if possible.”

Come to a Conclusion

A project retrospective is meant to be all-encompassing. Cover the project from start to finish, major milestones and deliverables and all other aspects relevant to the project. Your team should feel that they’ve put everything out and had it recorded on the white board. Any issues should have solutions identified. No one should leave the retrospective feeling they didn’t have a chance to participate fully. No issue should be left unresolved, or at least not without a concrete timeline for you to come back to address it.

Post-Retrospective

You’ll need to go beyond the retrospective to fully realize its benefit. Document every retrospective and the outcomes your team agreed on. Include a list of who attended, the purpose of the project and any other details to explain the context of the retrospective. You will look back on these at a time when the project will not be as clear in your memory as it is immediately following the retrospective.

You don’t need to do anything time-consuming to document the session. We typically write out everything from the session on a white board. The facilitator takes pictures of the white board and later transfers the information into a document. You can use a simple chart to record what was said:

What worked well?	What didn’t work well?	Specific steps to improve

Retrospectives become wonderful data points for tracking a team’s progress. Proactively remind your team members of what was agreed upon in the retrospective, and ask them to show evidence that they’ve followed through on any solutions proposed. Track your retrospectives across time to see whether what was in the “Needs improvement” column eventually moves out or even into the “What worked well” column. If you see that the same items continue to find their way into the “Needs improvement” column, then your solutions either aren’t effective or aren’t being implemented. Create a spreadsheet with different tabs based on the projects completed. Record the results of each project’s retrospective in a separate tab. This allows you to consolidate your retrospectives in a way that makes it easy to review progress.

Save the tracking spreadsheet to a storage space that all staff can access. Another benefit of tracking retrospectives is the opportunity to implement successful improvements across projects. You won’t always have the same team members in every project. You can disseminate your findings to the broader team when you track retrospectives. If a solution to a problem in project A is successful, you could try implementing the same solution if you see the issue pop up in a retrospective for project B. You avoid having to reinvent the wheel this way. Similarly, you can avoid solutions that don’t work for problems that reappear in other projects in the future.

So, you’ve conducted a few retrospectives and seen growth. You can call it quits, right? No. Your team members will change over time. Your projects will change in complexity and purpose. By making project retrospectives a standard part of your practice, you reduce volatility and continue on the path of growth.

Case Study: Using Retrospectives With The Same Team Across One Year Of Projects

I had a unique opportunity to serve as a core member of a team that spent a year working together on various projects. I served as the lead researcher for each project. The lead designer and lead developer also remained consistent for each project. Our usual model for staffing projects does not specify that teams should stay the same, so this was an experiment.

We conducted a retrospective at the end of each project. At the end of the year, we realized that issues we identified as “What didn’t work well” in earlier projects had moved to the “What worked well” column in later projects. We used this information to create a list of best practices.

Our managing director led the retrospectives. She had played an oversight role for all of the projects, so she had a working knowledge of the topics, successes and challenges we faced. The bulk of each retrospective was spent answering the questions:

• What worked well?
• What didn’t work well?
• What specific ways can we improve our future work?

I’m going to focus on real examples of what came up during our retrospectives. For the sake of brevity, I’m going to provide only a few examples. Our actual lists for each question listed above were extensive. I’ve added highlights to track the progression of issues whose status changed over the course of multiple projects. Each highlight color corresponds to a particular issue as it was tracked across retrospectives.

Project A

What worked well?	What didn't work well?	Ways to improve
Client working session at our studio	Research participant recruitment began too late. We relied on the client to recruit participants due to the sensitive nature of their relationship with users.	• Emphasize the importance of clients beginning recruitment ASAP during kickoff meeting. • Draft recruitment email and send to client for use immediately following kickoff meeting.
Research findings integrated seamlessly into design concepts.	Transition to visual design was difficult. Visual design needs were minimal; we waited to identify a visual designer until the project was half-finished.	Look for additional opportunities to have clients visit our studio.
Technology assessment findings and user research findings were presented as separate sections. (Would prefer to have seamless presentation of all research and to have tech assessment themes align with user research themes where possible.)	Technology and research to meet to integrate findings better into final report.

Project A’s retrospective identified a number of things our team had done well. Specifically, we held a client working session at our studio that went very well and that helped to set up a great final presentation. We continued to look for these opportunities as a way to document their importance.

We also identified three specific issues that could have been better executed on:

• We were relying on the client to recruit research participants due to the user types we needed access to. Our client had not begun the process of recruiting participants when the project kicked off. This led to a delay in starting the research according to the initial timeline.
• We limited the involvement of the visual designer until it was absolutely necessary. This was not ideal — the visual designer didn’t have insight into the reasoning for certain design decisions, and getting everyone on the same page took longer, which led to personal frustration for the visual designer assigned to the project.
• Our technology assessment was presented separate from our research findings, which felt disjointed. This aligned with how we traditionally reported these findings. However, we felt we could challenge ourselves to evolve.

Working as a group, we came up with a list of potential ways to improve on these three areas. Our managing director documented the retrospective and preserved our takeaways in a brief report that we were able to access through our shared storage.

Project B

What worked well?	What didn’t work well?	Ways to improve
Client working session at our studio	Research participant recruitment began too late. We relied on the client to recruit participants due to the sensitive nature of their relationship with users.	• Emphasize the importance of clients beginning recruitment in pre-kickoff phone call. • Draft recruitment email and send to client prior to the kickoff meeting.
Seamless transition between all project phases and disciplines.	Technology assessment findings and user research findings were presented together, but themes felt disconnected.	Technology and research teams work together throughout project to ensure alignment on research themes.

Project B’s retrospective identified that we had done a better job of identifying who would be involved from all disciplines from the start of the project. This led to a sense that the project unfolded seamlessly as we went from research to design and then development.

We also realized that we still fell short of completely resolving two of our previous issues:

• We were relying on the client to recruit research participants due to the user types we needed access to. Our client had not begun the process of recruiting participants when the project kicked off. This led to a delay in starting the research according to the initial timeline.

We had attempted to address this issue by coming to the kickoff meeting prepared with some of the critical items that we knew our clients would need in order to recruit participants.

• Technology assessment findings and user research findings were presented together, but the themes felt disconnected.

We improved on this issue between project A and project B, but we didn’t feel we had completely addressed it. The technology assessment findings were presented alongside the user research in the “Research findings” section, yet the themes remained distinct.

Working as a group, we came up with a list of potential ways to improve on these three areas. Our managing director documented the retrospective and preserved our takeaways in a brief report that we were able to access through our shared storage.

Project C

What worked well?	What didn’t work well?	Ways to improve
Client working session at our studio	Staff vacations overlapped key meetings and dates.	• Avoid overlap between team member vacations and key project dates. • Identify potential substitutes ASAP for vacation coverage, preferably at the start of the project or as soon as vacation is known about.
Seamless transition between all project phases and disciplines.	Create and implement guidelines for information shared during pre-kickoff calls, so that future projects benefit.
Pre-kickoff phone call alleviated issues of time with user recruitment.	Continue pre-kickoff calls.
Research, design and technology themes presented seamlessly.	Continue involving technology team in analysis of research from the beginning.

Project C was when our team really started to gel. This also marked six months of working together as a stable core team. We’d had time to learn how each other works and to support each other better. We were able to move both of the issues identified as “not working well” in project B to the “worked well” column in project C.

We had refined our process to the point that we were identifying the minor bumps that can arise over the course of a project as the ones we needed to focus on for improvement in future. We would not have been able to get to this point without conducting retrospectives after each project. Retrospectives enabled us to focus on what we were doing well in order to make sure we kept doing those things. We were also able to identify issues in need of improvement, with specific potential solutions to implement in the next project.

We did not achieve perfection by the end of our year-long experiment. But we did refine our process to the point that we had gotten beyond simply meeting our key performance indicators. We were actively looking for opportunities to implement better solutions; we were able to accomplish more, faster and with fewer resources; and we had developed positive healthy working relationships across the team.

Conclusion

You will find many potential benefits from conducting project retrospectives. You don’t need to invest a lot of time or money in them. There is no one-size-fits-all approach. I’ve given you some of the lessons I’ve learned as both a participant and a facilitator of retrospectives in digital design projects. Feel free to try what you want, and only use what works well for your team and situation.

However, we don’t always have the luxury of working in teams or having team retrospectives. I’ll focus on personal reflection in the second article of this two-part series. I’ll provide examples of written and verbal reflection that practitioners and students can apply to grow both personally and professionally.

Stay tuned!

References

• “Postmortem: Never Leave a Project Without It,” Andreas Birk, Torgeir Dingsøyr, Tor Stålhane, Norwegian University of Science and Technology
• “Project Retrospectives,” PM Notebook
• “Project Retrospectives: Evaluating Project Success, Failure, and Everything in Between,” R. Ryan Nelson, MIS Quarterly Executive
(cc, vf, yk, al, il)