Skip to content
Home » Blog Posts » Student software engineering teams need to learn to use retrospectives

Student software engineering teams need to learn to use retrospectives

Pause and think of how you might improve the work you do as a team.

Growing up in the midwest of the US I remember recess in school where we’d talk to friends about what we watched on TV the night before. We had to wait until the following week to find out what happened next. I was always amazed by friends, who could remember the dialogue so much better than I could. These gaps in the storyline provided endless speculation about what was likely to happen too.

After watching movies the discussion would always be about what happened, and who did what. There was no speculation about developing storylines. The opportunity didn’t present itself, except when there would be an intermission in longer movies, which were rare.

Pause so the team can think

Student teams working on software engineering projects are in a similar situation. The teams like to keep going without a pause as in a movie: we can’t stop to talk, there’s stuff happening. We gotta keep going until we finish.

Photo by Ron Bieber on Flickr

The team would do better to put in retrospective meetings to review how they do the work, in the same way that we talked about TV episodes. The team could discuss and compare options that would improve their collaboration and reduce rework, as well as speed up feedback.

Teams need to build this pause into the cadence of their work. Some teams will say they follow a scrum process, but when you ask them about it, they do the review with a client, and then move onto the next sprint. This keeps them focused on the work. The retro might not happen.

A better version would be regular pauses where they consider how they’re doing the work. They can explore options of ideas to try, or decide which parts are working well.

When I discuss this with teams some do realise this is what they were missing. Sometimes they do decide to do more pairing work. I have to keep reminding them of this key step. Without the pause to consider how they do the work, they can’t improve. They do want to improve.

Your next steps

Remind your student teams to pause, so they can see how they might improve.

Tell them to look for one new thing to try in the next sprint. This is the ‘study’ part of the plan-do-study-act cycle, so it’s a small experiment. Try it, if it helps, then keep it. If it doesn’t improve the work, then they can stop doing it, and try something new.

Introduce the weekly episode, compared to bing watching a series, and the opportunities episodic watching provides the viewer.

This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.

The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration.

If you’d like to be notified of future posts, then please sign up for more using the adjacent form, or follow me on LinkedIn

Cookie Consent with Real Cookie Banner