Agile Retrospectives: Make Good Teams Great

Many teams work hard, but they don't have any way to improve. Working harder is great, but you'll gain much more productivity by improving how you work. That's why the end of every sprint agile teams have a retrospective meeting.

Retrospectives have been around since the beginning. After running the agile manifesto, the alliance listed out several core principles. These principles clarified the shorter agile values. One of the principles says that at regular intervals the team should reflect on how to become more effective, then adjust their behavior. So the team should reflect, tune and adjust. In many ways, the retrospective is about the team being agile with their own improvement. They use the same ideas to turn their efforts inward to reflect on how they can be a better team.Typically, the team will meet for 2 hours on the last day of every sprint. 

A retrospective meeting is not an informal gathering. It should be well run, very structured. That's why many teams have a dedicated facilitator. A facilitator is usually someone outside the team. It may be an agile coach or someone who specializes in retrospectives.

Retrospectives depend on many set up details. This is true more than any other Agile event. There's a lot of details that really matter. It matters who attends. It's also important who's not attending. It's important who facilitates your retrospective. It's also extremely important where you have your retrospective. The facilitators should work hard to make sure that everyone feels safe and engaged.

Retrospectives depend on many set up details. This is true more than any other Agile event. There's a lot of details that really matter. It matters who attends. It's also important who's not attending. It's important who facilitates your retrospective.

 Sometimes, a retrospective's misused. Some teams just use the session as a way to vent their frustrations. Other teams just use it as a small get together. They focus on their accomplishments and only bring up a few items that could be improved. After a while, the team starts to lose sight of the intended purpose. That's why some organizations have independent facilitators. Their job is to come in and run the retrospective. They help the team get the most out of the time. Sometimes they're consultants.

Even very agile organizations can't fight the allure of a distributed team. Less expensive overseas labor markets are an easy way to cut costs. Also, many organizations like the ability to reach out and hire global experts. Either way, there's a good chance that your agile team will have at least one offshore developer.

Like many Agile practices, a good retrospective depends on a self-organized team. The team needs to accept responsibility for their improvement. That's why Norm Kerth created a short retrospective mission that he called the Prime Directive. The Prime Directive should be taken very seriously. Don't think of it like the original Star Trek's Prime Directive. The team shouldn't discard this directive whenever it may cause problems. Instead the Prime Directive is a pledge. It's a shared understanding about how to work together. Some facilitators even suggest reading out the directive at the beginning of each retro.

It's a little strange to see a team do this.

Every so often, something will happen which captures everyone's attention. Maybe it will be a big legal decision, an election, or a natural disaster. Afterwards you'll see experts talking on television. People will write articles. People at work will tell their own version of the story. When this happens, you might notice that it seems like no one person can tell the whole story. People only have their piece of the picture. They'll have their perspective of what happened.

A starfish is one type of chart you can use for your retrospective. The diagram shows the team how they can improve. The starfish has five equal sections. Each of these sections is a category. The categories are Keep doing, Less of, More of, Stop doing, and Start doing. The dividing lines look like a starfish. To use the starfish, each person identifies an item they'd like to discuss. One team member might like the way the team holds their standups. In the retrospective, they would create a note called "Having Efficient Daily Standups".

They'd put that activity in the Keep doing section of the starfish.

The starfish diagram is great for open-ended retrospectives. It's a simple chart, and it works well for many teams. It has the benefit of being broad but not too directed. It doesn't limit the team's agenda. Still, there are times when the team needs a little bit more guidance. This is especially true for newer teams. For these teams, it might be better to have a PANCAKE Retrospective. Unfortunately, this retrospective doesn't include a short stack of buttery, fluffy goodness.

 Some organizations don't like the idea of playing retro games. It seems unprofessional. It's different from the traditional corporate image. It's important to show that retrospectives are about creative reflection. It's about coming up with ideas to improve the process. 

Even during a retrospective, teams don't usually spend their time asking the right questions. It makes sense. Most Agile teams are filled with developers and managers. These professionals have spent most of their careers providing answers. They're not usually hired to be inquisitive. If they ask questions, they may even look less qualified. If you search one of the job listing sites, you'll see how most organizations hire teams. Search for words such as expert, solution and experience, then search for words such as curious, inquisitive or learn.

The second search will give you much fewer results. The first search would probably include most of the listings. What this suggests is that teams are not rewarded for being good at questioning. The problem is, without good questions it's very difficult to find real process improvement.

One of the goals in a retrospective is to find ways to improve the process. The starfished almost always has items the team wants to do less of, start doing, or stop doing. Yet identifying the challenge is only the first step. The team still needs to find action items so they can figure out how to make the process better. Fortunately, agile uses some of the same tools as lean manufacturing. Remember, that lean software development is still considered under the agile umbrella. That means that many of the items in the lean tool kit also work for agile.One of the oldest is the 5 Whys Technique. The 5 Whys Technique is used to find the root cause of a process failure.

While we recognize that there are allot of creative, non-repetitive, variable work in agile development projects, many work items, ceremonies, and activities can benefit from systematic, reproducible and standardized tasks test and options that can be captured in customizable checklists prepared and used by empowered agile teams.