Re: Scrum for Games Development
- --- In firstname.lastname@example.org, "Graeme Monk" <bigg@a...>
> I still have a problem wherebythe
> management still want a day to day input on the project and cause
> team to stray, which I understand is a problem with changing fromthe
> more traditional approach. I also recognise this as a failing on myI assume that managment is one/the source of your features?
> part, hence signing up for the course.
If you run short sprints, management can have input to the Feature
Backlog daily if they want, without upsetting the Sprint, and can
replan the Sprint Backlogs regularly (some people run 2-week
sprints). Once they understand that they can rearrange the Features
in future sprints, including tweaks to prior Sprint features, they
might just be happy to leave you alone for two weeks.
In our case, our verrrry insecure customers settled down fast, once
they realised that their requests were absolutely not being lost or
shelved. They explicitly said - no, it's ok, we can wait for that, we
know we'll see it on the list again at Backlog Planning time. The
Product Backlog is visible to them at all times, in fact it is
THEIRS. This is very reassuring.
Also, they get to see working code demo' (say, every two weeks) so
you are less likely to throw out 6 months of work. This is a big
selling point - if they are really paying attention, you could only
be throwing out one Sprint's work, which is not so bad.