Running an agile project with distributed teams

I am currently working with a large team doing software development. Whilst a lot of the lessons we learnt apply to any team, doing anything in multiple locations, our team just happened to be following agile practice. As a result, a lot of our learnings where on how to apply agile principles (both process and technical) in our situation. Half our team is in Melbourne, Australia and the other half in Hyderabad, India. I thought I would share how we work together. Mostly, we work well, however there are some things we would do differently or that still puzzle us (see what I did there).
Tools of the trade
  • Skype for text chat between teams
  • Skype for daily stand ups (voice)
  • Google docs for planning sessions - great for sharing and live editing with the teams in multiple locations
  • Jira's greenhopper plug in for our virtual board at stand ups, I've also seen teams use Mingle, Trello, whatever as long as we keep the damn thing up to date

Our daily activities
  • 9.30 am, Melbourne team stand up - 15 minutes
  • 2.30 pm, All team stand up (via skype) this is (I think) 10am Indian time, traffic is pretty bad in Hyderabad so we make allowances for that.

Sprint activities Sprint length is 2 weeks, these activities are typical of a standard sprint
  • Pre-planning in Melbourne (normally 1-2 hours) - Tech lead and BA and others (sometimes 'others' are optional) determine whether we know enough about the stories to go to an ALL team planning
  • All team pre-planning - normally 1-2 hours once a sprint, were we present the stories for the next sprint to the Indian team. Discussion is on clarifying requirements and details of the stories. The Indian team than take the stories away for the own estimation and commitment for the next sprint.
  • Demos - typically done to the Melbourne office by the Melbourne team. In the what didn't work section, I've gone into a bit of detail about this.

What works well
  • We worked for a long time to ensure there was technical leadership in both teams and a shared sense of design.
  • We make sure we visit each others offices as often as possible, 3 visits in 12 months and one on the way (I'd love to do it more often). It's important that the visits go in both directions.
  • We worked hard to ensure the outsourced team (in India)felt they were able to challenge decisions made in Australia. This was a long term project, but to their credit, the guys in India have, for the most part, found their voice in our stand ups.
  • Do enough planning to ensure the team away from the product folks have work to carry them through the time zone difference. Planning is perhaps one of the biggest pains for any distributed team
  • Doing those standard activities like, daily stand ups and combined plannings. Yes its hard to work out, but without that constant communication it's easy to get off track.
What doesnt work so well
  • Administration - especially for our BA, is huge, we have multiple places where we need to keep things up to date, especially backlogs. It is a full time job and in agile projects things change so quickly our BA, Gretchen, is often scrambling to keep up, which she does well to her credit
  • Underestimating the cultural differences between our teams.
    • We are constantly surprised by the subtle nuances of communication, and have learnt the hard way that 'yes' can sometimes mean 'no'.
    • Made all the harder by the tyranny of distance. We have worked hard to understand each other and we are getting better.
    • From the other side, I suspect the Aussie penchant for testing someones argument by challenging it, or taking an opposing view to what we actually believe gets lost in translation. This leads to misinterpretations of our intent, the Indian team thinking we believe something we don't.
  • Not doing enough cross team visits, I know earlier I mentioned this works well, the reality is we don't do it often enough. The friendships and understanding that are built up by face to face meetings can not be underestimated
  • Our tech lead here in Melbourne has had to make superhuman efforts to keep the project afloat. We have finally got some equality in tech ownership between the teams, but he is still our single point of failure
  • Having multiple boards, we could of course reduce them, but I love a big visible board and we have to have a shared electronic one so we wear it
  • Demo- we havent really had great success in demo'ing as a unified team. It kind of fell into the too hard basket after technical glitches caused by slow network speed. We've probably been a bit lazy and let these slide unfortunately. It's reminded me to try and kick them off again
What puzzles me
  • How, despite all the differences, obstacles, distance and time zone differences, it seems to work really well, most of the time


Popular posts from this blog

Using an agile storyboard as a scale of certainty

The surprise of reverse culture shock. Returning to Australia as a NRA.

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.