Developing by Demo: How Demo Creation Can Help Rather Than Hurt

One of the most polarizing discussions on game teams often occurs around the hated, cursed Demo.  Every year, right around February/March teams start kicking it into high gear in preparation for the center of the universe in gaming – the Electronic Entertainment Expo (E3).  Occurring in June, E3 is the North American equivalent of The Great Migration.  Developers, publishers, journos, movie stars, sports stars and any number of random hanger-ons descend on the Los Angeles Staples Center trade show floor to see the latest and greatest new and upcoming video games.  There are huge presentations, props and parties all attended by the best and the brightest in our business.  And we all dread it.

We dread it because we know months ahead that we’re going to have pass something off as “finished” waaaaay before the development schedule allows.  It usually turns into a big crunch for teams as they struggle to implement finished systems and assets earlier than the natural course of development says they ought to be included.  On paper its sounds crazy.  What exec ever mandated some arbitrary date for the dev team having no knowledge about the sacredness and fragility of the development cycle? Madness.  But there is a method to this madness and in this article I’ll attempt to break down the key reasons why these demos and all others are actually good for development. In fact, I’ll advocate for more demos. Please save your slings and arrows till the end.

THE DEMO

A demo is (obviously) a demonstration. It’s real software that will either be presented or even played.  If it’s consumer facing through the press, a kiosk or a download, it’s got to be pretty damn close to the final version in the quality department. To show anything less than great would hurt the game’s chances for success rather than help it. 

There are lots of demos that a team has to create.  Internal milestone presentations to stakeholders, press junkets, trade shows, etc.  They seem to come from all directions and, all too often, seemingly out of nowhere.  Teams get frustrated thinking marketing doesn’t understand development.  Marketing thinks development teams don’t appreciate the marketing needs. 

Demos must be crafted experiences in order to represent themselves well.  The poor man’s demo is typically making the first couple of levels the software.  This isn’t the ideal since demos must be designed to show off the best parts of the game.  Too often the beginning of games tend to be laborious but necessary tutorials and those aren’t generally the best at showing the game potential.

THE VALUE OF DEMOS

Now that we’ve established the many forms of a demo, you may be wondering why I view them positively rather than negatively.  Everything written prior to this point certainly doesn’t paint a nice picture.   There are lots of reasons the benefits outweigh the costs.  Here are a few benefits that I’ve pointed out but I welcome contributions from readers.

Create Transparent, Shared Goals: The value of a team having a collective goal cannot be under emphasized.  Both Agile and Traditional project management approaches espouse the benefits of having a single endpoint that is communicated clearly to the team.  If you choose to Google the topic you’ll find a number of studies regarding their importance in social and team psychological behavior.  Demos provide a single, demonstrable goal and once that the team knows will be evaluated on a variety of criteria depending on its purpose. They are a catalyst.  A rally point.  I’ve implied that demos only happen on special occasions but this doesn’t have to be the case.  The end goal may simply be the end of the sprint.  To quote a well-regarded Agile Coach and friend, Clinton Keith, “Teams should treat sprints as demos.”  His point is that demos bring together the team around a common effort and by treating every sprint as a demo the team will train itself into producing work they know will be reviewed within that constraint.  This forces teams to focus and helps mitigate the risk of items running past the current sprint and into the next.  You can find his very interesting article relevant to this topic here. http://blog.agilegamedevelopment.com/2011/06/e3-and-agility.html

Define Done: Aside from communication issues I place the challenge of “defining done” at the top of historical team problems.  Both are often discussed in project post mortems or retrospectives.  Many times I’ve taken a look at work from team members or external developers and wondered whether they were serious or not.  Did they really think this item or feature was good? Do they think this is done? In retrospect I place all the blame for this confusion on myself.  In my earlier years I should have worked with each team or individual and collaborated with them to define the definition of done.  This would have set the proper expectations and the quality bar required.  Producers need to work with their stakeholders and teams to make sure that everyone is aligned with what done means on a particular deliverable.   Done is also relative. It doesn’t always mean that the feature is ready for final ship.  Some work takes many weeks and, if the team member delivers work in progress at the end of sprint but it’s not final, that’s OK– as long as the expectations for the end of the sprint were set prior to delivery.  Frequent face to face check-ins during a sprint also help keep features on course. If this analysis and discussion is not performed there will be guaranteed problems and stress on any project, regardless of product size.  This principle covers the smallest indie games all the way up to the largest AAA console or PC titles. 

