Re: tasking
Adam Martin <adam.m.s.martin <at> googlemail.com>
2007-04-02 13:02:08 GMT
On 02/04/07, Kent Quirk <kent_quirk <at> cognitoy.com> wrote:
> Richard Fabian wrote:
> > I think this is probably the best place to submit this, as the
> > audience is right, but something in me thinks that it's verging on
> > "off-topic"
> >
> > Our producer has asked me to help find out of there are any software
> > solutions to a problem we are facing at the moment, and have faced on
> > every project we've worked on.
> > The programmers are happy building lists of tasks, assigning staff
> > based on capability and favourability, moving dates around after
> > assessing critical paths, overallocating and looking after when things
> > need to be done in time for other departments and requesting things to
> > be done by a certain time from them too... but no-one else is happy
> > doing all this "scheduling" and is saying that it is the producers
> > job. Unfortunately this isn't possible as the producer is not "games
> > industry", and doesn't innately understand some of the implications of
> > certain elements of game development and we've seen some horrific
> > gaffs because of an unnoticed dependency or a task that makes no sense
> > (its like production through a "chinese room" engine).
The simple (read: cheeky) answer would seem to be (given you say you
have this problem on every project) - why do you keep hiring the wrong
person for the Producer role? You yourself say the team expects the
producer to do this, but you've got a producer who doesn't.
Either they're right, and you need to get an appropriate (not
necessarily better or worse, but just "correct for the job") person
instead, or they're wrong and you need to find out why they have this
belief and then deal with it. IME usually if the team is wrong about
something like this (e.g. being unreasonable) then there's a more
subtle underlying cause that you can find out within half an hour of
talking to people - the same issue will keep popping up from short
conversations with different people. Again, IME, that's usually an
inexperienced direct manager or a malicious/incompetent indirect
manager (e.g. "our team's fine, but every time we try to do this, we
get screwed by Team Y [who are doing it because their manager has a
secret agend of their own]") somewhere.
> >
> > so, the question really is: is there any software or peopleware
> > process that will eliminate all the innadequacies of the system we
> > have at the moment. We were hoping for some nice dependency driven
> > todo list software or something, but we'd be equally happy with a
> > peopleware method of fixing our problems.
>
> If you're in the mood to take a look at your process, you might look
> into Scrum. It's been known to work in a variety of situations.
(if you're still reading this, after my slightly tongue-in-cheek
comments above ;))
I second SCRUM as an excellent thing, BUT: it's very much *not* a
panacea, it only solves a certain set of problems, and even then it's
a very "junk in, junk out" kind of solution: you can follow every rule
to the letter, and yet find SCRUM makes things no better (in fact
worse even) if you fail to internalise it on an individual level. I
think the quote Schwaber uses often is "it's business as usual",
meaning that teams adopt SCRUM, but then carry on acting in the ways
they used to, thereby entirely devaluing SCRUM. SCRUM is more a
mindset than an actual PM methodology. That can be hard to accept, so
be careful not to adopt it naively.
Given the way you describe the team, it sounds like they may certainly
benefit from using SCRUM. Sounds like a good match. But ... if they
have a problem with a manager, that person could easily deflate SCRUM
if they don't themselves internalise it.
> And if you're seriously interested, get Ken Schwaderer's book. It's
> short and simple, but it explains the process and the pitfalls pretty well.
Yeah - the first one (there's a few others now, IIRC - all good, but
the first one is the one you need to read first :)).
Also, I recommend the IGDA Production SIG mailing list - free to join,
and then when you're on there go to the archives (have to be a list
member first) and search last month and the couple of months before
for SCRUM conversations. There's been a few recently, with a lot of
good links and commentary.
Finally ... anyone here who's doing SCRUM or thinking about it for
games dev, I'd love to talk to you. I've done it before for small
teams (<10 people) and I'm moving a whole studio over to it now - I've
spent a lot of time tracking other recent studio-wide adoptions (e.g.
Bioware, Sulake) but would love any additional advice or warnings, and
would be very interested in some mutual support with anyone else who's
going through / about to go through a similar conversion at the moment
:)
Adam
_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
RSS Feed