Going Agile: Scrum in a fully distributed team

Working with a fully distributed team has made me appreciate the beauty of having face time with your team!  Hence, I took the opportunity at UDS to get more acquainted with my colleagues.

Scrum by DarkMatter

As a first part to introducing Scrum to the team, we defined the high level goals (or Epics) for the 6 month release cycle. Part of what I have been trying to figure out is how to use the tools we have at-hand to get started. For the 6 months sprint backlog, we finally settle on launchpad blueprints. We are basically using a planning project within Launchpad, that will have a milestone per sprint/release. By prioritizing and assigning blueprints against the milestone, we get the backlog view.

Back at Symbian, we started by setting up daily scrums and weekly iteration backlogs. However, once the machine had started we struggled to define long term goals. It is hard to get out from the 2 week mindset.

Hence, with HW certification team at Canonical, I decided to prioritise the longer term goals. This was made very easy by the regular cadence of Ubuntu releases. The next step was introducing daily scrums and a 2 week iteration cadence within the 6 months sprints.

Are you standing up at the other end of the line?

With a fully distributed team, introducing regular formalised communication seems on paper an easy win. However, the trick is in the implementation. How do you do it? We decided not to have IRC meetings, based on previous experience. Eventually,  people did not read the comments from others and waited until their name pinged in the IRC channel to post a pre-baked update.  Another option was to Mumble our way through it!

Mumble is widely use in Canonical, so I thought – why not! The first day was short of a disaster. At least 2 people from the team never made it. We had so many issues with headphones not working, that we finally started 10 minutes late – quite bad for a 15 minutes meeting.  I think Mumble is one of those systems that gets better the more you use it. So we will keep our weekly meetings in Mumble, but it didn’t cut the mustard for daily scrums.

Another point against Mumble is the global time zones.  It is great to use computer based systems, if your computer is already on, you are ready for your day and so on… However with people in Asia, US and Europe, the daily scrum is always going to be outside someone’s core-hours.  We settled on a phone conference bridge. So far is going great! We did fail victim to the different daylight savings switch-days between the US and Europe. Can someone explain me why, oh why!?

Iteration Backlog and Task Board

Having proven at Symbian that the all mighty Google-excel was able to deliver a usable Iteration Backlog, I proceeded to extended to host a Task Board.

The important thing is to remember what task board are about – visual aids! Ours is colourful and simple. It has a columns for  ID, Title,  Assignee, Not Started, In Progress, Blocked and Done. The last four are brightly coloured cells that can be easily copy&pasted. What can I say, it doesn’t beat the real deal but this will do for the moment.

Next episode – The Demo and Planning sessions!

3 thoughts on “Going Agile: Scrum in a fully distributed team

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s