Why We Have Meetings Where We Look Back, Evaluate and Focus
We consider communication as a primary element in making us better at what we do. We focus on enabling communication flow inside and between teams with different kinds of habits and roles. One of the most important habits that our teams have for weekly and monthly communication, syncing up and reality checks are retrospectives.
Retrospectives are connected to our weekly sprints and the longer, 3-6 week stretches. It’s important that after each sprint and stretch we have an opportunity to look at what we set out to accomplish, if we were able to meet the goals we set, what was getting on our way, and if the product still looks like we imagined a week or a month before.
To understand the need for retrospectives, we first need to dig a little deeper into our production ideology, which has many things borrowed from the Scrum method, combined with our focus on KPI driven development. We understand that we are making our games for our players, not for ourselves. To make the games that our players want, we need to rely on market research, early feedback, testing and data to guide our game making process. To get early feedback and test results, we need to get our games out there as early as possible, and actively iterate and update them. We are also prepared to react quickly to the feedback and data that we collect to incorporate it in our products and keep the iteration process going.
These lean and quick iteration cycles need certain things to support them: We need to be objective towards and open to data and feedback we get about our products, have the skills to swiftly adapt our approach based on the input we get, have a plan that is not too rigid and can be changed easily, and have ways of clearing hindrances away. Great communication is the key to all of these things, and without it there is a real risk of losing focus while receiving loads of information from different sources.
The Structure of a Retro
Our teams have organised their work based on weekly sprints with the goal of making something that the team can test, and longer stretches that aim for releasing a build in the store or for internal playing for the whole company. After each sprint and stretch we have a retrospective where we ask ourselves how can we work better together. What was getting on our way? What things are slowing us down or hindering our progress? We focus on discussing the different ways we work and interact with each other, trying to reach even better co-operation in the upcoming new sprints. This means we dive honestly into the inter and intra personal topics as well. Anything that can hinder us from making amazing games together should be brought up and handled.
All retros start with the same basic assumption: That we are all on the same side, trying to make amazing games together. To remind ourselves of this common goal, we start every retro with the prime directive introduced by Norman Kerth in his book Project Retrospectives: A Handbook for Team Reviews. It goes like this:
“Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”
This is a great message that keeps us focused on finding solutions together.
There are two types or retros. The weekly retros give us immediate feedback on how things went this week. The weekly retros help us keep the ball rolling from one sprint to another and to keep the team in sync with each other. The focus is very much on present: What happens right now and what is hindering right now? Some of the topics discussed might relate to for example to how we had not taken the dependencies and synchrony of different tasks into account, thus making them harder to execute or follow through; Or that the flow of work got disrupted due to insufficient communication with team members or other stake holders in the face of unforeseen circumstances. The goal is to figure out how we can work better next week to avoid the challenges we faced this week and to direct the teams focus on things that they succeeded in, strengthening those emergent, beneficial habits and building on them for even better collaboration.
The second type of retro we hold after longer stretches, after we have finished our deliverables, wether they are a build, game vision, marketing materials or something else, and shared it for internal or external evaluation. These retros are for identifying things that happened over a longer period of time: defusing the stress that might have built up during the stretch and celebrating the successes we have experienced. Our aim is to improve our future processes, and to review what we have built. Did we achieve everything we aimed for in the beginning of the stretch? How does the product feel right now? Are we on track? What challenges did we overcome during the stretch? Did we fail to identify or tackle some challenges during sprints? How does the team feel right now? What are the successes that we want to carry on to the next stretch?
Benefits of Having Retros
In short, the retros are meetings where we have the chance to talk about things we have on our mind, and to keep ourselves and the whole team in sync with the reality. We think it’s important to have designated slots for discussion in addition to discussions that will happen organically throughout the development. Both forms of communication have a clear function in a well honed team. Daily discussions keep the team members on the pulse of what is happening. However, the team members want save the bigger issues for a dedicated discussion to keep the ball rolling during the weekdays, and to give room for the more quiet members of the team to speak up as well. This is exactly what retros are: A recurring meeting, where everyone is expected to pipe in; A habit of syncing and coordinating the team work in a transparent, non-intrusive and inclusive way.
In retros we stop and ask ourselves if we are focusing on the right things:
Are we achieving our Sprint and Stretch goals? Are our goals realistic?
Are we doing the things that make our product better (according to data and feedback)?
Are we making a product that our players want?
Do we have a synchronised, coherent and realistic picture of the production and the situation at hand?
Are we adapting to data and feedback we get?
What are we succeeding in that we want to focus in the future as well?
Through retros we are able to synchronise our understanding of how we work right now, and together create ways to optimise our collaboration and communication both short and long term.