Rough Sea Games

As promised, this blog will include some thoughts about development processes and their impact on teams and projects. Today I will write about scrum and extreme programming (XP) for distributed teams, because at the moment we are one of those teams.

Scrum is a well known and currently very popular agile project management process. XP is a technical process, for programmers, and is also an agile methodology. The basics of Scrum are summarized in this great video from Kent Schwaber. If you looking for a good overview on XP check the Codebetter.com blog. More info on Scrum and XP can be found at the Agile Alliance Website and Mike Cohen’s blog.
I know both processes quite well, read all the available books, and have had the great opportunity to build up a team using these agile approaches at full scale.  The team included some offsite workers, but that wasn’t too hard to organize.

To implement Scrum and/or XP in a team which does not share an office sounds almost impossible. Everything in agile methodologies relies on communication and transparency. A distributed team talking over e-mail/ICQ/wiki normally has difficulty communicating, and most team members have almost no idea what their colleagues are currently working on.

I will tell you what our team has done to improve communication, and why it is currently working like a charm.  I have to admit that all team members know each other and are quite experienced. All of them have used Scrum and XP methodologies before.  So the techniques described might not work for new teams which have never worked in an Agile way.

Step 1 – a wiki substitutes for the daily Scrum

We established a wiki as our major communication platform. WOW! That’s magic, isn’t it?
Well, the magic is not in the wiki itself, it’s in the motivation of its participants. If the team doesn’t update the wiki several times a day, it becomes absolutely useless.

Every day, I post the latest technical and business news, and all team members, including me, write an update on their current tasks.  We still write e-mails and chat over ICQ, but most important communication happens in the wiki. It contains our business plan, the product backlogs, the complete (and current!) game design, helpful FAQs, various artwork and brainstorming thoughts. We even track our work hours and expenses in the wiki.  We are still trying to improve our communication processes, but for now it’s working out quite well.

Step 2 – removed sprints, and introduced stories as mini sprints

We are currently working part time on our project, because we are still looking for an investor. People work in their free time on weekends, vacation days and so on.  At first we tried to fix sprint timelines to certain dates, but that didn’t work at all. Working in your free time with (arbitrary) deadline pressure is horrific and far too much stress for everybody, so we skipped it.

Instead, Rafael put together a backlog in which the core game mechanics are written down as stories with acceptance tests. Stories get estimated by the programmers — not in a planning game, unfortunately, but the estimations do work out, because the team is quite experienced. It is very important that the stories do not exceed 2.5 points (most of our stories have 0.5 to 1.5 points). One point is a perfect day, so you need 2.5 perfect days to complete a 2.5 point story. This might take up to 2 or 3 weeks, depending on the time available. So the size of the story is important because of motivation issues: completing work in a short time gives you a very good feeling.

Step 3 – sprint demos are done for each story

We have always a working build and our designer is able to update the svn repository whenever he wants to. After updating he just has to start FlashDevelop, press F5 and can play the game.  As soon as somebody moves the story to the “completed” section, Rafael checks the story directly in the current build and adds a comment if something has to change. If the change request is too big,  Rafael writes another story and adds it to the product backlog.  This works absolutely great so far; thanks go to Rafael for doing a fantastic job here!

Step 4 – established test driven development from the start

Fortunately there are some open source frameworks for Actionscript 3 which support test driven development. We are currently using one of them, which Manuel has improved a lot in the first weeks of the project.  Maybe Manuel can explain what he exactly did in some of his future blog posts.

We used TDD from the very first moment, and it proved to be a good decision, because it helps us to have very stable builds. Having a stable version of the game is a must for distributed teams, because it will highly affect the motivation and performance of the team.

To be continued…

So I guess that’s it for today. There is a lot more to say about this topic, so I will write part two in the upcoming week. I hope you enjoyed this post and are able get some valuable info out of it.

Cheers,
Matthias

Popularity: 6% [?]