Foundations

Part 4 of 4 Series on Strategic Development for Emerging Market Developers.

For Part 4 in my series on strategic development in emerging markets, I debated on many topics to deliver this final piece to the series. ?I decided that the best thing to do is share the foundational experiences that have led me to expand into the project management approaches that I use and recommend today. Mine was not a solitary experience, and I have to give a big thank you to my co-workers and managers who helped shape the DNA of my experience at Capcom that guided my learnings and understanding of how to scale teams from the ground up.? So when I speak about “Project Management” in this article, it includes many people, but to name a few, many thanks to Christi Rae , Jason B. , Ed Tam ?? GDC , for those great discussions that really taught me the spirit of continuous improvement.

A pivotal moment for me in project management was defined mid-way through my 18+ year video game industry career when I managed the majority of the development team at Capcom Vancouver in 2015 for the Dead Rising Franchise of video games on their latest next generation installment.? I was given an opportunity to join a small team in pre-production that grew from 25 to 120 within a year, where I supervised production for 60% of a cross-discipline development team.? This experience laid the foundation for many frameworks that I have advanced over the past decade for many employers, which has allowed me to direct strategic development efforts for various game development companies.? When I was asked to support a new Capcom development team in 2015, it was to help develop a framework for scalability and bring a small team from a preproduction phase to a fully scaled team for production.? In this document, I will describe the phases of production that I was involved with, which teams I managed, and the challenges faced as we scaled the team to over 100 resources on this multi-million dollar budget.

?

Managing Team Growth & Scalability

Initially, our pre-production team was made up of approximately 25 developers. At any given stage of scalability, I was managing about 60% of the overall team that consisted of multiple disciplines from Artist to Designers and Engineers. Artist with expertise in 3D Art, 2D Concept, UI, Visual FX, and Cinematics, Designers in Narrative, Level Design, and Engineers in Technical Art, Rendering, and Systems development. We were lacking senior management in all disciplines, which bottlenecked our director’s ability to manage the ongoing frictions and personal growth of the team as the team continued to scale.? It was Project Management’s shared responsibility to facilitate a solution, and after some discussion, it was decided to separate the management of team friction and personal growth into career and people management focuses.? This easily freed the bandwidth of our creative leadership by 50%, offloading the people’s day-to-day friction and organized career progression tracking to Project Management, while leveraging the director and leads to consult on specific career progression initiatives.? This also allowed the Director level to focus on managing Lead level and above employees in both a people and career management role, leaving the larger team to project management.

?

Effectively Tracking Sprint Progress

In scaling the team, we found it an ongoing challenge to bring the entire team over to an Agile/Scrum framework.? The engineers were following the typical rituals of daily stand-ups, entering time spent on user stories in Jira software, and going through sprint planning, sprint reviews, and retrospectives.? However, the creative disciplines which made up almost half of the team were finding it difficult to adapt and struggling with time logging against their assigned user stories.? Historically, I have never found logging time in project management software like Jira to be an accurate representation of progress, unless the team consist of highly experienced, self sufficient developers.? With this new team, they were still a developing team learning to work together and incorporating senior talent as they continued to grow.? As one of a few project managers for the longest time, and with my portion of the team ballooning to 70+, I requested an associate project manager to support me, but it was essential that a better solution be found for effectively tracking and mitigating risk for the sprint.? I decided to meet the team half-way, and requested that they log their time every Friday, so we could generate a weekly report on the progress towards our 4 week sprints.? This decision created the least amount of friction, but whether they logged their time daily or weekly, the sprint burndown was far from accurate. I then proposed that we ensure that all user stories entered in Jira not be more than 2-3 days in duration, so that I could track the user story completion each week against the user stories remaining.? This allowed me to generate two Sprint Burndowns, one with logged time, and the other by quantity of user stories completed.? Only when both burndowns showed underperforming results, we would know to escalate the situation. If only one burndown was underperforming, it was fine so long as the other burndown was showing signs of normal performance.? To further refine our ability to mitigate risk for each sprint, I also decided to implement the 50/70 rule, where there was an expectation to be 70% complete at 50% of the sprint remaining.? This rule has been cited in various project management documentation and comes from the idea that if a plane is halfway down the runway but not at 70% of full speed, then the plane should abort the takeoff.? This concept was enough to create a sense of urgency from the team to further refine their performance.

