Sunday, April 03, 2005
Agile methods define the roles of the customer and the developer very clearly. The developers don't work on anything that is not clearly defined by the customer. These definitions include specific user stories and acceptance criteria for determining when a requested feature is complete.
I saw the following diagram in Agile Project Management that clearly shows the relationships between the customers and the developers.
There are major benefits for both groups. The customers get clear control over the priority and definition of the features which determine product value. The developers get control over the mechanics of implementing the feature, including the schedule.
The developers don't get handed a 300 page document and a time-drame and budget to complete the game defined by the document. Every iteration they allow the customers to decide how they want to spend the iteration budget. If they request too much for that iteration, the developer let's them know in planning that they need to reduce the scope of their request. Once the iteration plan is made, the developers go off on their own to implement the stories without being disturbed with changed goals, etc.
Customers in the game development world are not only the publishers, but the designers and artists that will use systems developed by tech. Additionally design, art and programmers assume the developer role to polish and tune features (with programmers) to be accepted at the end of an iteration.
One interesting thing has come up with our R&D efforts. Since R&D will produce core tech that will be used by the production teams, the programmers that will use the product of R&D are the customers of that product. Having "programmer customers" and "programmer developers" trying to hammer out things such as intermediate file formats and APIs can be challenging. This is where having the CTO as the "Product Owner" of R&D comes in.
Saturday, April 02, 2005
This week we’ve launched our first XP iteration. While we’ve been using parts of XP for a while, this has forced us to consider some of the differences between XP and Scrum iterations/Sprints.
First, the rollout of XP has been pretty smooth. One concern was that the introduction of pair-programming and test driven development would meet a lot of resistance and suffer in effectiveness. This hasn’t been the case. In fact, it’s been embraced by people transitioning over to XP.
Part of this can be attributed to lessons learned over the last year. Creating our first generation data-driven engine for a finished game in 25 months had left a lot of loose ends. One of the biggest pitfalls of such architectures is the ability for bad data to cause problems unless you are really careful. We didn’t have the resources or the practices to be as careful as we needed to be. Pain is a great teacher and it’s clear that we need to embrace better engineering practices to avoid this in the future. With the successful application of one Agile method (Scrum), we’re more than willing to try out XP as a solution.
XP books say that you can roll out XP practices one or two at a time, and we’ve done this. Pair programming and unit testing were the first practices introduced. Now we’re introducing proper iterations (as we grow the first teams that need it). Clearly we have work to do in writing user stories and defining acceptance tests.
The good thing is that you can come out of an XP iteration planning “game” with a bunch of tasks cards and start doing Scrum as usual. There is nothing inconsistent with either practice other than the 2-week Iteration versus the 4-week Sprint. However both methods allow you to adjust your iteration time range completely.