Start with Trust, Start with a Retrospective

July 23, 2008 by Peter Stevens

Taking over responsibility for a troubled project is always a delicate situation. Something was not working as it should. There is a group of people in place, who may or may not 1) be working as a team, 2) have the necessary skills and a positive attitude, or 3) be willing to accept change. So how do you, the new project manager, get the team back on track quickly?

We all have our stories about arrogant consultants and managers who a) don't know the business, b) reorganize everything regardless of the consequences, c) quickly move on or get promoted, and d) leave the team to clean up the mess. A certain skepticism is not only to be expected, it is healthy. So the top priority is to win the support and respect of the team. A close second is getting the team working on improving the situation.

Scrum teaches a wonderful tool: the Retrospective, which is normally performed at the end of each Sprint. At the start of a project rescue, I like to use a Retrospective to get to know the team, identify short term action items, earn the trust of the team, and plant the seeds for transitioning to Scrum (while focusing on what the project needs, not on methodology).

Scrum implements Deming's Plan-Do-Check-Act Cycle and repeats the process at least once per month. I prefer to call it "Plan, Do, Review and Improve" because that's a better description of what actually happens. So for a challenged project, starting with the Improve step is actually quite a logical thing to do.

The Retrospective normally addresses 5 questions:

• What happened?
• What did we do well?
• What could be improved?
• Who has jurisdiction?
• What is top priority?

In general, everybody who is directly involved in the project should be present, but no more than 15 people or so.

The result is two prioritized lists of action items to improve productivity in the project. The first list contains actions that the team can perform on its own authority. Items from second list require agreement from somebody 'outside', e.g. Management, the Customer, another department, whatever.

Why do a Retrospective?

By asking what happened, you build a common understanding of the project -- a common culture actually. Just getting people together at one table, giving them a chance to talk, and have them listen to each other goes a long way towards reducing emotional conflicts. You also send a message that what everyone has to say is important.

By asking what the team is doing well, you eliminate the risk of "throwing the baby out with the bath". You give everyone a pat on the back. You send the message that you understand that people are working for the good of the project and make clear that that is what people should be doing! They will respond and work better just because of the feedback and respect they are getting from you.

Furthermore, you have an opportunity to ask questions. "I would have expected pre-release testing would be high on the list of thing we do well. What testing do we do before delivering the software?" Either people will have a good answer or they are primed to make a good suggestion. By asking the right questions, you can drive the improvement process in the direction you want.

By asking the team how to improve, you get a list of short and medium term action items which will make visible improvements in the state of the project. Furthermore, the team owns the list, even the items you slipped in through clever questioning. So they will stand behind that list and help implement it.

By determining who has jurisdiction, you determine which items the team can action itself and for which items help or negotiations are needed. For the ideas under you team's control, they can start right away with the item at the first item on the list. For the rest, you start with the team's top priority request and work to get it approved.

Introducing code reviews might be an item on the first list: two developers get together and discuss their code. No one really has to even know, much less give their blessing. So just do it! Items on the second list may be difficult to get approved, and the chance of approval might play a role in assigning the priority. For example, you team might request a new build server. If you don't have the budget available, you would take responsibility for making it happen, and the team will love you when you are successful.

Some managers may be afraid that the team will come up with frivolous requests ("The whole team needs a fact-finding trip to Malta!?!"), but by prioritizing, you focus on what's really important. ("Yes it really does, and here is why..."). This is also why it is useful to have management present, so they appreciate the validity of the process.

The team may have enough ideas to keep them busy for the next two or three months, so you will probably need to focus on just a few items so that the team can continue to do productive work. Less important items can be postponed to the next retrospective.

Last but not least -- do it!

The consequence of every retrospective should be at least one concrete result — a list of things to do is nice, but you need actual results. When the team gets to do the things they've asked to do, that's positive reinforcement. When you make their top priority joint-responsibility request happen, you earn their trust and respect, which makes your life and theirs much easier.

But - If you don't allow them to do the things they identified, disillusionment can rapidly set in. So by the time you get to the next retrospective, you should have implemented (or least in the process of implementing) one or two of the top points from each list. Better to get one item done than to have 5 items in progress.

Results

My experience is that the team always identifies genuine potential for improvement (no one has suggested a trip to Malta yet). The top issues that arise out of that first retrospective are mostly organizational in nature and are easily addressed by introducing Scrum. This is the time to start talking to the team about Scrum and how it well help them solve their problems.

In the last year, I've been in involved in three rescues. Two were successful, one was not. In the latter case, the team identified much potential for improvement (some of it quite trivial to implement) but was not allowed to implement any of the changes they suggested, so the effort was stymied. Three months later, the project "hit the rocks," exactly as predicted during the retrospective.

One rescue, although successful, was started without a retrospective. The team reacted negatively and, despite objectively successful results, it was not until most of the old team members had moved on and been replaced with fresh blood that the mood turned positive.

The most successful rescue was started with a Retrospective. The team had the authority to implement most of the desired changes, so motivation, productivity and quality improved quickly and dramatically. Most of the issues raised by the team were addressed by Scrum or the tools we wanted to use, so acceptance of both was high from the beginning and there was no significant resistance to the changes in methodology.

How do you make the changes stick?

You won't change the world in one meeting. Emotional issues don't disappear in an afternoon. I remember one retrospective (between 2 "cooperating" companies) where the only agreement from the first retrospective was to have another one a month later. The trick is to make small improvements regularly. Emotional issues are often not "resolved" but simply dissolve over time. So repetition is important, especially when emotions are involved.

In an agile context, you would do a retrospective after every Sprint, i.e. once every two or three weeks. Even if you are not using Scrum or XP, retrospectives should take place a regular intervals no more than a few weeks apart. In any case, the top improvement on each list should be implemented (or at least under way) by the next retrospective.

Further Reading

There are many right ways and few wrong ways to hold the meeting. I like variations on Boris Gloger's Heartbeat Retrospectives. I plan to go into more detail about the retrospective meeting itself in a later article.

An understanding of Lean Principles and XP practices will help you ask good questions to the team. For a discussion of difficult project situations and the role of the retrospective, check out Saving Projects in Crisis on my blog.

Permalink