A retrospective is defined as “looking back on or dealing with past events or situations”. In the case of game development, it’s looking back on a set of work as a team and defining what you felt went right, what went wrong, and what could have gone better.
These are powerful tools to a Producer and I believe are under used in some studios. By doing these retrospectives more regularly I believe issues can be raised for the Producer to take ownership of and resolve, resulting in a better environment, process and happier people.
How I run retrospectives:
I run a retrospective at the end of every sprint, that’s every two weeks for the studios I’ve worked in. The goal is to take small problems that can be fixed quickly, versus waiting until the end of a project to have multiple large or hundreds of small issues that may not be fixable in time for a new project kick off.
My preferred retrospective format is to ask everyone to think of three categories:
Start – What do we want to start doing?
Stop – What do we need to stop doing?
Keep – What do we need to keep doing?
In this retrospective I ask everyone, including myself, to write down thoughts for each of these three areas. I try and put the Start/Stop/Keep onto a white board or as post it notes on a wall, so people can physically add their feedback, allowing them to give an explanation if required.
At the end of a retrospective all the actionable items are added to a retrospective backlog, in a Kanban style board. I then ask the team to prioritize these, which helps me focus on the most critical issues as thought of by the team. We also then review past items I have worked on and believe are now ‘better’. The team can sign off this item, agreeing with me that it is fixed, or they can give feedback that it needs more work, and it goes into an appropriate place on the backlog (as voted by the team).
The key reason I believe in regular and frequent retrospectives is the retrospective backlog. A living place where we track what needs done to improve how we work, either internal to the team, or on the project, or as a studio. By having a physical place that these items can be seen, and having the team prioritize and sign off if they’re done, I believe it shows a key willingness to improve and to take issues seriously, no matter the size.
In addition, I believe overtime it leads to more open communication as well as removing any fear of suggesting change, by encouraging frequent feedback and showing action, thus the team members know this list won’t end up in an email, confluence or wiki somewhere, forgotten and lost.
Producers, hold yourself accountable to improving how the team works, feels and delivers, take on their feedback frequently and not just as a token task at the end of a project.
Retrospectives are powerful, use them, often.
If you have any suggestions, disagreements or comments, let me know in the comments below or find me on Twitter: @RetroCrumpet