The Secret's in the Schedule: Bending The Mythical Man-Month

The Mythical Man-Month is a seminal work on not just software engineering but the psychology of human interaction inside a team environment.

Nearly everyone in our industry is familiar with the name of the book and most have a cursory understanding of its central tenets. However, significantly fewer people have ever actually read the book or have a deep understanding of it beyond some well-known quotes that have become platitudes. This lack of deep understanding leads to two problems. First, people don't prevent actions that go against the very pretense of the book, which means they make mistakes that were identified as mistakes nearly 30 years ago. The second problem is people rely on an overly simplified understanding of the book and therefore are unable to conceive how its fundamental rules can be bent and twisted to allow that which seems impossible.

Obviously I recommend everyone put this book in his or her personal reading queue and get to it soon. Rather than rehashing the book's contents, the focus of this article is on ways to bend and stretch The Mythical Man-Month to its extremes; to help reduce restrictions of progress due to communication breakdowns and interdependencies.

The author of The Mythical Man-Month, Frederick P. Brooks, Jr., puts forth an idea that probably isn't too shocking to most of us. He believes software engineering is radically different from all other forms of engineering primarily because there is no physical representation for our product. He argues that while studying the organization of other engineering fields can be useful, it cannot completely govern our particular craft. I'll extend this idea even further with another not-so-ground-breaking declaration: computer game engineering is by far the most esoteric of all software engineering, because at its essence is the difficulty of developing the all-important fun-factor.

About Schedules

The two primary ways to control the inherent limitations imposed by The Mythical Man-Month are through schedule and process. While the scope of this article is on scheduling, a complementary feature covering the process side will be given in part 2. The Mythical Man-Month states that adding people to a project experiences a law of diminishing returns until a point where growing the team actually creates a net loss in progress. The essence of this idea lies in the complexity of software engineering, where each team member works on a virtual object with a significant amount of attachment to other pieces. All of these separate pieces must line up correctly for the final product to succeed, so communication among people becomes an exponentially tightening bottleneck as the team expands. Translation: more of your day is being spent in meetings. This is especially true as the project gets closer to the end and the volume of history knowledge reaches its peak. However, while this general tenet is true, the rate of decline and the transition where the new person added causes a net loss in productivity is variable. The best way to control these variables is through knowledge of your project's scope and resources, especially the team's manpower. And this understanding must go beyond simple head counts and reach a true understanding that your team is made up of very different people who need to be managed in very different ways. An effective management strategy including schedule and process can pull significantly more productivity out of a given team and thus stretch The Mythical Man-Month to its limit.

All successful projects must start with a schedule to understand the scope of the undertaking, no matter their timeframe. If you believe you don't have time to schedule, then I counter you don't have time not to. A schedule is your first line of defense against the communication breakdowns that kill a project's deadlines.

Amazingly, I still encounter teams with extremely poor or even nonexistent schedules. In my early years in the business, I worked on three games called Esoteria, Tube Racer, and Beneath. Never heard of them? Exactly. The first was barely released and probably only sold a couple hundred units and the next two were both canceled after numerous schedule overruns. All suffered endlessly from a lack of proper scheduling. Since then, I have shipped every game I have led on time, mainly due to great schedules which gave me the information I needed to mutate my team when new problems arose. In my last year at Microsoft publishing, I've seen many games ship and many games killed: a constant theme running through them all is that poor scheduling leads to canceled projects.

Project Life Stages

To understand scheduling a game you must first understand the phases of existence that all projects go through. While the absolute time of each phase fluctuates based on the overall project length, there are common ratios of time between them. The first stage is concept development. You are in a creative period when blue-sky brainstorming is the goal. At this point, you have no need for real schedules beyond simply setting a deadline for finishing these initial meetings. Upon completion of this phase, you should have a well-defined design document with discussion of not just the gameplay but also art and engineering-centric sections as well. This should take approximately 1/8 of the total timeline or about three months from a 24-month project.

