Debriefing Development Teams

When you are married to an intensive care nurse you get no sympathy when you don’t feel well. On the plus side you do get to talk about interesting things.

One such thing we were discussing recently was how medical teams do debriefing and give feedback to each other.

Whilst web development is in no way in the same ballpark as nursing, I was interested enough in the techniques we were discussing that Elaine recommended I check out some articles on the subject.

The first article I read was “Debriefing Medical Teams: 12 Evidence-Based Best Practices and Tips” (from the Allegheny Health Network but is no longer available online).

These are all medical related best practices, but all but one of the 12 tips was relatable to giving good feedback to developers, especially when something has gone wrong.

Debriefing Development Teams: 11 Best Practices and Tips I borrowed from an article

I am honouring the order of the tips listed in the article, I am also going to use the word debrief in the title as per the article although I see them more as feedback sessions.

1. Debriefs should be diagnostic and either be recurring or after a critical incident

Feedback from these debriefs should be diagnostic, it should focus on looking at the actual things that happened. This could be something like committing back code, pushing code without test cases, etc.

If regular feedback is something you think the team would enjoy this should be recurring and a date in everyone’s calendar.

If after a critical incident (in the journals case this would be someone dying, in our case lets say it is some unscheduled downtime!) this should be done soon after the incident, see point 10.

2. You need a supportive Learning Environment for these debriefs

Feedback to share with your team, especially after something has went wrong needs to be done within the context of self and team improvement and not as something accusatory.

The premise should always be one of continual improvement, not calling out mistakes for the sake of it.

Instead of telling someone off for not writing a test that would have caught an issue in production, you would observe what has happened and offer up suggestions on how the person could test in the future, sharing resources were appropriate.

3. Team leaders need to be educated on how to do debriefs

The people leading these feedback sessions need to dedicate some time into learning the best ways to conduct themselves. If they go into something like this unprepared for what they want out of it no one will benefit.

4. Team members should always feel comfortable

This echoes point 2, at all times members of the team should feel comfortable. The culture needs to be right in order for these feedback sessions to be effective.

5. Focus on a handful of specific issues per debrief

A feedback session should focus on one or two specific issues. These should be issues that were observed (lack of tests, pushing without peer sign-off, etc).

The sessions should not be seen as a free-for-all to talk about anything and everything related to the project.

6. Specific interactions should be called out

These feedback sessions will not produce useful results unless specific things that actually happened get called out. Dealing in generalities do not help people.

7. Specific support feedback should be given

Like the fact that specific interactions should be called out, specific support feedback should be given.

This means that you shouldn’t tell someone to “learn rspec” you should point someone in the direction of a specific article that would address the exact problem they faced.

8. Outcome feedback is less important than process feedback

I think this is the most important point.

Outcome feedback is feedback on what actually happened (the site went down because of a syntax error that crept into production code).

Process feedback is feedback on the process that led to the outcome (the test suite wasn’t updated to reflect the new functionality that was built, so certain parts of the code were not executed).

Outcome feedback can be important to illustrate a point, but the real learning in any feedback session can be found in looking at what processes were or were not followed.

Changing a process is a harder undertaking but is more sustainable and helps a greater amount of people.

9. Know when to do individual feedback verses group feedback

Sometimes there is something that will benefit the entire team, sometimes one person who should know better did something stupid.

In the case of one person doing something they shouldn’t have it might not be the best idea to give this feedback in a group setting, as per points 2 and 4 it goes against the session being supportive and comfortable.

10. Short times between the event and feedback

If the feedback meetings are a result of a critical event, for example downtime then the time between the thing happening and the meeting should be as short as possible.

Whilst version control commits will stay about forever, memories fade and specific things said or done will become hazy.

11. Record conclusions made and goals set

In order for something like a feedback meeting to have lasting value there needs to be a record of goals set and conclusions made, this holds people accountable and makes sure that people are improving.

The conclusions will also help if management want to ask why the site was down or why a certain project was delivered with bugs.