The Salt Lake Agile Roundtable meets the first Thursday of every month at the Borders bookstore in Murray, UT from 2pm to 5pm. These are my notes from the October, 2009 meeting.
Roger Booth asked about agile practices in the context of game development. I mentioned the article over on Gamasutra, A New Attitude To Game Engineering: Embrace Change, Re-Use, Fun and Jamie Fristom’s GameDevBlog as well as Schizoid from Torpex Games. Schizoid was developed using agile development practices. They key to any agile development technique is to use customer feedback and rapid iteration to guide the development. In the context of game development, feedback and iteration mean prototyping the game play and getting that in front of some test players and listening to their feedback on where the gameplay worked well and where it didn’t. Repeat that a few times and you’ll always have better gameplay than if you just proceeded with the initial conception of how the gameplay should unfold. Torpex followed this approach with Schizoid and came up with some really novel and fun gameplay.
Alistair Cockburn brought up an idea that’s been used by The Pragmatic Bookshelf to tighten the feedback loop and make iterations quicker. The Pragmatic Bookshelf folks use a feature of PDF files that allows a reader to provide feedback notes on a PDF at the point where the note is relevant. This gives the author context for the feedback that is natural for both the reader and the author. Alistair’s suggestion was to provide a way for the player to pause the game in the middle and provide direct feedback comments at the pause point within the game. This will give the game designers feedback as well as the context within which the feedback was given — the feedback mechanism can record the game state at feedback time.
Where I work we are engaging our community of users more directly in testing early builds of our releases and in defining features for releases. I brought up this scenario of “community driven development”, wondering how we can keep the community engaged and enthused over the course of several releases. Zhon Johansen mentioned that what we are doing is a form of crowdsourcing. Zhon suggested that we create contests with prizes to keep the community enthused and engaged. Kay Johansen suggested that we rotate people out of our advance beta team if they lose their focus or enthusiasm and rotate new members into the team. It was suggested that we actively survey our team members to find out how they feel about their participation and empower them to suggest improvements in the way we manage our external community team.
John Major asked about the downsides of dedicated teams. John proposed the idea that a small company may end up creating dedicated teams devoted to particular products as they expand their product portfolio. This created a situation where “teams are not fungible” in that you may have employees bound to a product instead of binding them to the most important economic opportunity facing the company. Where I work now, we don’t have engineers assigned to a particular product, we work on whichever product has a business need at the time. At previous employers I’ve seen situations where an employee is tied to a product by management and expresses frustration at working on the same thing all the time. I’ve also worked places where the teams were mixed up after each release giving employees a chance to work on something new each release. Rotating employees through products and technologies prevents the company from having all their investment in a product or technology bound to a single employee. If that employee quits, the company doesn’t lose a significant chunk of their intellectual property.
This discussion brought up the idea of self-selecting (or self-organizing) teams where people sign up for the projects they want to work on, regardless of whether or not its the same product/technology they’ve worked on before or a new product/technology. It was mentioned that if you have too many people sticking with the same thing for too long, then you may need to do a little manual mixing up of the people and their assignments. This is the “self-disrupting team”. The idea of self-organizing teams is discussed in Ricardo Semler’s book Maverick that was mentioned at last month’s roundtable.
We discussed the problem of bottlenecks in system integration and performance testing. We generally considered that the reason it was a bottleneck is because it was delayed to the end of a release cycle instead of being performed continuously throughout development. Naturally we recommended continuous integration, continuous performance testing and continuous deployment. If the performance measurement process is integrated into a regular routine, then its not a surprise at the end of the release cycle. The same holds true for integration testing. Zhon brought up the idea that some performance optimizations should be undone at the beginning of a release cycle because development is likely to shift the area that needs optimizing; the example he gave was related to database optimizations where they renormalized the database at the beginning of each release cycle. I found this an interesting insight because rarely have I seen previously applied optimizations questioned and re-evaluated in the context of code changes that happen in subsequent releases.
Jonathan House is a frequent attendee of the roundtable, although he wasn’t present in person this month. Jonathan often talks about a process he calls “pain driven development”. The theory is relatively simple: take what isn’t working for you and increase the pain levels for the team. Not doing enough automated testing? Crank up the pain on manual testing until the team itself reaches the conclusion: “we need to automate this!”. In the context of this performance testing bottleneck, it was suggested that perhaps what is needed is for the entire team to feel the pain of the performance testing bottleneck. If everyone is experiencing the pain, the team may solve the problem for itself instead of it feeling like one person or subgroup of the team is required to find the solution to the bottleneck. This led to an observation that “pain driven development” may not work effectively if there simply isn’t enough pain to go around to the whole team.
After the roundtable, Zhon gave me a Borders 20% off coupon which I used to buy a copy of GPU Gems 3. Thanks, Zhon. I had a chance to read through the foreward and saw that it was written by Kurt Akeley. Kurt and I both have EE degrees from the University of Delaware, although Kurt was a couple years ahead of me. When I was working at Evans & Sutherland in the early 1990s, Kurt asked me to be a technical reviewer of the OpenGL 1.0 specification. As a chief architect of SGI graphics systems through the 1990s and a key figure behind the creation of OpenGL, Kurt has a great perspective on the evolution of graphics hardware and the APIs we’ve used to control that hardware.