TIGSource Forums

So I put my hand up to run a workshop at Freeplay an indie games festival here in Melbourne, Australia. The topic is "The art of getting things done" and focuses on leadership and management on small teams. A subject I feel is both overlooked and very important, a major cause of project death.

I was wondering if any of you have thoughts and insights you would like to contribute on this topic. I have my own methods and thoughts but varied perspectives on the problem would assist greatly (I will credit you and link to the thread in the handout).

Thanks!

Is it at all ironic that you're asking for other people to help you get done a talk on getting things done? ;)

Actually, I find it helps motivate me to get things done when I'm getting feedback from other people. So I'll answer my own question: no. :giggle:

I would love to see more discussion about this!

I think one component to completion that can be really hard to get over is the simple act of "Letting Go".

When a project is winding down, and most of the work of hashing out the structure and meat of the game is done, you're in a strange phase where you have to polish the game until its "good enough". "Good enough" is a really subjective concept that is hard to achieve when you're pretty critical of your own work. Eventually you have to release the project without feeling like its completely 100% "good enough". Such is life, and nothing is every perfect. Its a hard thing to get used to.

I'd agree with the above statement that having other people around to offer differing opinions can be really helpful - especially if you have low self-confidence or high level of critical tendencies towards your own work. Sometimes having someone say "Hey, this is fun!" is enough to make a lot of those useless self-doubts evaporate.

I also like this: http://www.ikiw.org/2009/03/04/the-cult-of-done-manifesto/

In my experience, the #1 thing you need in order to get stuff done is to have reasonable, incremental deadlines, which everyone on the team has accepted and committed to meeting.  You need a "finish on date 'x'" deadline, and for lengthy projects you also need incremental "milestones" during development, to keep things on track and (much more importantly) to be able to realise when you're falling behind.

Having these sorts of deadlines helps you to end up with a realistic feature list to match your development schedule, and ensures that you'll always have short-term goals well thought out.  And finally, they provide a built-in "date on which I must let go", which can help enormously for those of us who have trouble ever considering their work to be good enough to release.

^ I feel like that makes a lot of sense, but it might only work with certain games.

i think donelines are more important than deadlines -- milestones w/ a list of things that have to be done for that milestone, but no set date, because it's usually impossible to predict how long something will take to finish.

one thing i've found which works is keep a public development log, and update it every day with what you did that day. i've been doing that for the last two months in my livejournal for my game, and it's improved progress a lot -- not only in me, but in some of the rest of the team, since they see that progress is being made and don't want to seem to be doing nothing by comparison

It's not impossible, it just takes some practice to get good at it. 