The next stage is your prototype where you prove out the major unknowns, the foremost being the fun factor. This section is scheduled much like the whole game, only with an abbreviated timeframe, normally around 1/8 of the total project but sometimes growing depending on initial technology. Obviously, the more stable the tool set and engine you start with, the more likely the prototype would fall within the three-month estimate. If the prototype is successful, you should leave this phase with a strong understanding of what will make the game fun and an example program that conveys this idea. Along with this will also be a system-level task list with estimated time allocations for designing these new systems. In other words, all the major systems might not be done but you should know what they are and have a rough guess as to the manpower needed to complete their first pass. This is the phase when independent developers should begin shopping around to publishers. While some development houses are lucky enough to get signed with only paper presentations, showing up with a working prototype goes significantly further when trying to secure a deal.

Your next stage is preproduction, which is when the team tackles the remaining uncompleted systems through at least the first implementation. For example, your new experimental lighting system with dynamic shadows should be up and running along with the decision to continue work on it or cut it due to problems. You should also have your first couple of levels completed to alpha quality to extrapolate the effort needed to complete the remaining levels. The first level always takes the longest and usually ends up being the worst because your team is getting used to the process and the new game you're making. So you must complete two or three levels so the team begins approaching what the real world manpower per level will be. Once you've done this, you'll be able to map out the rest of the time frame and know if you need to reduce the level count immediately. This stage should take about six months from a 24-month project or 1/4 of the total project.

Now you enter full production, which is normally when your team hits its maximum size (without the extras needed for test, which normally comes on later). At this stage, the game should be fun and its entirety should be known. This is where your system level task list is constantly being refined into smaller and smaller resolutions. The process is becoming mechanical now as opposed to the freeform conceptual stages in the beginning. Your schedule is now the end-all be-all of the project's existence. You should expect this time to last about nine months or a full 3/8 of the project making it the longest stage. This section of development ends with code and content complete meaning everything is in the game the way it was originally planned. It doesn't mean the game has to be completely locked down as final changes can still be made well into alpha as long as proposed changes significantly improve the overall quality of the game with limited risk.

And now we're brought to the end, the final stage. It's here that you've reached alpha and beta, also known respectively at Microsoft as code/content complete and zero-bug release (ZBR). These stages are mostly defined by long crunch times. Programming is focused on bug fixing, the art department on final polish, and the test team ramps up to full capacity. The schedule is becoming less structured and instead the team is being driven by daily and hourly updates derived from the test team along with oversight from the departmental leads and producer. Your bug-tracking software essentially becomes your schedule as you make your final sprint, which normally lasts about three months out of 24 or 1/8 the total.

Once you understand these stages of development, you'll be better able to schedule them. One important point is that these fractions are meant to be guidelines, not strict rules. All projects expand and shrink these stages as they need them. While one project needs more time for prototyping, another needs less for production. Or perhaps your project is a simultaneous three-console release that will probably increase your absolute time spent in the final bug push. However, these guidelines should help you identify earlier when a particular stage is grossly beyond expectations. For instance, if you worked on a prototype for nine months, you shouldn't expect to complete the game in the next year. Your team obviously created lots of new technology and gameplay if it took nine months for a prototype, so ramp-up time alone when building the full game will prevent your team from finishing in the coming year. Working at Microsoft publishing has shown these time ratios to work successfully for many projects including Counter-Strike for Xbox, which was essentially a five-month project, and Whacked, which was a two-year one. These two projects had completely different absolute times but similar ratios between segments.

______________________________________________________

Building a Schedule

Traditional scheduling in the form of a Microsoft Project document or a simpler Excel spreadsheet is most critical during the prototype, pre-production, and production phases of development. Concept development is too freeform and the final bug push is too reactionary; neither will benefit much from a schedule. The prototype phase is really just an abbreviated form of pre-production and production, so to understand those is to understand prototyping. Therefore, let's focus on pre-production, production, and the differences between them.

