Producer | 47-Person Team | 3 Months of Development
Embedded Files
Fastival is a high-speed arcade-racer featuring multiple courses, karts, and characters to play. Players can race through several original tracks against friends and AI opponents.
Game Trailer:
My Responsibilities
Leading Postmortems
every milestone that we had. Together with the lead, we would lead a discussion with the entire programming and SFX team, to discuss what went well, what needs improvement, and what we could do next sprint to improve the development cycle.
Notes in Daily Scrums
were crucial for keeping track of the day-to-day actions of the team. My priority every day would be making sure that everyone was unblocked and had all the meetings scheduled that they needed. I kept all my notes about what everyone did (and what I needed to do) in my trusty notebook that I took with me everywhere
Teaching Tools
like Jira, Monday.com, and Confluence were all critical to the success of the game. I worked frequently hard to make sure that everyone understood the tools that they were working with so that we could.
Facilitating Communication
and making sure my team understood all the details of their work was important in keeping everyone up-to-date with the latest information.
Postmortem
Fastival was the first project I ever produced on, and with that came many lessons that I learned. Some of them ended up being more about dealing with certain interactions and certain people, but there were a lot of bigger rules I learned, too. Here are 3 of the big ones:
Lesson 1: Nobody Reads the Documentation
We began this project using a Monday.com board, but with base functionality, it did not exactly follow our process very easily. To mitigate this, I used data linking to reflect tasks on both a "backlog" board and a "task" board. This separated the player stories and epics from the same screen on which people would find their tasks, making it easier for people to find their tasks. The data was still linked, and the Backlog still showed progress, but the team didn't have to navigate through info they didn't need to read. Additionally, compartmentalizing the bug list from the main board assisted in clearing the communication pathways. Lastly, created color-coded filters allowed specific members of the team to filter out even more excess information they didn't need or want to look at.
That may be a slight exaggeration, but it can be really hard to get the team to read the documentation. I learned how to help deal with this issue by adjusting my communication in 2 main ways: accessibility and diversity.
I also realized that as the project progressed, there was a lot less consistency among team members when it came to reading the changes to the Game Design Document and picking up higher-priority bugs that were listed on our Jira (which we had to switch to mid-development). To make sure that all of the urgent and important tasks were done, I made sure that I was constantly writing down all issues that were brought to my attention, and speaking verbally to the individuals that would be in charge of fixing it. Making the change to sharing bugs/tasks verbally and digitally (on Jira), many of the bugs were caught and fixed at a much quicker pace.
Lesson 2: Embracing Feedback
When I received criticism, I would often explain the reasoning behind my decisions, thinking that by providing context, my mentor would better understand my thought process and offer more targeted guidance. However, I realized that this sometimes came across as if I was justifying myself rather than being receptive to feedback.
As a new producer, I received a significant amount of feedback, which was instrumental in helping me grow. Along with peer evaluations and post-mortems with the team, I had regular meetings with my mentor. During these, he would highlight any issues he noticed so I could address them within the sprint.
Through this experience, I learned that, as a producer and communicator, my primary responsibility is to ensure the team feels heard. While it’s important to address my own concerns, the focus should remain on finding solutions and supporting the team, with my explanations left for a different conversation when appropriate.
Lesson 3: How to Write a Bug Report
One example of this is when one of the designers entered a bug. Under the ‘Expected Behavior’ section, they put “[the feature] should work,” and under the ‘What Happened’ section, they put “[the feature] didn’t work.” This was not ideal for several reasons, but the most important reason is that it did not describe exactly what the behavior should do, nor prior events that may have led to this feature. The lack of information used up excessive time trying to figure out what the details were regarding this feature’s bug. Additionally, it made the programmer who worked on this feature feel really bad about himself, as he felt like all his work was for nothing and that people did not understand nor respect the effort he put into his feature.
When talking with team members (programmers especially), the importance of being literal and specific cannot be understated. This is a lesson I learned more by watching the reactions of my team closely, as well as talking to them closely. As we entered later phases of development, a lot more people on the team began to submit bugs. With a larger number of people doing this task, the quality control on the bug checking went down by a lot.
The wasted time having to send messages back and forth was not terribly significant, as it easily took less than 5 minutes to actually type out the messages and send them back and forth, but that was 5 minutes after I saw it, which was about 30 minutes to an hour after it was sent. That meant that the person who was working on that feature was not able to even start fixing it until all of that communication was settled and the bug was clearly defined. I learned that communication must be very direct, concise, and detailed when the development cycle is extremely short.
The Dev Team
Google Sites
Report abuse