Auxilium: Postmortem

Auxilium is a 4v4 capture the flag game made using the Unreal Engine. It was developed by student developers over the course of a semester for the curriculum of SMU Guildhall. The team consisted of around 50 team members split across art, level design, programming, and production. The team was organized into four sub teams in charge of delivering a single level of the game, and a small team of project leads. On this project I held the role of co-producer. The following information was collected from a 360 postmortem at the Guildhall.

What went well

Takeaway:

For context, Auxilium was a student project. Up to this point, each of us had only developed a game on a team of four to five developers. Moving to a team size of around 50 was extremely challenging for obvious reasons. We knew that many things could and would go wrong, so myself and the other producers worked hard to maintain high morale. The team worked late shifts twice a week, so I held a barbeque every week before our late shift. The team spent time together and focused on something other than the game. We also added fun elements to the work day. For instance, one of the other producers would blow a conch horn (with varying success) to signify the beginning and end of a core hour session. We also held show and tells at the end of each day for developers to show off their work to the rest of their team. Morale stayed higher than expected considering the problems that arose from a larger team. Through the difficulties, we shipped a game we were proud of, and we believe the bonding elements we injected into the process helped us reach our goals in the face of adversity.

What went wrong

Takeaway:

Our biggest pitfall was our lack of agile fundamentals. This was apparent in our poor scrum hygiene, lack of a product backlog, and incomplete sprint planning. In the beginning of the project we became so distracted with the most immediate issues on our team that we forgot our agile training. The problem was across the whole team, as nobody realized until far too late in the project that we were not performing some of the agile fundamentals. The lack of a product backlog was due to an undefined direction to the game, and made our sprint planning much more difficult as we had to start our planning from scratch every sprint. When our sprint plans became rushed and incomplete, that had an effect on the scrum meetings as some people were unsure what they were doing day-to-day. All of these problems served to slow down our development cycle and prevented us from making something stellar, but provided us with excellent learning opportunities.

What we learned

Takeaway:

“Trust but verify” is a phrase we learned to echo at the end of Auxilium. Simply, it means that it is okay to trust that someone else is doing something, but it is your responsibility to follow up with them and make sure everyone is on the same page. If we had followed this thought process from the beginning, we would have caught several of our classic software development mistakes before they derailed our project. Two instances where this would have been helpful would be with understanding the roles of the individual on each of our sub-teams. Throughout the project there were people that thought someone else was working on a task when they were not. Following up with the person would have alleviated that problem on the spot. Additionally, we had a miscommunication with the stakeholders about the definition of our proof of concept: technology milestone. We thought we were expected to research solutions to risks, but were informed in a regrettable milestone presentation that we were supposed to be mitigating those risks and delivering solutions. Our milestone could have been saved if we had verified our assumptions with the stakeholders at the beginning of the sprint. This goes to show the power that "trust but verify" holds in a game development context, and it would be one of the most important lessons we would learn from Auxilium.