Team up fast and learn even faster 

15 April 2021

🎙️Introduction

Knowing where and when to innovate is precious information. In 2020, we started by setting up a team that would dive right into the innovation pool. They would research, prototype, design and develop all kind of existing and new opportunities and ideas for OSM. At the same time, live teams would keep improving OSM, step by step. With this document, we want to get into the difficulties we encountered, the successes we celebrated and the lessons we learned. 

The game we played as a team outside the 40+ working hour weeks, one year and three months lasting project, was Innersloth’s COVID-19 skyrocketed, extremely fun and enviable mobile monster hit Among Us. To unwind, laugh, cry, yell at each other and most importantly, to cast blame. The latter being the exact opposite of what we’re going to do here.

👨‍💻The team

We started out with 1 product owner, 1 scrum master, 1 game designer, 2 artists and 2 developers. For every role, we had at least one colleague that had at least 4 years of experience with OSM and Gamebasics. The whole team had previously worked together in some form. There was a mix of all your classic office archetypes. Hard-working developers with a healthy emphasis on generic feature set-ups, creative artists pushing for more change, a scrum master with military precision on team rules, a game designer secretly trying to put long-lived user wishes on the agenda and a fatherly product owner trying to keep everything within scope. Besides hard skills, we tried to mix tireless optimists (with the risk of overlooking problems) with critical thinkers (with the risk of uneasy meetings), keeping each other in place.  

Gradually, more team members were added. A meticulous UX lead, a former native developer with a can-do attitude, outside perspectives from an ambitious and curious game artist, a troubleshooter with knowledge of every obscure OSM scenario, a particle magician and eventually a two-man feature team to expand the feature set.

Takeaway: Compose a team of experienced colleagues with mixed soft and hard skills.

⚙️The process

What’s a project without agreeing on basic working rules? A lot of written and unspoken rules were based on a prelim. We went with a responsibility framework that was new at Gamebasics; an empowerment board. This board was designed to capture the areas of responsibility that were needed to build OSM as a team. Advantages were clearly defined responsibilities for team members that were assigned to an area. A disadvantage was that it proved hard to be consistent in to what extent a responsible team member could make a decision.

Making calls that affected the product – which was true for almost every call we made – also required an empathising mindset for team members. It was one of our strengths, decisions were easier to make because they were backed up by the process. Even when team members didn’t agree with the decision itself. What we didn’t always manage to do was really come to terms with the decision, mentally. This sometimes expressed itself by lingering on calls in the past or bottling up frustrations. 

Another big process call we made was starting with pre-production. This meant we set up different generic types of the UI. Things like lists, currencies, timers, alerts and text. Up until this point, there is no consensus within the team whether this helped velocity in the long run. On the one hand there was a clear advantage, being able to reproduce already built UI parts during production. On the other hand, most of the things we made were subject to change over the course of 15 months of work. 

What really sped things up was when we started production with the pipeline we established. Every discipline had its own step in the process, being responsible for presenting it to the rest of the team. Everyone could chip in and features began rolling off the assembly line. It also enabled us to come up with a burndown, estimating complexity relative to other items. Since the project was on a deadline, the burndown helped making choices and communicating with stakeholders. Planning sessions would always be composed of checking presence during the sprint and plotting gatekeeper meetings. 

Takeaway: Define areas of responsibility, install active process milestones to ensure a solid transfer of work for the next discipline and talk about and respect each other’s expertise. 

🤝Working together

The product owner and scrum master made a thing of emphasizing the importance of working together and communicating in general. Besides the obvious game problems we were about to face, there was the complexity of working as a team. Especially during the COVID-19 inflicted lockdown. We reminded each other that working together well would be hard work. We pushed each other to share thoughts, conclusions and even private convo’s in public places. Pleading a case for paid Slack accounts was important in this regard.

But this didn’t always hold up. We stepped into the pitfall of thinking onboarding new colleagues was a walk in the park. In some cases we waited with sharing frustrations, we held grudges, we postponed calling each other, we got defensive and we lost each other in the Slack jungle. But we didn’t lose hope. There was always someone that could see through the heat of the moment and started patching things up. This person rotated in the team, which gave us confidence that everyone saw the upside of eventually resolving these issues.

Takeaway: Be aware that working together well is hard work and write guidelines for new team members.

🐾Devs x artists

