Doom / Doom 2

Platforms: PC, PS4, XB1, Switch, iOS, Android · Engine: Unity

Team size: 14 · Timetable: 14 Months

Nerve updated Doom and Doom 2 as separate releases to work on modern platforms (PC, PS4, XB1, Switch, iOS, Android). We aimed to be as true as possible to the original game by running the original engine natively, while upgrading certain features of the game. Our upgrades include adding Bethesda Net support and providing basic quality of life changes to improve playability in 2019.

I was the main Producer on the DOOM and DOOM 2 ports working with the development team to deliver quality work on schedule.  I worked with the team to approach the project through an Agile lens, so we could respond quickly to client requests and would maintain a playable version of the game through the course of development. In addition to working with the team to increase efficiency and effectiveness, I was also a point of contact with our clients and various other external partners. Our team bought in to the Agile way, and we worked together to overcome roadblocks as they arose throughout the project. In the end, we delivered a product that the development team was very proud of.

SQ_NSwitchDS_DOOM1993.jpg

Contributions and Tools

Role: Producer

My Contributions:

  • Drove implementation of Agile with Scrum

  • Performed Scrum Master duties

  • Trained and Managed the QA Team

  • Gathered Estimates and planned schedule to evaluate scope

  • Worked with Game Designer to manage sprint and project backlogs

  • Orchestrated presentations to stakeholders

  • Owned and drove Localization, 1st party Backend features, Telemetry

  • Managed build delivery to external Partners

Tools I Used Daily:


Documentation and Downloads


Images


Risk Assessment/Management

Assessment: Too much work, Too little time

Management: Negotiate Timeline or Requirements

Method: Generate a longer-term roadmap and negotiate Backlog and deadlines with clients

We arrived at the end of a specific sprint and we hadn’t made enough progress on specific features, and I realized we needed to either cut the feature or extend the deadline. I laid out our backlog item estimates in sprints and took that to the client to negotiate changing either the deadline or the expected features. Eventually the feature did get cut, and we continued using the more robust forward sprint planning method, but we still missed our deadline.

Assessment: Don’t know if we’re hitting our goals

Management: Find way for developers to measure goals

Method: Create a testinG plan against User Stories using conditions of satisfaction

Initially, we decided something was considered done when it passed through an internal QA review. At the start, this was too ambiguous, and Engineering and QA needed a way to measure completeness of a feature. I worked with the team to construct groups of Conditions of Satisfaction for every User Story and designed testing plans around them with QA to test features against. QA and Engineering both benefited and enjoyed this system, and our overall quality bar increased for future sprints. We became more thorough in engineering and in testing because expectations were clear for implementation.

 

Assessment: Rapid/changing client requests

Management: Use development style prepared for that 

Method: Drive implementation of agile with Scrum

Working contracts with external stakeholders requires constant communication with them about the status of the game and reacting promptly to their feedback and requests. With this in mind, I focused  on Agile with Scrum as our development methodology with the team. We worked in short sprints and maintained a living backlog to ensure that we tackled work in short bursts to better handle incoming requests. There were indeed changing client requests, but the team was prepared to handle them through the system we developed. It mitigated the risk well for the most part, but there were still instances where we had to toss a sprint plan to pivot in the middle of a sprint.

Assessment: Unplanned tasks taking resources away

Management: Find another resource to complete tasks

Method: Get hands-on and contribute with Engineering background to get across the finish line

Throughout development, there were several challenges that came up that we hadn’t planned for. As these things came up, I jumped in to take care of them, so the team could continue to focus on the larger goals and feature requests. I owned localization by collecting keys, sending them to our partner’s localization team, and integrating the strings when they returned. I also worked on various first party tasks like setting up trophies and achievements in the corresponding backends, and tracking some basic telemetry events for our partner.


Quotes

Justin was an exceptional producer, mentor, and friend. He helped train and teach myself and three other QA testers who were new to the industry. During our project, he ensured he was always aware of what each team was working on or needed and assisted with clearing their blockers. Justin always had a plan of attack as well as a contingency plan in case plans change, which they did many times. Seeing a project come together with Justin helped inspire me to strive for a leadership position and resemble his attitude for it. The QA team never felt at a loss during our project, and Justin’s dedication and efficiency was a large part of that.
— Maria Garza, QA Tester
Justin, throughout our entire time together, always used his depth of knowledge of production techniques and practices to make our department more efficient, cohesive, and informed. He was indispensable during the development of the Doom classic projects which required managing product statuses across six different platforms as well as during our internal project development. His broad and deep expertise in Agile development along with his technical background made him an essential addition to our team and a huge asset to anyone else’s.
— Roger Kort, Lead Engineer