Monday, 30 May 2011

University time is busy time: Group Work

An academic year goes by real quick when you've got a lot of coursework to hand in.  Almost of all it group work  Some idle thoughts about group work beyond the jump.

Teams needs leaders, leaders need teams

Luckily my group came to a decision rather quickly and amicably about who should be in charge.  Some groups did not and it showed.  With only 5 people the leader role is a minor addition as opposed to a full time task, but fail to assign the right person and disaster inevitably follows.  Luckily we worked together amicably and me as leader seemed to suit us, and so we are all still on the course as a result.  Teams without leaders or with people determined to do it all by themselves rather than as a group always had problems.
Video game development demands multiple people to get it done.  If you think you can do it all by yourself or without someone to lead the project, be prepared for a hard life.

(As a side note I found leading a team to be more interesting and fun than I was expecting.  So perhaps I should put producer up on the blog instead of designer.)

Work together not apart

I made the fatal mistake of letting people do the work in their own time and used a quick check up meeting to see what progress had been made.  Despite better access to programs (and computer power) at home, working separately ensured that no one felt compelled to get stuff done.  When my INTROG group worked apart we picked at our respective problems, together we managed to blitz our way through problems.
Setting aside days or multiple hour workshops seem like a better way of getting stuff done.  As a corollary, planning around these meetings ensures that you make games based on what allows you to work together rather than apart.  We would never have picked UDK, a programming necessitating high power computers, if we wanted to work together in person.

Research and planning
Its always worth spending some time to look at other options and planning stuff beyond technical issues.

Don't just stand their do something
Start early, as early as you can.  Getting stuff done at the beginning means you have enough time to polish rather than just fixing, or in our case ditching features until we could get to a (sort-of) working prototype stage.

I really hope future me remembers this list.  If nothing else the various RTGROP and INTROG groups that failed should remind me of what awaits me if I don't.

1 comment:

  1. Wish you luck with the team. I was recently promoted myself to team leader, and I must say it requires quite a bit of subtle effort to actually do it right. Read an interesting book on this matter, called "Are leaders born or made?" by David Grabovac where he gave some really neat tips on leadership, as well as examples of leaders throughout history. Hopefully I'll do a good job.