One of the initiatives to work effectively was the idea to pair developers and artists up. This meant not only a 1 developer – 1 artist ratio but also a deal to work as a two-(wo)man team. They would work together to deliver assets, customise settings and maintain the same timeline when setting up a feature. For example, one team would do the underlying game logic, the other team would do the UI screens. The key here was to set up a non-developer friendly environment for artists to work in. This resulted in fewer waterfall mechanics – basically waiting on someone to continue – and more ownership. 

More documentation and explanation of the exact settings that could be adjusted by artists is necessary though. Mostly to reduce unintentional changes in Unity. 

Takeaway: Yes, use artist-developer pairing and create non-tech friendly setting panels.

🧪Innovation

One of the big questions on missions like these is to determine to what extent the team will innovate. We got a handful of progressive team members who were thirsty for change. This varied from the desire to implement new mechanics, to new navigational structures, new platforms to new research methods. We started by identifying the largest possible gains and hit the innovation ground running. New navigation, new visualisation of core loop features and new validation methods emerged. We figured the core was the best place to innovate since small changes only had minor effects, earlier tests had taught us.

Validating UI, UX and game design choices was hard but we managed to cover a lot of ground with UX testing, sample testing, representative research and A/B-testing.

Takeaway: Fixing known problems is a no-brainer, back this up with a solid plan to fully validate the changes and actively discuss the extent of innovation.

🖥️UX

Very early in the project, we came to the conclusion we missed UX expertise. We did a lot of UX testing with prototypes at that stage. With UX expertise in the team, we figured we could learn more as individual team members and lift the quality of these tests and validate other assumptions. It also helped with understanding the UX flaws in OSM even better.

What didn’t help was national lockdown. We couldn’t get people to the office to test our prototypes and alpha versions. Working with a remote testing tool was a great alternative and enabled us to continue getting an outside perspective on our work.

While adding new features, we incorporated a UX step in our process to ensure we didn’t miss something in this regard. It also allowed us to create predetermined flows.

Takeaway: A dedicated UX’er helped us make better decisions across the board. Besides that, it’s important to set up cases for management like we did with a testing tool.

🛠️Tech

A big tip in general is deconstructing elements and creating building blocks. Re-use as much as possible. Try to keep it as consistent as possible for a higher velocity. An open communication channel for developers to actively discuss features and their implementation is a must. We used a git branch structure with git folders for organisational purposes. Then there was the quest of making branches more specific. The smaller the pull request, the safer the merge. And of course, unit testing helped improve the quality.

For new developers in the project, starting independently with a small user story and continually growing in size was a good practice.

One of the setbacks was implementing third parties. Partially due to choice and partially due to circumstances, we saved them up and ended up with a lot of unforeseen complexity. This hurt the project estimate a bit and morale a lot. 

Takeaway: Keeping things small, structured and communicating about it – a lot – helped.

📋QA

We started without a dedicated QA’er. Most of the QA we did was by hosting so-called gatekeeper meetings to ensure everything was covered in the process of delivering features: research – prototyping – flow – art – implementation. Features were tested when ready, the whole set was tested once per sprint and internal leagues were played to find bugs. When we got a dedicated QA’er, the QA process was rethought.

What helped was the documentation of requirements per feature. From here, it was easier to define if reports were actually a bug or a new requirement.

Takeaway: Document feature requirements and put a QA process in place from the start.

🎮Game design

Actually changing mechanics of features proved to be more tricky than we realized beforehand. By experimenting we found out that this was high risk versus high potential. 

There were lots of game design questions we had to answer for the features we made. We benefited hugely from the call to document all requirements and the accompanying reasons why. This helped create support for decisions, inside and outside the team. The same goes for validating calls through surveys with users.

Takeaway: Document decisions and reasons why. Get feedback and get it early, even if it’s not representative for your user base. 

🎨Art

At the beginning of the project, our lead artist wrote a vision on how the UI could be visualised. Two of the main points in that vision were a more scalable, intuitive and hierarchical visualisation and a more mature look and feel. 

An important decision was to clean up the base UI. This entailed a more intuitive navigation and limited information on overview pages. We learned a lot about our art by presenting it to end-users but also to a group of internal selected power users. Another good practice was presenting work to team members in order to meet requirements and getting input for out of the box ideas. 

Takeaway: Write a vision to see the bigger picture and use generic UI components to be able to build features that are recognizable for the user.

📖Epilogue

It was one hell of a ride. 15 months of intense developing, designing, prototyping, researching, discussing and calling. We learned a lot from just setting up a team with all necessary disciplines, innovating and validating. We’re eager to bring all the lessons we learned to OSM.

For all OSM players: we will continue to work on OSM with renewed motivation, capacity and ideas. Cheers to new future improvements!