Productivity Voodoo

Once scope is set, designs are written, and schedules are built, planning is over and production begins. During that time, producing isn't just running meetings, playtesting and giving inspiring speeches. That may get people to work harder but it's not going to make them work smarter. In this issue we're going to look at the #1 responsibility for producers after planning - PRODUCTIVITY!

Productivity Practices

Game development is like an automotive assembly line. Whether you manufacture software or cars, there is always room for improvement to speed up production and reduce costs. Several project management systems have been developed to help - Lean, Kanban, JIT, Sigma Six. They all largely focus on the practices of value assessment, waste reduction, continuous improvement, and reduced cycle time. But you don't need to be a PMP certified expert to understand that each deliverable, process and task in game development eats up the valuable commodity of time and effort. Your goal as producer is to optimize processes that do. Here are some ways to do this.

Value Assessment

This is an assessment of the game design, deliverables and tasks from the perspective of product value vs cost - the so-called "bang for the buck" test. Will that feature improve player satisfaction and sell more copies? Will that task or deliverable, if removed from the pipeline, be visible to the customer? If the task is not adding significant product value for the cost, it should be streamlined or eliminated. Here are some examples to consider.

Early E3 Demos Producing the E3 or tradeshow demo to generate marketing buzz is a fine value add, but do it too early and much of the effort to make it will be tossed like vaporware. Content creation should focus on the art and code that is actually included in the finished game.

Demanding Internal Customers Reports and presentations are often generated in development to be consumed by executives and directors on the team or external partners like a game publisher. There may also be a quarterly or monthly presentation to the larger audience at the company that you need to prepare for. Yet in an effort to make these reports and presentations stellar, resources from the team are often tasked to contribute to them instead of tasks on the game itself. Push back on these demands. Make do with the assets you have. Caveat the work-in-progress. Perfection for internal consumption is a waste.

The Money Shot The "money shot" is that ten second vignette designed to get featured in promotions or that one minute of unique gameplay that may garner a lot of buzz and respect from the gamers. Yet if it's so unique or polished that it is actually costing you a lot of money, you need to rethink it from a cost and value perspective. How often do players actually experience this in the game? What other things can you offer a player with that time and money?

Shipping the Design Document While it is important to maintain design documentation as a record of design decisions, it need not be perfect. Yet some teams take it too far. They'll replace the mock-ups in the document with actual screen shots as the work gets completed. QA testers may bug the document for spelling or grammatical errors. Designers and producers may fret about the formatting or inconsistent verbiage or capitalization, even though it isn't customer-facing text. You don't ship the design document, just the game. This is a conceit perpetrated by the game designers that you can afford to skip.

Eliminating Waste

Beyond the value-add question, there is much to be gained by eliminating waste in the development process itself. For every step in the workflow there is often some wasted time and effort that you can look at. Here are some examples.

Waiting for the Next Assignment Team members shouldn't wait around for a task to be assigned to them. If they're done they should skip ahead with "Self Service Tasking". This is in fact how Kanban works, though many teams use SCRUM instead, which has a Sprint Kanban, but it is only made up of the planned work for the time period. Towards the end of the sprint, developers may run out of work and wait for the next sprint to pick up more tasks. That's an easy target for waste reduction. If someone finishes early, have another story for them already prioritized on the backlog that they can grab.

The Danger of the Zero Rollover Goal A team is motivated by peer pressure and personal commitment to get everything done that's on the sprint without rolling over anything. A project manager may pride themselves on achieving zero rollover. It means they planned the sprint correctly. The danger is that it can lead to a tendency to keep the scope light, effectively easing off the gas pedal.

Zero rollover is a great goal for the team, not the producer. As a producer you'll want to have a different goal: maintaining and steadily increasing velocity. Keep that foot on the gas pedal. It may mean some tasks rollover, but better that than settling into sluggish complacency. In the end, your effectiveness is measured in how productive the team is, not in zero rollovers.

Underutilization On large teams especially, it is harder to keep everyone busy. Forgotten team members may slip happily into a non-busy state where they are waiting for a hand-off, tasks to be assigned or feedback from their lead. They may noodle and look busy to fill up their time, but they could just as easily help someone out with another task if they were made aware. At Cadillac Jack we had a meeting prior to the next sprint among producers and discipline leads to address this issue. We dubbed it "Resource Roundup".

