A Case of Agile Game Development in Korea: MAIET Entertainment

This is the English translation of 애자일 게임 개발 적용 사례.

Note:

• At this point(May 2nd, 2007), MAIET Entertainment is the only game developer acknowledged using Agile game development in Korea, although there is a rumor telling that other several companies like (some teams in) NC Soft are using it.
• Don't hesitate to notify me broken English in this translation.
  

I presented the case study of my project by using Clinton Keith's Agile Game Development translated by Kay Kim and Chang-joon Kim's Agile culture before Dev Rookie's members on  last Sat. (2007/04/28)

Issues;

• Adopted Agile methodology(esp. Scrum) since Nov. 2006.
• Started small. (Never try to convert the entire studio overnight.)
• Adjusted Agile game development to our team, not followed it as dogma.
• Not forced team members into Agile game development.
• Tried to build Agile culture first: planning game, penalties, seminars, changing roles and analogue practices.
• Didn't focus on doing Agile practices, but making a fun game.
• Continuous trials and errors.
• Trying to raise the frequency of using Pair Programming and TDD

Scrum;

• Team size: 10 programmers.
• Customer: the director of our own.
  
• Sprint length: 1 month
• Sprint planning meetings
• Daily scrums
• Reviewed user story every Mon. Short demonstration.
• Sprint review
  

Challenges;

• All the members were not good at Agile game development. (Never trained before.)
• Had difficulty estimating
• The scrum team wasn't self-contained. No participation of game designers and artists yet.
• Less efficient user story reviewed by the customer: caused frequent redos on completed user stories.
• Members' low motivation toward Agile game development.
• Communication is still a problem: we need to talk more.

It's almost same as the thing from How to Schedule a Montly Plan, but something were changed;

• Programmers and game designers wrote user stories together.
• Wrote detailed tasks of a user story on post-it and post next to the user story.
• A person in charge of each task wasn't defined in advance, but just before the task began.

Actively utilized a white board and a post-it. The picture above is a scene from  the game design discussion that I, a game designer and a programmer attended.

You can see detailed information about the picture above from Our War Room. The upper part of "Done!" is about the completed tasks in this iteration and the lower part is about the last iteration. Planning "To Do" for this iteration was meaningless for too frequent changes of "To Do". So, we decided to list only the completed tasks in this iteration. (Once we had reported what each team members did in the last iteration, but we replaced the report with the list of completed tasks.)

Added the day tasks began and ended post-its including description, memo, worker, estimates and priority.

The burndown chart of Feb. 2007.

Its velocity was 2.3 based on five-day-iteration, and the problem is unstable velocity.