Eira: Echoes of Adventure is by far the biggest project I have ever worked on. Both the team size and development length were double that of anything I’d worked on before. However it has also had more serious impediments than any project I’ve worked on prior. From family emergencies to a global pandemic, it seemed as though God himself was afraid of our success. In this post-mortem, I will reflect on my team's performance and my individual performance to see how we can improve. When I joined No Scope studios, Eira was already halfway through its development cycle. The game was exiting pre-production and expanding its team. Eleven people (including myself) joined the team bringing the total number of team members up to sixteen. This scale-up presented several issues, the foremost of which was the logistics of organizing such a large team. Many of the team’s methods were deemed obsolete as they did not work on larger teams. To combat this we put in place two systems. The first of these systems was to make one person from each discipline a lead. These leads were responsible for organizing and reviewing the work done by others in their discipline. This system helped to ensure that all work done was quality, and helped us move closer to our goal. It allowed for clear communication as each team member had a person they could The second of these systems was less successful. Up until the expansion, the team had been using a framework called “Scrum” to organize their work. However, that system only works effectively on team sizes of five to nine people. To continue using this framework it was decided that two sub-teams would be made. These teams were multi-disciplined and focused on game systems and game content respectively. These teams would conduct stand up, plan work, and meet individually. The only time these teams would interact with each other was during the weekly team meeting. This lead to a disconnect between the two teams, as communication between them, was largely nonexistent. This was perpetuated by the poor distribution of members between the two teams. All the programmers were on the systems team, while all but one of both the artists and designers were on the content team. Also, except for programmers, all discipline leads were on the content team. These issues dramatically impeded the quality and speed of cross-discipline communication. This was especially problematic between designers and programmers. There were many times when the systems team had questions for the design team that couldn't be answered over text. During these instances, it would often take many days to meet with the content team and get an answer. It became clear that this system was not working To solve this, we switched over to a discipline-based system. The teams were dissolved and standups, work planning, and meetings were now role-based (with the producers observing). Each week, disciplines would meet individually, in addition to meeting one on one with each other discipline. Team meetings were held twice a week to further encourage communication. This not only streamlined communication but helped to make full team meetings more efficient. What I learned from this is the importance of interdisciplinary communication. Each part of the team is only one piece of the puzzle, and to see the full vision, they all have to communicate. Going into my career what I will constantly strive to increase the quality of my communication with each discipline. I will strive to make sure that my explanations are clear and that I ask questions on issues I am unsure of. This will help to not only open up the communication channel but also to improve my understanding of the project’s vision. While handling this expansion proved a big issue, it was not the biggest problem that we had to face. That would be the global health crisis. Midway through our development, COVID-19 was declared a global pandemic. This prompted many governments and businesses to take action to prevent the spread. No Scope Studios was no exception. At the time of the pandemic, our studio was already in the middle of a one-week shutdown. This was extended to two weeks, as we began making preparations to move all team members onto remote work. It was our goal to make sure that all team members were safe and had access to necessary equipment. We then began a period of remote work that would last for the rest of the project. Our role-based system adapted relatively well to the new style of remote work. There were minor issues occasionally, but we were able to continue without much change in terms of scheduling. That being said, none of us had worked remotely for an extended period before. It was clear that this new style would cause a dip in our productivity. As such, we decided to scale down the scope of the project by cutting various pieces of content. Most notable of these cuts, were our second level and all of the game’s narrative interactions. These cuts, while tough, were necessary to produce a polished final project. Not only was our productivity down, but we had also unexpectedly lost a week in preparation for remote work. Our ship date was immovable and was quickly approaching. Because of these issues, it was clear we would no longer be able to produce a polished product without altering scope. Cutting these features allowed us to better provide a polished and complete experience. This whole experience reinforced the idea that cuts latter in development are sometimes necessary. While it is never pleasant, failing to do so can lead to the death of a project. Because of poor planning or impediments, the scope of a project can grow beyond what is reasonable. Removing features can sometimes save a project and make the final experience more polished and complete. On a personal level, I faced several challenges during this project. One of these issues was having to leave town due to a family emergency. This occurred mid-sprint, without warning, and caused me to be unable to work on the project for several days. As our sprints were only one week long, this had a chance to drastically alter the sprint plan. It was my goal to minimize the impact that this would have on my team while making sure I was able to deal with this issue. I first contacted the team’s design lead and producers. I updated them on the situation and explained how it would affect my work. Then, after getting to my destination, I reviewed the sprint plan to see if anyone had listed my tasks as dependencies. Had there been any, I would have then contacted that person and worked with them and my department lead to minimize the impact my absence would have. Thankfully this was unnecessary as no one had listed my work as a dependency for this sprint. Because I took the necessary steps, my absence made a minimal impact on the overall sprint. My team was informed of my absence and was aware that I would most likely not be able to complete all my work for the sprint. This enabled me to maintain the team’s trust and for them to plan their work accordingly. This experience helped cement the importance of team trust in my mind. Had I not trusted my team (or felt they did not trust me) I would have been hesitant to inform them of this impediment. However, because I trusted them I informed all affected parties immediately. Because of this, we were able to work together to plan around this impediment and I was able to preserve the trust my team had in me. Previously in this paper, I discussed the global pandemic and my team's response to it. However, the pandemic also affected my work on a personal level and caused me to change my workflow. I would like to now talk about how the pandemic affected my work and how I reacted to it. When the switch to remote work was announced our studio was in the middle of a planned one week closure. During this time I was visiting my parents that lived several hours away from the studio. Since their house had all the necessary equipment to continue my work I chose to remain there. While I still had all the necessary equipment, my new space came with several complications. One of the biggest was the lack of a dedicated workspace. Previously, I had strived to separate my workspaces from spaces where I did other activities. This helped me to focus more on my work. However, in my new accommodations, there is not enough room to have a dedicated workspace. With three other people working in the same house, the only area where I have space to work is on the desk in my bedroom. I also do several other things in this area which made it difficult to concentrate on. Ultimately I decided to chair to only be used during work. This allowed me to have a change in my surroundings, which signaled that it was time to work. If I had pushed forward without making changes, my productivity and quality of work would have taken a hit. It may sound simple, but small changes like this allowed me to work more efficiently. My one regret is that I didn’t experiment more with altering my environment. While swapping chairs was helpful, things like clearing my desk could have also been beneficial. In the future, I will continue to create an environment where I can work most efficiently. Sometimes work has to be done in conditions that are not ideal. This experience has taught me that during these scenarios, I should look for ways to improve my surrounding’s to better fit my ideal workflow. My brain works in very specific ways, by observing it and working with it I can better optimize my workflow. Overall I am proud of the work my team and I produced. We were able to navigate through the multiple impediments to create a unique and polished experience. As a team, we managed to pull together when things began to get difficult. As an individual this experience has taught me various valuable lessons that I will take with me throughout my career.