Driven by the lead producer and using something similar to a Trello board, we would assign people to projects, trading resources between scrum teams. Producers from different projects would take turns spouting their needs. Need an animator or sound person for the next sprint? Need a logo or concept? Maybe there's someone on another team that can spare the time, or maybe that task is a candidate for outsource contractors. Once it's figured out, this board was then shared with the team so they knew where they would be needed and which team's sprint planning to attend.

Templated Time Estimates While it may seem efficient and even fair to make a templated task list include default time estimates, not everyone works at the same pace, and not every instance of a task will be exactly alike. Typically the templated estimate is rounded up and padded to account for this variation, but that just leads to faster people running out of tasks early. Don't let templates dictate times. Get estimates for each new task from the assigned team member.

Meeting Hell Meetings can be a huge time sink where no one is able to work on their actual tasks. The glaring exception may be the managers and directors whose job it is to use the meetings to collect and communicate information and make decisions. Therein lies the problem and solution.

? First off, do the value test. Does this meeting have any value or could it be accomplished with an e-mail? Is there another way to get the information you need that doesn't involve calling everyone into a meeting?

? There might be a regular meeting on the books, but if there's nothing on the agenda for the day, cancel it. The team will thank you.

? Next, look at attendees. The more people there, the longer the meeting will take, and the less real work is getting done. Optimize attendance. Use representatives from a discipline rather than the whole group.

? If it's important to make a personal announcement to the entire team, and sometimes it is, then try to keep the meeting brief.

? Enforce standup brevity. There's a reason why daily scrums are not traditional sit-down meetings. Standing encourages brevity. If people want to solve a problem during the meeting, ask them to take it offline after standup. If someone likes to figuratively stand on their soap box for five minutes and spin a tale about their challenges and discoveries, pull them aside later and ask them to give briefer updates.

? If the scrum team gets so large that everyone is getting weak in the knees while waiting to give their update, it may be time to split up scrum teams into more manageable groups using Jeff Bezos' two pizza rule. The team should be no larger than one that can be fed by two pizzas, which is about eight people if they have more than one slice. This will add to the number of meetings on your books, but the developers will have shorter meetings and more time to get work done.

Waiting for Feedback So much time is wasted just waiting for a code or art review. Developers might delve off in the wrong direction for days only to be course corrected. You need to tighten that feedback loop.

? For artists and designers, daily walkaround or screen sharing of work in progress (WIP) for review by leads dramatically speeds up design time.

? For coders, that feedback comes before any code is written by having a plan reviewed by leads using a technical design discussion or document. Before starting a new feature, add a story for the TDD to kick it off.

? Coders should also have peer code reviews before changes are merged into the dev branch. This helps avoid bugs or reworking later, and it often makes code more reusable. Some software will handle the code review requests, but have them speak up in standup if they're still waiting for a code review.

Rigid Sprint Schedule Early in development when there is a lot of discovery to be made on research tasks or idea exploration, it shouldn't wait two weeks. There is no steadfast rule on sprint duration. You can have shorter sprints of a few days to a week to make the discoveries and plan the next iteration. This means more meetings but they will be congruently smaller. Sprints can get longer as the unknowns are reduced.

Swirling You may notice in standup someone delivering the same update every day for a week. That may be expected for a longer, vague task, but you can always ask for a more atomic task breakdown to be sure they're not swirling.

If they are, send the swirling dev a lifeline. If it's a specific task going way beyond the original estimate and showing no sign of finishing, it's time for a follow up from their discipline lead. If you are their lead, sit down and talk with them. There could be problem with design direction, some over-thinking or a similar disconnect from expectations that you can clear up. There might also be some technical debt or unplanned groundwork that wasn't captured in the sprint planning. It could also just be a really challenging coding problem that could use some mentoring and maybe some pair-programming.

Old and Lingering Bugs Bugs not only slow you down because they have to be fixed. Just waiting to fix them for the designated testing phase can generate a lot of additional waste.

? Old bugs are almost by definition suspect, because a lot has changed since the bugs were observed. They'll need to be verified again, wasting tester time, or they'll waste the developer's time if they're already fixed.

? Lingering bugs keep getting discovered and often re-entered creating duplicate bugs, a huge time-waster for all.

? Older bugs are sometimes harder to fix because the developers have to reimmerse themselves in the code and the problem it was solving. It's so much faster to fix the bugs as they're working on the feature.

? Bugs are often the first sign of problems on a coding approach, and if the fix ultimately requires a major re-write, it's best to find out sooner.

