Software Project Retrospectives

At the conclusion of a software development project, a project retrospective is a best practice for process improvement. The retrospective can help identify best practices and anti-patterns, acknowledge effective and not-so-effective practices, and provide a sense of closure or completion for team members.

Before jumping into a retrospective, take some time to think through the motivation for having one:

What are the goals for having a retrospective?

• Improve process / artifacts / quality
• Motivate the team to improve its own processes
• Focus on a specific objective, such as improving communication within the team or between the team and other functional groups
• Better serve the client
• Identify team-wide or department-wide opportunities for improvement

Who will benefit from the retrospective?

• Project management
• Company / department management
• The current development team
• Future maintainers of the same project
• Other development teams in the department

Make sure you have a plan for the deliverable(s) you'll create (memo / report / best practice list)?

Answers to these questions should help frame the questions you ask during the retrospective.

Planning the Retrospective

It is a good idea to pre-generate ideas by sending out questions before the actual meeting and to set ground rules. Like any well-planned meeting, a retrospective should have an agenda: specific questions to be answered, topics to be discussed, actions to be taken, and responsibility to be assigned. The retrospective should not be an undirected discussion.

Also following good meeting practices, someone should lead the retrospective (a facilitator), and someone should be responsible for taking notes and publishing a follow-up. Ideally, the facilitator and note-taker should not be team members, and the facilitator should have experience leading project retrospectives.

Part of a retrospective should be commitment from management to actually do something with the information gathered. Otherwise, we're just wanking.

Be certain to have a plan for the questions you’ll want covered in the retrospective. Phrase the questions so they can’t be answered with "good," or "bad" or "yes/no." Asking "how was team communication" won't generate the same kind of feedback as "describe an instance of effective / ineffective communication between team members." Asking for specific examples forces people to actually think about what they are saying. Anonymous feedback or "on a scale of 1-5" feedback are not useful.

Team and project dynamics are complex; they deserve more than a yes/no answer.

Questions you might want to ask (many ask the same question in different ways):

• What happened on the project that surprised you? What events during the project did you not anticipate?
• In which cases would stronger / different project management have prevented problems?
• What do you know now about the project that you wish you had known earlier? How would this have changed the project?
• How clearly defined was the project life cycle? Was the project life cycle used effectively to driving project deliverables?
• What have you learned from this project? What lessons are you taking away?
• What skills or knowledge turned out to be the most important? What skill gaps did the project encounter?
• What work turned out to be a waste of time?
• How effectively did the team understand and communicate the needs of the customer?
• What aspects of the system were well designed?
• What aspects of the project’s design need to be refactored?
• What aspects of the project’s code/implementation need to be refactored?
• What components should be considered for reuse outside this project?
• How effective were the project’s quality control and assurance activities?
• What is your level of comfort with regard to the product’s quality? What aspects of the system cause you to lose sleep.
• What is your overall impression of the end product (does it fail/meet/exceed the users needs and wants)?
• What one aspect of this project would you change if you could?
• What one aspect of this project would you keep unchanged?
• When did communication between team members on the project work well?
• When did communication between team members on the project break down?
• When did communication between team members and management work well?
• When did communication between team members and management break down?
• If the system is a rewrite of an existing system, what aspects of cutover / migration to the new system went well? Which aspects didn’t?
• Which part of the system are you most proud of?

It is a good idea to "prime the pump" or pre-generate ideas by sending out selected questions before the actual meeting. A pre-meeting memo is also a good place to set ground rules:

Purpose

• Spot gaps in process or implementation
• Look for opportunities for process improvement
• Help everyone better understand the development process

Not The Purpose

• Evaluating individual’s performance
• Lengthy discussion of solutions

Principles

• There is no ownership: anyone can suggest issues / improvements with any aspect of the project
• Mutual respect; choose your words carefully; don’t ever get personal
• Topics covered in the retrospective are for process improvement; the retrospective does not feed into individual employees’ performance ratings.
• Issues must be specific: "I don’t like it" isn’t good enough.
• Identify problems, but don’t try to solve them
• Think through the issues beforehand

During the Retrospective

The facilitator’s role is important. Facilitators must be able to direct the conversation and should have skills to elicit feedback and conversation from the whole team. Project management should prepare the facilitator with specific examples and project situations to help get conversation started. The facilitator should also be able to sense the team dynamic; some teams are very collaborative, outspoken, and confrontational while others will fear "rocking the boat." Different teams require different tactics to start conversation.

Disagreement between team members during the retrospective is OK; it is the facilitator’s job to enforce the ground rules regarding mutual respect.

The note-taker should record enough of the conversation to create a detailed post-retrospective memo. Consider tape recording the meeting. Handing out forms to the participants may encourage them to take notes during the retrospective. The contents of team members’ hand-written notes can often be surprisingly different than the spoken conversation. Be sure to collect the forms after the meeting, though.

After the Retrospective

Hopefully, the retrospective will generate good conversation, some examples of a job well done, and some opportunities for improvement. If well run, a retrospective can also energize team members for their next project.

As soon as possible following the retrospective, the note-taker and facilitator should put together a follow-up memo. The memo should detail the retrospective findings, and should be send to the project team as well as team management.

At that point, management must be responsible for acting on the retrospective findings. At best, if management doesn’t act on the findings, the effort will have been wasted. At worst, the team members will grow cynical and will be less motivated to improve process. Management action need not be sweeping department reorganization; acknowledgement of the findings and a commitment to review process can be sufficient.