In preparation for a new project this Fall, I have been reading through the ETC project postmortems from Spring 2012 and looking for common themes that I can implement into my next effort to make it successful. This is my own summary lens on 14 postmortems. I believe the postmortems are internal to ETC so I won’t be linking to them or giving out too many details, but the general lessons may be valuable.
The Basics
A few points get hammered home over and over again when you read postmortems on student projects. Our professors remind us of these all the time and they seem so obvious, but in the heat of a 15-week development cycle it’s easy to get them wrong.
Limit your scope
Somebody – could be anybody – will ask for more than you can give. So estimate your work right away, and be very clear about how much you can do and why. This is hard, and certainly deserves its own book, but there are a few key principles that will help:
- Accept that estimates are imperfect – it takes the pressure off. Round to days or half-days.
- Involve everyone in estimation – they will be more invested, and you will get more accurate estimates.
- Estimate frequently – you will get better at it.
- Build in buffer time – you will need it.
Almost every team celebrated limiting their scope, and no team wished they had taken on more work.
Prototype early
Teams that get past talk and design and make something the fastest, seem to have the most success, while those that don’t always wish they had started earlier… probably because this is a prerequisite for the next couple of points, iteration and playtesting.
For tips on making this happen, see “Gold spike” below and Kyle Gabler on rapid prototyping.
Iterate
The results are 100% consistent: Every team either says “We’re so glad we iterated so much,” or “We wish we had iterated more.” Build it, try it, discuss it, rinse and repeat. Of course, this goes hand-in-hand with the next point:
Playtest
The most successful teams were consistently the ones that did lots of playtesting. Those that start playtesting earliest and do the most over the course of the semester always have a more polished, more impressive product in the end.
Of particular note, one team mentioned that they did a lot of playtesting but they didn’t reap the benefits because they didn’t take the time to discuss their playtest results and update their direction accordingly. So, don’t forget the do something about it step. I’m hoping our whole team can meet after each playtest to talk about the feedback and plan changes together.
Doing Better
Then there are good habits that only some of the teams get – usually the successful ones.
Specialize
Very successful teams do a good job of specializing, with clear distinctions between roles for team members. “A lead for every task and every task has its lead.” This has a number of benefits – team members who feel solely responsible for an aspect of the project will be more invested and relish in their creative freedom. It helps keep aspects of the project from being overlooked. It looks good in presentations too, when for any given topic the team can point to their expert.
Foster interdependence
The flipside of specialization is interdependence and duplication of knowledge. Some teams reported that their members were so independent that they were not always on the same page. So while you have a lead on every task, you should also have at least two brains on every feature. It will build a team mindset, help team members get each other ‘unstuck’, and when crunch time hits you won’t have put the whole weight of the project on the shoulders of that lone programmer that knows how to deploy to the staging server.
Gold Spike
You have a brand-new team that’s never worked together before and you need to get started, but your client is out of reach and your design is up in the air. Early prototyping seems impossible. What to do? Why not make a tiny game together to get everybody rolling? The “gold spike” task (doesn’t even have to be a game) can be an icebreaker, lets the team get an early read on their group work style, and can be a first step in establishing your asset pipeline. I’m considering starting this semester with a quick “Asteroids” remake.
Low Latency Communication
A number of teams reported a new understanding of the value of face-to-face conversation when working through problems. It is tempting for some (like me) to write a long, detailed breakdown of a problem and its solution, and sometimes that is important. But drawings and diagrams are much more efficient than writing to communicate with a group, and if you can just walk over to someone and tell them about it, that is even faster. Documentation is an important tool, but it’s a slow one. Turn to better tools to communicate quickly within your team.
A Physical Task Board
A number of teams attempted to use Scrum or a related agile development style this last semester. Every single mention of Scrum in the postmortems said (paraphrased) “we started the semester using a digital task board, but it just fell apart. When we finally switched to a physical task board everything came together!” I’ve had the same experience on at least two different teams.
Above and Beyond
Then there are those outlier cases – times when a team did something different, and it really worked!
How to Pitch
One team told a great story about trying to help their client pick an idea. They had gone in with a number of good ideas, and explained the technical merits of each, but they were not getting the positive response they needed. So they sought assistance from the faculty, who recommended that they pitch just one or two ideas very well. They needed to show more excitement about the ideas they were pitching so that they could really sell them. They also needed to make the technical merit of the ideas secondary to an emotional hook. The team landed with their next pitch, and the project had a clear direction from then on.
On my own team I learned a lot about how important it is to be pitching your idea all the time. Even when the client comes to you with an idea, you have to ‘pitch’ it back to them with enough passion to make them your partners in the work. And practice makes… well, you know.
Unifying the Team
One team mentioned that they used improv games to get to know one another throughout the semester, and reported great camaraderie and unity as a result. That team worked some very long hours in order to produce a polished, finished product, and they credit their ability to cooperate at 3AM to how they developed their relationships early on.
Crazy Ideas
Humor me… some other things I want to try after reading the postmortems, though they weren’t directly mentioned.
The Mantra
It’s easy to get lost in the details when working on a project. Some of the strongest interactive works exhibit a unity of vision that can be hard to create with a team. I wonder, what would happen if, as soon as we had our vision hook/design pillars/theme song figured out, we repeated that as a group every day? It could take as little as one minute of a stand-up meeting. Would it help us create a more unified experience?
Juicemaster
Try putting one team member in charge of the “juiciness” of the experience. This is one of those easy-to-forget things that has a big impact. Ideally a game designer is looking at this, but programmers have a huge impact on it too.
A Shared Vocabulary
I wonder if it wouldn’t be helpful to continue building a shared foundation of words and ideas within the team, via common reading. You could even make this a role, and put someone in charge of the “book” club, but you share articles and videos. We kind of do this naturally, so it might be real overkill – or it might be interesting to collect all shared theory.