Converts to agile tend to disparage traditional (“waterfall”) scheduling as an outmoded way of doing business, anti-productive process, and in all other ways evil.  However, the reality is that very few organizations can (or should) function on a purely agile basis.  I’ve personally done over a dozen due diligence evaluations of studios, worked with a dozen more, and with all of the teams that I have personally seen use agile, all of them have used a hybrid of agile and traditional scheduling, consciously or not.  Part of this certainly comes from the milestone-based contracts that external developers have to work with when dealing with traditional publishers; even internal teams often fall into the same structure due to organizational inertia.  But, in my opinion, the larger part of this is experienced production managers understand that agile and traditional scheduling are both toolsets; while each has their strengths, they also each have their weaknesses, and by leveraging the strengths of one against the weaknesses of the other, a stronger process can be built.

On a very basic level, traditional scheduling can be very valuable for those aspects of games that cross over from production into other functions: QA, marketing, and operations.  While everyone can recognize that the incessant re-writing of detailed schedules is an endless, Sisyphean task and usually wasteful of time and energy, a rough map of deliverables (call them milestones, or a release plan, or target dates for key features) is essential for the non-development areas of an organization.  QA, for example, needs to know, preferably ahead of time, what features are in the pipeline, what their scope/effect is intended to be, and when they are going to be testable.  You can lose as much time and energy writing and re-writing test plans based on daily stand-ups as you do managing a typical Gantt chart.  Similarly, marketing people need lead time to prepare materials, line up PR, and in the case of retail (still a significant source of revenue, even if it is not the hot medium right now) preparing channel strategies and distribution.  If you’re only marketing what you have after it’s live, you’re not getting the most you can out of your work.  And again, operations needs to know what’s changing, when, and how to prepare not only the underlying infrastructure but also all the player-facing resources: customer service, technical support, and community management.

At a slightly less intuitive level, traditional scheduling can play an important role in the administration of a studio and its teams.  Hiring a new team member takes a minimum of two months in all but the most exceptional of cases.  The staffing (or resource) plan needs to be forward-looking, identifying key needs well ahead of this two month window.  Even if you’re working in a large studio, where resources are easily transferred from one project to another, someone is still going to need to be able to justify the resources, plan for their transfer, and handle all of the associated details (workspace, equipment, etc.).  And as much as we would like to believe that every game developer is so insanely smart and talented that they can do their work effectively in any context, it’s going to take time to ramp up a new team member on project specifics, especially all of the places where their work is going to interface with existing work and other team members.  Again, this is time you will be well-served to anticipate, and that’s going to be a lot easier if you have a framework schedule that you’re working to.

At an even more abstract level, it is important to have significant review points.  While the speed of development and deployment these days means that a lot of people are looking at daily data, it can be easy to lose the forest for the trees.  Yes, if your retention/monetization numbers are going up every day, the trend line is obviously going to be upwards, but few projects generate that kind of dynamic.  Whether you’re reviewing performance internally, preparing for a quarterly corporate review, or presenting to your investors, it’s important to set larger-scale goals, then measure progress concretely against those goals.

If there’s a theme here, it’s that traditional scheduling offers valuable ways of doing forward-looking planning on larger, macro time scales.  Agile is great at keeping things humming on the day-to-day and week-to-week levels, but it has very few functions that apply to quarterly or yearly performance.  Those frames are ignored at your own risk.  While the in-the-trenches developer or scrum master doesn’t need to concern themselves with these larger problems, someone in the organization needs to be keeping an eye on the horizon and measuring velocity on a scale larger than an 8-12 person team.  The advantages of using agile methodologies (not just Scrum, but also things like Kanban and Lean) to manage the micro level of execution and implementation are fairly well-established, but a seasoned producer knows how to balance those processes against longer-term goals, and traditional methodologies can be an effective way to meet that need.