Possibly the most important aspect of an agile process is the
retrospective. A retrospective usually happens in a team meeting,
generally at the end of every agile iteration or sprint. While there are
any number of ways to run retrospectives, the object is to discuss
three questions:
What is working well?
What is not working well?
What should we change?
The first question tends to be the easiest to answer, and it is tempting to just skip it, but that is dangerous. It is every bit as important to celebrate the team's success as it is to grapple with the team's issues and problems. Positive reinforcement is more powerful than negative reinforcement.
The second question also tends to be easy to answer in teams where the members feel safe to discuss work honestly. It is important to surface problems so that the whole team is aware of the current issues and why those issues affect the work.
The third question tends to be hard to answer. There is an entire body of literature devoted to running retrospectives, most of which focuses on dealing with that third question.
Before I suggest any answers, I would like to emphasize that a retrospective is an explicit invitation to change the development process for the whole team. And in fact the whole team should change its process over time, as a direct result of discussion in retrospectives and along the way. If you start doing your agile process "by the book" and a year later you still have the same process in place, you are doing it wrong.
The most effective retrospective change process I ever saw came from Thoughtworks. That was with a (mostly) co-located team. I've adapted the process slightly for a remote team and it works something like this:
The retrospective happens at the end of a sprint in a conference call with everyone attending. One person acts as facilitator (so far just me, but I intend to start recruiting others now that our retrospectives are becoming routine) and shares their desktop open to a wiki page that they edit in real time. I keep the discussion open and the tone light and friendly.
We ask the "what went well?" question and write down what people say in a list. As facilitator, I try to pay attention to who might be more shy, or new to the team or such, and ask them specifically about their experience in the last sprint. On one recent sprint, I specifically asked one person who is notoriously grumpy to name something that went well, and he really came through! I do not "go around the room" or enforce any kind of structure. I find this open format (with some friendly support from the facilitator) over time encourages participation from those who might be less inclined to contribute, whether they're shy, or skeptical, or for whatever other reason not excited about the exercise.
As a result of answering "What is not working well?" the team creates a bullet list of current issues and problems. Say for example the team identifies five problems like:
Problem 1: X is unpleasant
Problem 2: Y is broken
Problem 3: Z is missing
Problem 4: Definitions are vague
Problem 5: Process Q is onerous
Note that while some problems will be persistent over several iterations, other problems will pop up and then go away as they are addressed.
What we did at Thoughtworks was, having created the list of problems, we gave everyone on the team a certain number of votes; say three votes each for the five problems. Everyone on the team could cast their three votes to address whatever problems they felt were most important. One person might cast all three votes for "Problem 3: Z is missing" because they are blocked by the missing Z. Another person might cast one vote for Problem 4, one vote for Problem 5, and one vote for Problem 3, creating now four votes for Problem 3. The problem with the most votes at the end of the exercise is the most important problem affecting the whole team right now.
This is easily done on a whiteboard with a co-located team. For a remote team, my first attempt at a voting process was with a table on the wiki. It didn't work very well. Since then we have been using a plugin for the Confluence wiki called "MultiVote" that almost does what I want but not quite-- it won't allow one person to cast all their votes for a single problem. I'm surprised that more than ten years after I did this on a whiteboard at Thoughtworks, I am unable to find software that does it today. But the existing MultiVote plugin is close enough that it accomplishes what I'm after: to expose the problems that are currently annoying the most people.
When the votes are tallied, the team commits some time to investigating the problem with the highest number of votes. The team does not necessarily solve the problem, but we commit some time to looking for a solution or workaround or somehow to further a solution if a solution is possible at all. At Thoughtworks the biggest problem every iteration would be assigned to a "champion" to lead this, but right now in my current team no one person has any particular responsibility. It still works pretty well.
The problem-identifying and problem-solving activity is repeated for every iteration. And-- this is very important-- at every retrospective, we revisit the the problems from the previous iteration and discuss whether the problems with the most votes have been solved, or have gone away, or if they need to carry over into the current iteration. This looking back is really important. It closes the feedback loop. Otherwise, people would get a sense that they have problems, but nothing is ever done about them. Over time, this proved to be an extremely powerful agent for positive change.
(I usually revisit last iteration's problems between the "what went well?" part and the "what didn't go well?" part, but sometimes I do it at the very end of the retrospective instead.)
It is important to note that this activity is powerful over time. For example, as the only QA person on the team at Thoughtworks, I often had problems that were different than those of the many developers on the team. So I would introduce a problem to the list, I would cast my votes for it, and some other issue would top the list to be addressed. But on the next iteration, if I still had the problem, my problem would begin to affect others on the team, and would gradually gather more votes and be more important.
My favorite example was that this team had an issue creating test data for the application. I flagged it as a problem for myself, but it was not immediately a problem for anyone else. But as our code progressed, more and more developers and others on the team also found a need to create test data, and the problem eventually became the #1 issue for everyone. We assigned various champions to the problem, even eventually a Computer Science Ph.D/ architect/technical project manager, and even he could not solve it. Eventually we solved our test data problem on that team by hiring a whole new developer with this particular area of expertise.
I started this saying "a retrospective usually happens in a team meeting" but I'll end it by saying that change is the essence of agile practice, and we can make changes at any time for any reason. Retrospectives are an important tool to guide change in a productive way, but they are not necessarily the only path to change.
What is working well?
What is not working well?
What should we change?
The first question tends to be the easiest to answer, and it is tempting to just skip it, but that is dangerous. It is every bit as important to celebrate the team's success as it is to grapple with the team's issues and problems. Positive reinforcement is more powerful than negative reinforcement.
The second question also tends to be easy to answer in teams where the members feel safe to discuss work honestly. It is important to surface problems so that the whole team is aware of the current issues and why those issues affect the work.
The third question tends to be hard to answer. There is an entire body of literature devoted to running retrospectives, most of which focuses on dealing with that third question.
Before I suggest any answers, I would like to emphasize that a retrospective is an explicit invitation to change the development process for the whole team. And in fact the whole team should change its process over time, as a direct result of discussion in retrospectives and along the way. If you start doing your agile process "by the book" and a year later you still have the same process in place, you are doing it wrong.
The most effective retrospective change process I ever saw came from Thoughtworks. That was with a (mostly) co-located team. I've adapted the process slightly for a remote team and it works something like this:
The retrospective happens at the end of a sprint in a conference call with everyone attending. One person acts as facilitator (so far just me, but I intend to start recruiting others now that our retrospectives are becoming routine) and shares their desktop open to a wiki page that they edit in real time. I keep the discussion open and the tone light and friendly.
We ask the "what went well?" question and write down what people say in a list. As facilitator, I try to pay attention to who might be more shy, or new to the team or such, and ask them specifically about their experience in the last sprint. On one recent sprint, I specifically asked one person who is notoriously grumpy to name something that went well, and he really came through! I do not "go around the room" or enforce any kind of structure. I find this open format (with some friendly support from the facilitator) over time encourages participation from those who might be less inclined to contribute, whether they're shy, or skeptical, or for whatever other reason not excited about the exercise.
As a result of answering "What is not working well?" the team creates a bullet list of current issues and problems. Say for example the team identifies five problems like:
Problem 1: X is unpleasant
Problem 2: Y is broken
Problem 3: Z is missing
Problem 4: Definitions are vague
Problem 5: Process Q is onerous
Note that while some problems will be persistent over several iterations, other problems will pop up and then go away as they are addressed.
What we did at Thoughtworks was, having created the list of problems, we gave everyone on the team a certain number of votes; say three votes each for the five problems. Everyone on the team could cast their three votes to address whatever problems they felt were most important. One person might cast all three votes for "Problem 3: Z is missing" because they are blocked by the missing Z. Another person might cast one vote for Problem 4, one vote for Problem 5, and one vote for Problem 3, creating now four votes for Problem 3. The problem with the most votes at the end of the exercise is the most important problem affecting the whole team right now.
This is easily done on a whiteboard with a co-located team. For a remote team, my first attempt at a voting process was with a table on the wiki. It didn't work very well. Since then we have been using a plugin for the Confluence wiki called "MultiVote" that almost does what I want but not quite-- it won't allow one person to cast all their votes for a single problem. I'm surprised that more than ten years after I did this on a whiteboard at Thoughtworks, I am unable to find software that does it today. But the existing MultiVote plugin is close enough that it accomplishes what I'm after: to expose the problems that are currently annoying the most people.
When the votes are tallied, the team commits some time to investigating the problem with the highest number of votes. The team does not necessarily solve the problem, but we commit some time to looking for a solution or workaround or somehow to further a solution if a solution is possible at all. At Thoughtworks the biggest problem every iteration would be assigned to a "champion" to lead this, but right now in my current team no one person has any particular responsibility. It still works pretty well.
The problem-identifying and problem-solving activity is repeated for every iteration. And-- this is very important-- at every retrospective, we revisit the the problems from the previous iteration and discuss whether the problems with the most votes have been solved, or have gone away, or if they need to carry over into the current iteration. This looking back is really important. It closes the feedback loop. Otherwise, people would get a sense that they have problems, but nothing is ever done about them. Over time, this proved to be an extremely powerful agent for positive change.
(I usually revisit last iteration's problems between the "what went well?" part and the "what didn't go well?" part, but sometimes I do it at the very end of the retrospective instead.)
It is important to note that this activity is powerful over time. For example, as the only QA person on the team at Thoughtworks, I often had problems that were different than those of the many developers on the team. So I would introduce a problem to the list, I would cast my votes for it, and some other issue would top the list to be addressed. But on the next iteration, if I still had the problem, my problem would begin to affect others on the team, and would gradually gather more votes and be more important.
My favorite example was that this team had an issue creating test data for the application. I flagged it as a problem for myself, but it was not immediately a problem for anyone else. But as our code progressed, more and more developers and others on the team also found a need to create test data, and the problem eventually became the #1 issue for everyone. We assigned various champions to the problem, even eventually a Computer Science Ph.D/ architect/technical project manager, and even he could not solve it. Eventually we solved our test data problem on that team by hiring a whole new developer with this particular area of expertise.
I started this saying "a retrospective usually happens in a team meeting" but I'll end it by saying that change is the essence of agile practice, and we can make changes at any time for any reason. Retrospectives are an important tool to guide change in a productive way, but they are not necessarily the only path to change.