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: 3% [?]
Loading tweets...
7 comments
1 ping
René says:
September 30, 2008 at 10:24 pm (UTC 2 )
You might have a look at the folks at objectmentor.com to get more information about XP. Uncle Bob’s comments and books really made me a better programmer throughout the years. He influenced me more than any other author out there. And don’t forget to visit Ron Jeffries site at xprogramming.com (especially the software page is noteworthy when you are into TDD)
BTW: nice idea Matthias. Would be nice if you’d give me a call sometime.
Matthias says:
September 30, 2008 at 10:45 pm (UTC 2 )
Hey René,
great that you are watching our blog and thank you for your comment.
I will add the sites you talked about to our blog roll. Would be great to have a chat with you very soon. I will definitely give you a call! All the best!
René says:
October 1, 2008 at 1:34 pm (UTC 2 )
On a sidenote: if you are skipping the sprint deadline and not using a planning game it’s not called SCRUM anymore. I really don’t want to be a nitpicker, but it’s max. SCRUM inspired
I once had a long discussion with Boris Gloger about that issue. Why not use the normal procedure and adjust the points you want to achieve in each iteration accordingly. IMHO that makes it easier to talk about which impediments occurred. Are you using the team-effect in each iteration to its full extent ? Remember, SCRUM is a self-organizing process. Of course, if it really doesn’t fit than it is better to adjust the process than stick to it, since this is what agility is all about.
Looking forward to hearing from you guys!
René
Matthias says:
October 2, 2008 at 12:47 pm (UTC 2 )
René you are absolutley right, it’s Scrum inspired it’s not really Scrum anymore. Anyway I will leave the title because otherwise it might be to confusing for anybody else
.
As soon as we are working a perdictible amount of hours on the game, we will immediately switch back to sprint deadlines. The team is definitely self-organized; the methodolgy we are currently using is actually the outcome of the teams feedback, after completeing various stories.
Cheers,
Matthias
René says:
October 6, 2008 at 12:08 pm (UTC 2 )
FYI:
http://inside-scrum.blogspot.com/2008/09/erfolgreich-dank-scrum-oder-doch-nicht.html
Seba says:
October 8, 2008 at 9:26 pm (UTC 2 )
Heeey! Cherishing this already
Here goes some thoughts/questions:
1 – Daily Scrum: I like the idea of using the Wiki as a substitute for the daily stand up meeting and as an info hub. Does it also work in terms of quality of information relayed (typing is a bit more of an effort, compared to just talking) and commitment? Also, have you considered something like video conference, should the individual schedules allow?
2 – Sprints: Using stories as sprint goals seems like a sound idea. Yes, yes, it may not “technically” be gospel Scrum, but it does abide by the “inspect and adapt” motto, which is more valuable in my opinion.
3. – Demos: How do you do off-site demos, with developers in multiple locations? Do they all run the acceptance tests by themselves once a story is finished? Does Rafael do it and send a commented .avi around?
4 – TDD: I appreciate how you associated build stability with team morale. Good one!
Ahhh…. missing the gang here
Matthias says:
October 12, 2008 at 1:14 pm (UTC 2 )
Hey Seba,
welcome to our blog! I appreciate your suggestions.
1. Well, surly it does not have the same quality than a daily stand up, that’s is because nobody can look in each other face and hear the voices. I agree that video conferencing would be a much better approach, but as you already mentioned the individual schedules are a big problem at the moment. Anyway I will try t organize those meetings via webcam as soon as possible.
2. Thanks!
3. Normally every developer checks the acceptances tests, but Rafael will do this again and immediately write a comment if he is not satisfied.
4. Cheers!
Missing you too here! All the best with your current projects!
Scrum and XP for distributed teams (part two) | Rough Sea Games says:
October 20, 2008 at 10:47 am (UTC 2 )
[...] and XP for distributed teams (part two) Please check my last blog entry for the background to this [...]