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.
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.