Creating a schedule first requires building a task list, which is in fact an expression of your design document. Are you building a racing game? Do you need a four-point suspension system? Do you need a flight control model? Is water surface dynamics critical to the boat level? Do you need a custom lightmapper? These game features need to be filtered into independent engineering, art, and level-construction tasks. The resolution of these tasks is dependent on where you are in the timeline of your project. We begin with system-level tasks during pre-production and constantly refine these as milestones are started, progressed, and completed. By the time you reach production with the major unknowns resolved, you should be able to make a valiant effort to refine the entire schedule down to days, but don't. Tasks should initially be timed at a resolution of about a week. Anything that needs to be completed in the next two months should be resolved down to days. Refining the resolution too much, too soon will be work wasted since the dynamic nature of a schedule will lead you to redo it anyway.

Understand the Team

The next stage is understanding your team's manpower. You should begin by identifying the type of developer (any team member including programmers, artists, level designers, and so forth) each person on your team is. One simple way to do this is to analyze how they fall into four basic types, based on combinations of skill and dedication. These types can be represented on a simple 232 matrix with their skill level on one axis and their dedication on the other. Developers near the low end of both axes, those with little skill and poor morale, should be removed from the project after attempts are made to improve their dedication. Skill takes significant time to improve--so don't expect that to rise over the course of one project, but a person's morale certainly can. However, if you can't promote improvement in a reasonable time, say 1/4 of the total project length, remove them from either the project or the company. Too many leads allow poor performers to stay in positions where they drop the ball and bring down the morale of those around them. Removing a poor performer can quite often create a net gain for the entire team even with the loss of the head. My previous work at Presto Studios showed me first-hand the damage one or two low-end members can do to the overall workload and morale of a team.

The next type of developers are the highly skilled persons who are poorly motivated. Maybe they don't like the game. Maybe they're angry because they didn't get the lead positions. Maybe they just came off a horrible crunch and just aren't ready to dedicate long hours again. Whatever the reason, they simply want to work their 40 hours, do their job effectively, and then go home. But since they are still highly skilled they are valuable in their own way. They will be most useful when working on exactly what they want to work on. If they're masters of networking, then that's where they go. They will put up with the least amount of unpleasant work when compared to the other developer types. Due to their skill level, they will require less hand holding but their strict hours mean keeping them on their schedule will be most critical. Luckily, their own sense of pride will often be their strongest motivation for getting the job done right and on time.

Then we have the young kids straight out of college with little skill but miles of desire. These developers want to prove themselves but they can get over their heads very quickly. Give them the systems with the most design in place. Put them in positions where they have the most number of seasoned developers working with them. They should be given non-performance-critical code such as UI. They should be watched over by more experienced mentors and be expected to make up for their inevitable schedule overruns with long hours. At this point in their career, they are paying their dues. And if their rookie mistakes are kept to a minimum by monitoring them closely, their ambitious attitude can help light a fire underneath everyone in the group.