?

Exhibit 1. The “50/70 Rule” is a more realistic way of estimating how far along you are in a project.

?

?

The Horizontal Slice

In a video game product, there always seems to be an emphasis to reach a “Vertical Slice” release that provides a proof of concept of what the final product will be.? Many stakeholders rely on this in order to approve further funding and allow the team to proceed to production phase.? Unfortunately, for this development at Capcom, it was decided that the team would not use the proprietary game engine that had been used for the previous 4 iterations of the Dead Rising Franchise.? Instead, the team was to adopt Epic Games’ Unreal Engine 4 since it was highly adopted in the industry at the time and had offered a quicker turnaround for content development.? As the team made the transition over to Unreal, my portion of the team was progressing rapidly and beyond expectations, having the robust pipeline of the Unreal Engine at their disposal. However, the engineering teams were slow to implement gameplay features and made many compromises from what their proprietary engine provided.? As the creative teams progressed further and further ahead with amazing results, the technical teams fell further behind, and it was clear that a vertical slice would be impossible to present at the end of pre-production.? This is where project management shifted the team towards the concept of a horizontal slice, and upper management was able to convince the high level stakeholders at Capcom to accept a horizontal slice.? The idea was that we would provide two deliverables, one focused on a walkthrough of the gameplay experience using prototype code and without any finished graphics, and a second deliverable representing the visual quality of the finished product.? This was enough to create confidence in the stakeholders and approve funding to move the team into production.

?

Effectively Tracking Feature Progress

As we moved into production, it became clear that the overall game size and features were constantly changing, and it became a big unknown as to what to expect given the available budget and timeline.? How could we develop the product and communicate to the marketing team what product we were trying to sell when we weren’t sure of the scope of the product?? This would affect market positioning, and pricing strategy as well.? The topic became a growing concern for all stakeholders.? Up to this point, we had been organizing the user stories towards Epics that represented different components/features of the game, but with the two vertical slice deliverables, it showed that features couldn’t be fully worked on and completed until the technical portion of the feature caught up to the creative work’s progress.? This is when project management requested that Features be broken down into different phases of completion, from Design/Prototype Phase, Functional, Intermediate, and Advance Phases of the product, as well as a Polish pass.? This method allowed us to see the feature progress better instead of having these uber epics.? User stories couldn’t be flushed out in a waterfall method for all phases. We couldn’t trust on the planning of user stories in advance to get a sense of progress, as these user stories continued to grow in quantity under the old system as the feature continued to develop.? Seeing these new Epic Phases complete gave us a better sense of the progress of the overall product by looking at the product progress under an Epic Completion Burndown.

?

Forecasting the Scale of the Product

During pre-production, my team went through several iterations before achieving their horizontal slice deliverable.? The first iteration was to develop the highest quality product that represented what a next-generation product would look like.?The second iteration was then to rebuild something equivalent to the scale of the first iteration, but in a reasonable timebox with content optimized for the game engine.? The third iteration was to use the workflow that the team used in the second iteration, and try it with a larger strike team to get a better sense of team velocity.? By going through this process, we understood the team’s velocity on delivering portions of the world that made up the product.? With some additional data from other disciplines, I was able to create a system to forecast the playable size of the product within the budget and timeline remaining.? As the technical team continued to develop their understanding of the new engine, and develop features, they continuously changed the design and expectation for the product.? Any change by the technical team that would impact the schedule of the creative team, we could quickly communicate within minutes how that change would reduce the overall playable size of the product.? The forecasting system was essential in keeping the overall team on schedule, and to prioritize the features that were most needed for launch.

?

Conclusion

This experience really changed my approach to project management, giving me the insight to understand that not every project will be managed the same way, and that we need to learn to adapt for different people, stakeholders, and when the situation calls for it.? The context here was that having knowledge did not equal having understanding.? It’s been 8 years since my Capcom days, taking those standard project management practices and methodologies and adjusting in a way that reduced team friction, increased risk mitigation, while supporting the scalability needs of the team has become my standard.? This personal standard has promoted self-learning and continuous reflection in my ability to create an optimal working environment to lead teams effectively.? Today, I am open about the foundations that have led to my personal growth and share with the teams I am consulting with to promote their professional development.