Here are the some rules that you should have on every development team to solve this. (1) Developers must fix bugs as they go. (2) Embedded testers can bug any task or story when it is marked done. (3) Developers should do a build and self-test their work for obvious problems before marking a story or task as done.

Too Many Cooks in Too Many Kitchens The knives often come out in polish meetings. It's unavoidable but hopefully directed at making the game better. The problem comes when there are too many people i.e. too many cooks in the proverbial kitchen. This not only frustrates the developers receiving the feedback, but it can make the meeting take much longer. Consider shrinking the attendance of this meeting to only a few discipline leads or directors.

The opposite can also happen when key people providing feedback are NOT in attendance. They may be doing it remotely or are just not available at the same time. Not only do they end up catching many of the same issues and wasting their time, but they can sometimes disagree. One may ask for changes that another dislikes, creating confusion and frustration that can bounce the producer between the stakeholders as they work it out. Such disagreement in the polish list can create a lot of confusion and wasted efforts.

Still another problem is having an unexpected stakeholder give polish feedback late in development, taking something back to concept that you thought was done. Not only is this not fair to the team, but it's a huge time-waster to go back and change things that may have already passed several reviews.

The solution is to call all the key stakeholders into a meeting room and have them hash it out together then and there. No more surprise feedback from surprise and absent stakeholders. Publish the polish list, work on it, then pursue their sign-offs with the goal of focusing only on bugs and publisher feedback.

Continuous Improvement

Teams should always look to continuously improve their processes. Producers should facilitate this even as they themselves may be determining process. To that end, you need the following:

Process Retrospective There needs to be a way to get feedback from the team back to those that drive the process. The process needs to work for the team or it's not working. This can be a monthly or quarterly retrospective. The team may not feel comfortable openly sharing criticism with upper management in attendance, so keep them out. You want to just collect the feedback and ideas and bring that report to management for consideration.

Internal KPIs To measure improvement you need some targets for the team and measures for success. For slot or hyper casual mobile games, this may be game count for the month or quarter. For console or pc games, this may be an asset or level count. For epic tasks that take longer than a month or sprint, this could be percentage done vs targeted done. The trick is record keeping so you can compare to previous sprints or months. Share these KPIs with your team.

Time Estimates No one likes doing estimates if the work is getting done anyway, but time recording, even if it's just scrum points on a sprint or hours on a task is essential for measuring success and learning as an organization how long tasks take for purposes of scoping out the next milestone or game project.

Bug Count and Trends No one likes to see their names on the top of the open bug count report. It's a motivator for sure, but it also gives them a target for self-improvement. Here are some bug count charts that you may find useful:

? Open Bug Count By Severity (A, B, C etc.)

? Bug Counts by Status (New, Open, Fixed, Closed, Waived)

? New vs Closed Bug Trend By Build

? Open Bug Count of A, B, C, Total Open Grouped by Individual Assignee

? Average Lifespan of Bugs (in Days) by Month

Reducing Cycle Time

Repeated steps in a game project, like the station at manufacturer's assembly line have a cycle time. This is the time it takes to produce one asset. These repetitive tasks can get faster over time as people get more skilled at it, but it's not always about skill. They may be on the critical path for your project and anything you can do to unblock them and simplify their job will shave days off your finish date. Here are some examples:

Better Tools Sometimes the task is an inefficient use of talent or is prone to bugs that have to be fixed. Automating something with a tool that takes a few weeks to build that saves collectively months of time for people is well worth it.

Sign Offs At CJ we had a sign-off board for leads and a published polish list. This made tangible something that could potentially remain an obscure moving target. Sign offs help keep tasks moving forward.

Published Workflows and Timeboxing An asset, level or game can pass through various hands and stages before completion. Document that with a flow diagram and write on there a range i.e. 1 to 3 days to indicate what the expected range is for an easy (1) to harder (3) asset. Work on those times with the team and publish it so they can measure their performance vs expectations.

Conclusion

These examples were all aimed at improving productivity using manufacturing principles. You may come up with your own methods and process improvements. Every game studio is different. Just remember that people come before process. Keeping them happy, contributing and growing with challenging and fulfilling work is still your most effective way of making a successful game. It's in the details - the hand-offs, sign-offs, meetings, tools, documents, task boards and reports, where the process improvements can make a huge difference. This is how you help them be successful in hitting their dates without having to crack the whip and crunch. In this way you are of service to your team.