Wednesday, October 30, 2013

Conducting Project Retrospective with a Distributed Team

Like many modern software development teams, some of our team members do not work in the same office as we do.  We have the added and common scenario that some of our colleagues work nearly half way around the world, so our morning is, quite literally, their evening.

And, like many modern software development teams, we like to us an Agile process, using a Scrum model with typically a two week sprint.  On the last day of the sprint, we hold a project retrospective, so that the sprint's events are quite fresh in our mind, then we close the sprint and start the next one.

As in so many aspects of team and sprint management, I like the retrospective to be completely democratic; each team member has an equal opportunity to provide comment.  Here's how we do it:

The purpose of the retrospective is process improvement; what can we learn from this and previous sprints so that we can codify successful behavior and modify less-successful behavior?  To focus on learning lessons, ask two questions:

  1. What did we do well in this sprint?
  2. What could we have done better in this sprint?

To get answers, start with question one and go round-robin, with the questioner going last in the sequence, giving every involved team member (pigs only, please) an opportunity either answer the question at hand.  Each person can either provide a new answer to the question or take a pass.  When they take a pass, they typically are not asked to provide any more answers to the question.  Don't be draconian; if someone remembers something in the course of the process, it is better to be inclusive than rigid to a rule.

It runs something like this:

Scrum Master (SM): Person 1 (P1): Do you have something we did well in this sprint?

P1: Yes, We completed some significant new functionality for our users

SM: Thank you.  Person 2 (P2): Do you have something we did well in this sprint?

P2: Yes, We were very responsive in reviewing Pull Requests

And so forth until everyone has taken a pass on the question.  Then move on to question two.

One way to document the answers in a group is to use a document, word processor or presentation, and put one answer on a page.  Put the document on a large screen so everyone can follow along. Then, print out all pages and put them on the wall.  Each person takes a pen, marker, sticker or something similar and makes three votes on the answers to each question.

The votes are then tallied up and the top three answers are documented in some centralized document of Retrospective Summaries.

How then to do this for teams that are geographically disbursed?  We want everyone to follow along with the documentation of the answers so they every team member can agree to the wording used.  We want every team member to be able to vote and we need to tally up the votes.

When facing these challenges for the current team, I first looked at collaborative work spaces that would let us all see the same documents and perhaps collaboratively edit the documents using some kind of tick mark or initials to indicate votes.  These were less than elegant.

Today we use two technologies to conduct our project retrospectives.  First, we use to have the entire team view the screen of the Scrum Master.  The Scrum Master creates a survey on  The survey has two questions, the ones above.  Each question requires exactly 3 answers be selected.  We then go round-robin and document each answer.  Here's what it looks like as we edit a question:

When we have finished the process of gathering the answers, the SM posts the URL of the survey in to the team chat window and pauses  Every team member votes and when all votes have been collected, the SM unpauses and the team reviews the answers.

The top three answers are documented in a centralized document and an executive summary is sent around.  Every other or third sprint we look back at previous answers to see how we're trending.  We look for answers that we have repeated and talk about how we will retain good practices and what we could use to replace less-successful practices.

By retaining our focus on process improvement, we have the opportunity for every team member to have a voice and everyone has had very helpful inputs, that even if not voted, stay in the collective consciousness.

No comments:

Post a Comment