When setting deadlines, you want your incremental milestones to be about six weeks apart, and to have lots of different things lumped together in each.  That way, if one task takes longer than you planned, then it's likely that one of the others will take less time  and your milestone workload will balance out overall.  Remember that you want to include slack time and debugging time in your considerations as well.  The larger the team and the more complicated the project, the more slack time and debugging time per person you want to allow for.  My general rule of thumb when you're new to this sort of estimating is to take your best guess about how long a task will take to complete, multiply that guess by two, and then add one.  (And that final number will probably still be a bit low, but it'll at least be within spitting distance)

But yeah, the first time you do this for a project your numbers are probably going to be way out.  But you'll get better at it as you do it more often, and learn your own and your team-mates' work habits.

And do remember that there's no problem with overestimating how long it'll take to complete something;  if you say that it's going to take you a week, and it ends up taking you two days, then you're ahead of schedule and can start on the next milestone's stuff early, or can work on polishing or take a well deserved break or do whatever else strikes your fancy.  But it can be really useful to know early when you're falling behind from where you need to be in order to finish your game on the date you wanted, so that you can decide whether to move your finish date or to change the project requirements in order to try to catch up.  It's far better than just arriving at that finish date and wondering how you missed it by so much.


But again, I don't recommend scheduling milestones for projects that are going to take less than about six months;  they're not worth the time investment for short-ish projects like those.  But they're totally essential for long projects, and projects with lots of team members.

well, i've been making games for around 15 years, and am still not very good at determining how long a particular part of it will take. mainly because my own motivation and free time is always in flux.

When we do a project at my company (I am head of development at a virtual worlds company) there are always estimations of development time written down and agreed to by the team. Estimations need not take the form of a date deadline, a estimation of the number of hours/days/weeks/months a project will take are equivalent or better (esp in the case of hobbyists). They needn't be written down either, though I've found written estimations are followed better by both myself and by others.

There are a couple of reasons to do estimations, even on short internal projects. Firstly it provides some focus, a desire to meet the commitment even if that commitment is to ourselves. Secondly and perhaps more importantly it improves our team. If we think something is going to take a week and it takes two something went wrong. Without that estimation will the team realise something went wrong? Perhaps but the estimation ensures it is noticed.

A debrief aiming at the root causes of the issues will then help address the problems so they aren't repeated (read http://startuplessonslearned.blogspot.com/2008/11/five-whys.html for an excellent debrief technique). A debrief isn't about assigning blame, rather it is about forcing you to look at how you work and what you can do to improve things. The estimation itself may be found to be at fault, which is fine as estimation itself is something that is improved by this process.

With creative and open ended processes (that indie developers encounter all the time) estimations work just as well. You can estimate how long it will take you to come up with a number of ideas, then estimate how long those ideas will take to test/prototype then estimate how long it will take to fully polish the chosen idea. This is process is reflected in the "The Cult of Done Manifesto" linked to by Alec. A focus on drafting, throwing things away, and getting feedback means you spend less time polishing turds and accept failure.

This touches on a couple of the areas I am covering in the workshop (planning and the creative process). The other part of it is leadership and working in a team which are very important skills that many of us fail at.

btw http://startuplessonslearned.blogspot.com/ Lessons Learned is an excellent blog that has many concepts that have applications in indie development (whether you are in freeware or commercial development).

This is exactly what deadlines solve. :)

If you have a set date to accomplish some goals, you MAKE time. You feel motivated to get it done. Your other schedules then flux around the game, and not vice versa.

If there is no finish line in this footrace - everyone walks. And not all in the same direction.

i guess i don't really see it as a problem to be solved. i think it's important that the creative process have ebbs and flows, periods where a lot is done and periods where little is done. i.e. it's better to not do anything than to force yourself to do something, because the quality of what is forced will be less. i think it's a good idea to work on one's game every day to keep the momentum going, but i don't think you should work on your game an equal number of hours every day -- some days i work on it all day, other days a few minutes, and that works best for me.

an analogy can be made with creative writing -- if you have writer's block, it's a bad idea to try to force yourself to write x hours a day if nothing is coming out. it's a better idea to take a break and do something else until you're ready to return to it. a writer who can write a set number of hours a day every day and plans out the order that they're going to write something in usually turns out very mechanical-feeling works. deadlines seem more appropriate to tasks which can be predicted, like building a hut or digging a well, something where there's a clear correlation between hours worked and finished product. that may to a degree apply to the programming aspect of game development, but not to the design aspect, and it's the design aspect i spend most of the time on (even though i'm also the programmer of the games my team makes)

Our societies view of the creative process is poor in my view (this is not making a judgement of your ideas or processes just in general). For example Michelangelo must have sketched the Sistine Chapel several times over. The artists I work with put in a lot of hard yards sketching, producing wireframes and deleting a lot. The point is that creativity requires a lot of work and false starts and there are processes that allow you to bring about creativity. Just like other disciplines require research, planning and prototyping so does design and art.

As there is a fairly standard processes an experienced artist/designer goes through (standard for the individual, they all do it slightly differently) it allows one to estimate and plan. That said I often find it difficult to pin a artist down to make an estimation. I think it may be due to the conundrum that they know how much time they would like to spend on it (as much as possible) and how much time they *should* spend on it. Though this is probably true of programmers so perhaps it is an education thing; more thought required there.

All of this isn't for everyone though. I'm coming from a business background where you must work to a schedule and deadlines. This needn't be true for indies, the ones not trying to live off their games especially. However as an aid to producing I find it invaluable to set estimations on the attainment goals, even if those goals are just personal ones. Knowing where you are is all about knowing where you have been.

Great talk Rory, thanks for speaking. Oh, and the name you were looking for is Jason Rohrer.  ;D

Yay thanks. My public speaking can only improve but I'm pretty happy with my effort. Next time! :)