The document summarizes agile game development techniques used by a game studio. It discusses using short 2-week iterations for development, scheduling priorities with customers, small cross-functional teams, test-driven development, pair programming, continuous integration, and collective code ownership. It also notes improvements like minimizing non-productive time and further team self-organization. The goal is to discover important features first, improve code quality, and have a more robust process while maintaining a sustainable pace.

1. August 14-15, 2006 “ WALK IN” SLIDE

2. Agile Game Development: Tales from the Trenches Noel Llopis Senior Architect High Moon Studios Presentation/Presenter Title Slide

3. Coming up Agile Development Organization Agile Techniques Programming Agile Techniques Lessons Learned

4. PART 1: Agile Development

5. Motivation Unknown technical constraints Changing requirements Finding the fun factor

6. What is Agile Development? Maximize work not done Just-in-time decisions Adapt to change

7. Scrum

8. Extreme Programming (XP)

9. Others Evo RUP ...

10. PART 2: Organization Agile Techniques

11. Short Iterations Scrum suggests 30 days; XP 2 weeks. We tried both, and we're doing 2-week iterations. Each iteration attempts to create a true vertical slice . Use results to feed into next iteration. Yes, you can do a lot of work in 2 weeks (hard to believe at first).

13. Scheduling Customer == Person who cares about the ultimate outcome of what the team produces. Customers come up with priorities. Team estimates how long things will take and signs up for most important tasks in available time. Conversation between customer and team.

15. Team Composition Small teams (8-12 people). Collocated in open work environment. This is huge for quick discussions and communication. Originally only programmers; now, totally cross-functional. Scrum of scrums to scale to larger team sizes.

16. Who Does What Tasks are created and estimated by team People pick whatever task they want to work on Great for morale and spreading knowledge Careful how to deal with domain experts

17. Long-Term View We create working software instead of documents. Important to be in total agreement with publisher. Try your publisher. They may resist change at first, but then they realize they get to have more say in your project. Backlog Long-term planning; three-month release cycles.

19. PART 3: Programming Agile Techniques

20. Pair Programming

21. Pair Programming Is output 2× of what one programmer can do? Not quite. It's a bit less (1.6 - 1.8×), but it also has other huge benefits: Much higher quality Spreads knowledge & philosophy Promotes team spirit In the long term, it is a huge win

22. Pair Programming Not everybody likes it, but a very large number of programmers do. Some teams use it almost all the time; some other teams not as much. Another benefit: Intensity and concentration. You never have low moments, little breaks, or anything. You work 8 hours and you end up exhausted!

24. Test-Driven Development Check in Check in Write test Write code Refactor

25. Test-Driven Development Quick idea: test-code-refactor cycle All code unit-tested; written by programmers Design methodology Much easier to refactor/optimize

26. Test-Driven Development Unit tests are: Small Self-contained Fast Code doesn't have to be written with the future in mind. Instead, we can change when/if the time comes. Huge win! Never refactor for its own sake; always because we want to do something.

27. Test-Driven Development Get a unit-test framework (UnitTest++) Running on the Xbox 360 is a bit more challenging, but do-able. Need to be able to run a program, capture its output, and return code. Xbrun should really do it.

28. Continuous Integration Many small, very frequent check-ins (maybe every 3-5 minutes) As soon as any code is checked-in, build is triggered People are notified right away of any failed builds Unit tests are very useful for keeping things stable We use CruiseControl.Net—it's great!

30. Continuous Integration House rule: Nobody leaves without making sure his last check-in resulted in a successful build. The faster your builds, the better; so, pay attention to logical and physical dependencies (feedback time for normal checkins is around 10-20 seconds). Much slower for Unreal projects.

31. Collective Code Ownership Really means collective code ownership, not "no code ownership". Anybody is free to modify any code as long as it's because they're working on it. Really relies on unit tests and shared knowledge.

32. Sustainable Pace What's one of the big problems in the industry? Crunch time. Work as hard as you can, thinking of the long term. That means about 40-hour work weeks. Intense 40 hours, though! People come back refreshed and ready to do work. They also have the time to learn things outside of work and feed that knowledge back into work.

33. Automated Tests Unit tests from TDD are huge, but only part of all the automated tests. Functional tests: Test whole program or parts of it. Fully automated. Run them on the build server at least once a day. (We have them running every couple of hours.) Run them on your target platforms as well. Great for testing systems involving multiple threads

34. PART 4: Lessons Learned

35. How Is It Working? We're discovering the important stuff first Much-improved code quality More robust builds People are really happy

36. What Can Be Improved? Team composition How many resources are shared How to fully integrate people with different ways of working and thinking (programmers, artists, designers)

37. What Can Be Improved? Team self-organization Big goal of scrum. We’ve made lot of progress, but it can be taken a step beyond. Team needs to realize they're empowered to do whatever it takes to get their tasks done. Sometimes some leadership will still be needed

38. What Can be Improved? Non-productive time Scrum recommends 1 day for reviews and 1 day for planning. That's 2 days out of 10 “wasted”; even worse with multiple teams. We recently changed things to minimize down time, and we do reviews and planning on the same day.

39. Adopting Agile Development We have customized a lot of the standard scrum rules to fit game development. However, it's best to start with the default rules, try them in earnest, and go from there. Tweaking too many rules from the start can lead to wasted time and failed attempts. XP was easy to adopt without any major changes.

40. Resources Games from Within http:// www.gamesfromwithin.com Agile Game Development http:// www.agilegamedevelopment.com Questions?

41. © 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. DirectX Developer Center http://msdn.microsoft.com/directx Game Development MSDN Forums http://forums.microsoft.com/msdn Xbox 360 Central http://xds.xbox.com/ XNA Web site http://www.microsoft.com/xna End Slide August 14-15, 2006