Every one of the ~six talks I have been to has raised the topic of agile in a positive light. One of the most encouraging comments that I have heard was from Trent Oster from BioWare who said that the internal BioWare teams using Scrum show a 2 to 2.5 times improved productivity.
The "Leadership in an Agile Environment" roundtable was very crowded and lively. It was great to hear that their are many common solutions to the common problems that face agile adopters (mostly Scrum). Among those are publisher relationships and the confusion about long-term planning. I'll revisit these two topics in detail here soon.
One interesting thing to hear about is the topic of how much a team should change the Scrum practices up front. I hear a lot of comments like "we're doing a hybrid of Scrum and Waterfall". This seems to be a necessary phase for many company environments, but to me the jury is still out on how effective this is in the long run versus adopting full Scrum practices from the start and modifying them after they have been mastered.
Some observations:
- The lack of full Scrum adoption seems to cause some disgruntlement among the people who are enthusiastic about it.
- Many teams adopting Scrum don't send at least one person through certification.
- Teams that adopt full Scrum from the start have a great deal of success, but it requires someone in charge to champion the cause.
- How design and art fit into Scrum is a point of contention.
- "New Scrum fanatics" can turn people off with their fanaticism.
- Some folks on the team firmly oppose agile from the start. "It's the latest management fad" they say.
- Adopting Scrum halfway into a project creates lots of problems, but everyone who experienced these problems are excited to apply Scrum to the next new project.
Well done IGDA!
3 comments:
"we're doing a hybrid of Scrum and Waterfall"
Hah, I heard that a lot too. The fact is people have even less idea what Waterfall is like than Scrum.
Most game development teams I've worked on use iterations and some form of "organic" communication, which is definitely not Waterfall. Just because you write a design document doesn't make it Watefall all of a sudden!
No one is really using "Waterfall" to mean the original definition anyways. It usually refers to phased development that includes a planning heavy phase, some iterative development followed by integration, debugging and polishing at the end.
The point is that if these companies can't swallow the leap to agile all at once, there is some benefit in trying some of the smaller loop practices (e.g. daily scrum), seeing success and deriving some pride in that. It leads to further acceptance rather than an outright rejection of everything agile that you may see from an all-or-nothing approach.
Thanks for clarifying. Somehow I get the impression that calling it "waterfall" allows teams/managers to distance themselves from the fact that game development is by nature quite 'agile' by default.
Anyway, nice blog; I enjoy your insights!
Post a Comment