Practice Closing: Some teams are great at wrapping up projects.  Some, not so much.  Often, I’ve found it comes down to the project management, leads and production team to set the right cadence and priorities.  This comes up often at the end of projects when team members may not be focused on higher value features or bugs and, instead, focus on their pet tasks.  When this happens the work is not aligned with the overall project strategy.  The producer must be very aware of what the team is focused on and what their bug closure rate is.  Demos, in this case, allow a team and producer to practice finishing the project.  If each sprint is treated like a demo a team can get very good and lean when closing the title.  Real, official demos (like for E3) simulate the finaling process to an even greater degree.

Iterate on Polish:  While some demos arise due to surprise opportunities most do not.  The trade show dates are usually set a year in advance, the general ship date is known, etc.  Producers need to work with marketing to evaluate possible opportunities that may arise so that proper risk management can be performed.   There is simply no excuse for a producer to not plan for demos in the schedule.  I do not advocate “padding”, however.  This is generally frowned upon all the way around.  If the producer and team understand the scope of the demo(s) then some planning can be done around their creation.

Engage Stakeholders:  Stakeholders are any people who will be affected in some way by the project…and there are a lot of them.  Usually, when it’s used in conversation it is referring to executives, studio directors, etc.  However they can also be the team members, customers, governmental agencies, etc.  It’s up to the producer to make sure the stakeholders that can have direct impact on the development process are regularly engaged.  Demos provide a way to show work in progress to these people.  In my younger days Bing Gordon, a founder of Electronic Arts, would harass me during meetings for me to stop using “weasel words”.  He was referring to my (previous) tendency to add a lot of qualifiers when showing off software.  He was a believer that the software should speak for itself and not require a lot of excuses like “that’s not done” or “we’re going to improve that”.  I’ve come to realize that weasel words actually hurt the feedback loop.  It’s important to not censor feedback and comments by preemptively cutting off potential critiques. Demos of working software allow this feedback to be honest.

THE VALUE OF CONSTRAINTS

Target dates are inherently a constraint, for demos or otherwise. In fact, the end goal of a project might be the biggest and most powerful constraint there is.  In the book Scarcity: Why Having Too Little Means So Much by Professors Sendhil Mullainathan and Eldar Shafir  the value of constraints is explored. http://www.amazon.com/Scarcity-Having-Little-Means-Much-ebook/dp/B00BMKOO6S They argue that the brain handles scarcity of food, money, etc. sometimes illogically and at the expense of the long term welfare.  It’s interesting to this discussion because our scarcity is “time”.  In other words, the lack of time leading up toward a deadline tends to focus people on the highest priority work alone.  If not managed correctly these deadlines can affect the long term success of the title.  This is why I agree with Clinton Keith about treating the sprint deliverable as a demo.  The regular time pressure cadence can help teams to focus on the work.  Too often teams lose focus and momentum when the project has years till the final date.  Sprints allow teams to create a sense of urgency that is sustainable and help alleviate panic as deadlines draw near. How often have you reflected back on your own projects and wish you had spent the time in the initial phases more wisely?

Constraints help projects focus and find creative solutions around a problem.  Many times I’ve had similar discussions with artists, designers, programmers, etc. and all generally agree that constraints help them be more creative when implementing a feature.  Constraints force out of the box, creative thinking.  They also help to eliminate waste.  In this case, the time constraint of the deadline forces team members into efficiency since they will need to be finished soon. 

Constraints can backfire, however.  If they exist but are unknown to the team then they can’t be managed properly and can lead to a very broken project.  In almost all cases, communication transparency is king.

IN SUMMATION

In the end, if managed correctly I truly believe demos can have a net positive effect on the success of a title.  I’m sure many readers may feel otherwise as this can be an emotional topic.  As always, I welcome feedback and I’d like to hear about other experiences as well.