And finally, we are brought to the most important people on the team: the superstars. They are the highly skilled, highly motivated crew that makes the impossible possible. This is the white-hot fiery core of the sun that will drive your project when things get tough. They will work weekends without even being asked. They will bring in sleeping bags when necessary and work all night if needed to get back on schedule. Work for a 1:3 ratio between superstars and the other two types of developers. (Remember, you should have already fired the first group so we're only left with three total groups.) Your superstars are your first and last line of defense against missing your milestones.

Assign the Team

Once you understand your team, you can successfully begin to assign people from your pool of talent to the task list you have built. Assign the highly skilled but poorly motivated people first. Give them the systems their skills match and they are interested in building. If you run into conflicts such as too many physics programmers all wanting to own the system, try to exchange these resources with other teams. You do not want highly skilled, poorly-motivated people working on systems they don't want to. If you do this they will most likely start dragging their feet or sending out resumes. Next, layer in the superstars who most likely can do almost any system you assign to them. These people have written graphics, physics, sound, AI, and most everything else so skill matching should be less important. After they have been placed, the first two groups of developers should cover every major system, leaving the eager rookies to round out the corners and fill in the gaps.

With people assigned to the task list, the lead should take the first pass at assigning time to each job. Be liberal with your estimates; optimism is a swift killer of any schedule, so assume mistakes will be made. Go ahead and assume your difficult, product-defining systems will need to be rewritten two or three times. Once completed, bring your team together and as a group discuss your estimates, gather contrary opinions, and negotiate final estimates for the schedule. Remember, even though you're the lead, it's the persons you've assigned to the task who have to complete it in the scheduled time. Give them the final word if you can't come to a consensus.

You now have a full task list complete with people and time, however it's still not a schedule. I've seen many projects over the years stop at this point without truly turning the task list into a schedule by serializing the pieces. This process begins by determining dependencies among the tasks. You can't texture a level until it's been modeled. You can't animate a character until it's been skinned. You can't program the front-end UI screens until a base GUI system is finished. This is what creates a timeline that shows people what they should work on on any given day. This is also how you can identify the communication dependencies that lead to one of the central tenets of The Mythical Man-Month. It's at this point that you can see just how interconnected your different systems and the programmers building them will have to be to complete the project.

We now must lay this data into our schedule software. Put each person down for six hours a day for five days a week. Even if you expect a death march, don't start by scheduling for it. That's a sure bet at blowing your deadlines down the road. The six-hour day covers the time during an eight-hour day the person will be in meetings, taking lunch, or hanging out in the kitchen eating a muffin with the team. Remember to put in holidays. (I laugh every time I see a schedule with someone completing a task on Christmas Day.) And as a general rule of thumb, assume each developer will take one personal week of time every four months.

Now you might look down at your schedule and think something has gone horribly wrong. One or two people in the schedule will have way too much work that puts them months or even years beyond the rest of the team. Workload balancing is required to fix this problem. Move tasks to other developers, starting with the easiest, but remember as tasks move away from their ideal owners they may need additional time padding for someone not as familiar with the system. This is also when the idea of additional developers should be first introduced. If you have a hard date for delivery and the tasks just don't add up, start padding your team with TBD (to be decided) members. This true and honest schedule will be your ammunition to request more support from your boss. Fight the urge to simply schedule for a crunch this early in the process. If you can't get the people you need on this schedule, then make it clear cuts must begin now. By following these steps, you can start making these hard decisions early instead of in the final months.

After days or weeks of working out the tasks and timeframes, you now have a schedule. You should know the size of your team, the tasks they perform, the order in which they will perform them, and how long the total project should take. Of course, it's all a big educated guess at this point but it's infinitely better than nothing. And remember that the schedule is a living document that should be updated daily by the owner. Don't be afraid to change it and make sure people know when their sections do change or when a major overhaul is needed to bring the schedule back into reality. If any one person falls behind his or her milestone deliverable time by more than 10 percent, the problem should be addressed that day. Maybe the person just needs to talk the problem out with a mentor. Maybe he or she needs assistance with the volume of work. Maybe someone else can take one item off the plate to give the person a couple of extra days. Be honest with the schedule. The more truthful the schedule is, the more flexible your team will be.

A schedule is knowledge. Yes, it's a human construct and therefore ultimately flawed, but it's still the best way project managers have to understand what lies before them. It's your map through the jungle and you'll be glad you have it even if a couple of the trails are mislabeled. With this information you'll be able to stretch your team into shapes and forms everyone around you will claim are impossible. And even if you do miss a milestone, a well-built schedule will help everyone believe you're only missing one instead of the constant slide most doomed projects face.

My next article discusses process and useful ways to implement your new schedule, so your team can continue breaking new ground in game development while you keep the communication nightmare off their backs. Now get back to work, you have a schedule to write!

______________________________________________________