Your team has been heads down in a project, crafting the most meaningful experience ever for your clients, and you finally pop up for air. All that work was great, but how could your team have been more efficient? What are some roadblocks that you want to avoid in the future to make the process smoother?

The answer to these—and many more questions like this—lies in a retrospective.

The primary objective of a retrospective is to field honest feedback from everyone on your team. This feedback will boost your team’s performance and make your time working together even more effective.

At Digital Telepathy (DT), we run retrospectives, or retros for short, on multiple occasions throughout the course of a project. On some teams, retros are just part of our standard cycle, running them every four weeks (or sprint). On other teams, we get together for a retro after completing certain phases (e.g. moving from wireframes to design). Heck, we even run retros with our clients during (or after) onsite visits. Client involvement can be tough to schedule, but, man, does it do wonders for your relationship and project alignment moving forward.

While the cadence of retrospectives varies between accounts, we use the same flexible framework to improve communication and productivity among our team, and with our clients. This approach gives everyone an equal opportunity to contribute ideas for how to improve team performance. It also prevents issues from being swept under the rug.

Before you do anything, find a moderator. This is normally a non-project member who is able to objectively control the discussion in the room, group similar pieces of feedback together, and take notes on the fly.

Once you’ve determined a moderator, you’re ready to get started.

Step 1: WRITE

Retrospectives work best when everyone is in the same room. You’ll need a conference table, a whiteboard, and packs of Post-It notes and markers for each participant. Set a timer for 7 minutes (there’s no magic to 7…but it’s not too long, not too short), and have the team write down as many ideas as possible for the following three questions:

  1. What should we start doing on this project?
  2. What should we stop doing on this project?
  3. What should we continue doing on this project?

These “betterment” ideas can be anything (we’ve had things, such as, “Start hiring a barista while the client is onsite” and “Continue having group live demos”). This is a great opportunity to raise awareness about team issues, or to call-out unheralded wins by team members.

After 7 minutes is up, each participant will add their Post-Its into the columns labeled “Start,” “Stop,” and “Continue” on the whiteboard. You can probably see already how surfacing this information will help improve the performance of your team.


Now for the fun part! Let’s see what everyone wrote, and figure out where ideas overlapped.

With all of the ideas  on the whiteboard, the moderator will read each one aloud, and the team discusses that specific card (this is where a 3rd-party moderator helps… sometimes discussions get heated!).

For our regularly scheduled retrospectives, we normally reconcile each column for about 10 minutes, and end up with 2-4 themes. Of course, your needs may be slightly different depending on the size of your team or a number of other factors.

After reading a few cards, the moderator should begin grouping cards into similar themes. We’ve had a bunch of themes like “Client Experience” (more planned activities, defined daily objectives, etc.), “Work Session” (clearer agendas, increase developer involvement early),” and “Team Awareness” (maximizing our strengths, being more efficient).

Using Google Docs helps organize your notes and keeps accountability at the forefront.

After themes are determined, the team can decide who will be responsible for any immediate next steps, if there are any. Then the moderator will snap a picture, and write up the notes (we use Google Docs) after the retro ends.

But before the group breaks, there’s one more important step…

Step 3: REVIEW

The last step to using a retrospective to improve your team’s performance is to review the notes from last time.

Fire-up your previous notes, and run through each item that you previously wanted to start, stop or continue. This adds a level of accountability and ownership for everyone on the project. We add a comment to the item in Google Docs mentioning if we actually did what we were supposed to do.

In general, a good sign of progress is when you actually started the things you wanted to, and they show up on Continue the next time.

It should be noted that there’s no such thing as a perfect project retrospective. Each team is a little bit different, but the framework mentioned above will provide you with flexibility to experiment with what generates the most honest feedback and makes a lasting impact on your team’s performance.

What do you think? How have you run project retros in the past?

  • Great description of a retrospective Brian. I introduced something similar in a large consulting firm many moons ago and this structure is great.

    Couple of add-on tips for people not used to doing this:

    Some people resist doing this because it generates too many actions ‘on top of’ getting the project done. At a philosophical level retros make it more likely you will get the project done well, but at a tactical level you can get over that by using sticky dots to let everyone vote for which 3-5 items get actioned this month i.e. you don’t have to action every single Post It.

    And when the discussions get ‘heated’, as well as a moderator or facilitator, it’s useful to give everyone the discipline of turning their resistance to an idea into a question e.g. instead of just saying “we can’t afford it!”, which is an opinion which dares people to agree/disagree, it’s much more useful to ask something like “how could we adapt this idea to find a version we could do for less than $100?”.

    • Brian Bimschleger


      Awesome points.

      The dot method works wonders, as you’ve noted. I’ve used it before in Lean Coffee formats (leancoffee dot org), and it focuses the group on a specific set of items.

      Your second point is so important for the team to wrap their collective brains around. Retros aren’t simply about listing issues, but also around inventing solutions to those issues. Your framing of “how could we…” is a terrific way to get the team thinking about this.

  • Frank Sack

    Very helpful, thank you Brian.

    • Brian Bimschleger


      No problem at all…if you decide to test this out in your company, let me know how it goes. Each team operates a little different, so I’d be curious to see how it works for you.

  • Megan W.

    I like that you call them “retros” vs “post-mortems.” There’s something inherently dark about the latter. Nice write up!

    • Brian Bimschleger


      Glad you liked it. By making it less negative, people tend to be more willing to participate, as well. Let me know if you guys run something similar at Huge.

  • I am missing one important step: Take Action!

    My view is that reviewing is not enough, the team needs to decide what to do differently in the future, and assure that that gets done.

    • Brian Bimschleger


      You’re absolutely correct. In the retros that we’ve run, we’ve been fortunate where many of the items that require action are showing up in “Start” the first time through.

      What would be your thoughts on reviewing a previous retro first, to help identify items that need action?

      • I start with making the results of the current retrospective actionable. If I’m facilitation a retrospective I will make sure that the team leaves the room with things that they will do in the next iteration. Preferable those actions are added to the status board and/or to the backlog, so that they are not forgotten.

        When coaching team I help them by reminding them and pulling in actions during the iteration. E.g. at the stand-up, when I’m talking with team members, when they are reviewing things, whatever occasion. I also coach Scrum masters on being aware of the actions that they agreed to do, and look for opportunities during the iteration to do them.

        You can read more about how I do retrospectives, and help teams to do them, at

        I usually start a retrospective meeting by looking at the actions from the previous meeting, to see if they are finished. If they are not (and I urge teams to define actions that can be done in an iteration) I will ask them what is causing them to be unfinished. Sometimes there are simply to much actions (where I suggest to do an exercise to come to the vital few actions, see, or there might be deeper reasons why teams are not able to improve (in which case I suggest to do a Root Cause Analysis to deal with that, see

        I hope this provides some ideas on how to get actions that ar doable, and to get them done.

        Ben Linders
        Co-author Getting Value out of Agile Retrospectives

        • Brian Bimschleger


          Awesome. The part about asking the team WHY they cannot complete the actions is great. Perfectly combined with the toot-cause analysis.

  • Very helpful information.Nice Sharing information.