The body of knowledge on agile software development is fast-growing both in academia and industries. Many conceptual frameworks, tools and techniques have been developed over time. I think it is vital for those who work and/or are going to work in game industries to master agile software development (and agile management~). So, I’ve invited Dr. Mark van Harmelen to lead a session on agile software development for the CVG 1 students on 4 November 2010.
Mark then introduced the concept of “facilitation”. He said that agile software development is usually carried out by a self-organising team, which, in a particularly pure form, would appoint a facilitator rather than have a manager. The team members learn together; their goal in leaning and spreading knowledge within the team is to achieve greater delivery capacity.
Determined to end the culture of competition prevailed in our society, Mark’s approach focused on building a learning culture within a team for carrying out teamwork with an ultimate goal of maximising a team’s delivery and implementation capacity.
Agile software development (usually test-driven or behaviour-driven) is a good method for dealing with changes in game development processes where changes are inevitable (e.g., user/customer requirements, emerging ideas). Agile development recognises that increasingly there is a fuzzy boundary between customers and the development team, thereby it integrates customers into the development team.
An agile development processes comprise many iterative steps, including iterative interaction with the users, and the repeating design-develop-implement-test cycle. A common iterative span is 2 weeks, but between 1 and 4 weeks are normal.
Mark facilitated a teamwork session with the students. The task was to collect requirements for a RPG menu following the format –
As a _game player _, I want to _use a RPG menu_, in order to _choose a character_.
Students needed to put themselves in several different positions (e.g., game player, developer, publisher), and jotted down as many statements as possible following this format. And after every team member generated enough statements, the team started reviewing all statements and ranked them against popularity and feasibility. Design concepts then emerged during the brainstorming discussion.
Being agile means no definitive way of doing agile development. But developers usually have a retrospective session. Mark asked students to review their team working experience, discuss their team dynamics, and come up with some solution to improving their interaction.
Physicality appeared to be a popular theme emerging from students’ group discussion. One team decided that a member only had the right to speak when a ball was passed on to him/her. In so doing, the team avoided talking among each other.
Another team found themselves hard to concentrate. They kept being distracted by the window view over a car park in the vicinity (Don’t ask me why – I was also wondering how this could be a distraction). And they said they needed a facilitator to keep them focused.
The session ended in lots of laughter. Well, there’s no better way of learning than being happy and being passionate. Mark has succeeded in facilitating a fun learning session.
Thank you, Mark.