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

Comments

Post a Comment

Popular posts from this blog

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

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

Image
Earlier this year I ran a survey around ‘release processes’ specifically with companies that follow agile practices. I promised that I would publish the results and apologies for the delay, I have collated the responses below. Thanks to everyone that participated, really appreciate your time and energy. At iflix we're always looking to improve our release processes so it was really great to get so many good responses. We learnt we're not that far apart from our peers out there. We've got a lot to learn of course, some of that comes from hearing from others and some from the mistakes we make. The trick is to make your mistakes small ones and learn fast with minimal disruption to your customers. This survey was run at least 5 months ago, so it’s a snapshot in time.  Most places I have worked change their processes (inspect and adapt!). I've reproduced the responses in their entirety, so it is a bit of a long read. I’ve anonymised the responses somewhat, retaining
Read more

Mission Orders, 6 military principles that can work for agile teams

Yesterday, I was watching a documentary on the "Battle of the bulge" A famous battle in World war 2. The docu makers were investigating German tactics during the battle. Specifically, tactics which had worked so well early in the war, over extended periods of time, towards the end of the war, fell apart after 3-5 days. Early in the war, German officers had Mission Command, that is, Hitler and high command had high trust in their teams. As the war went on, and things started to go wrong, mission command was gradually eroded as trust fell (especially when his officers tried to kill him). Mission command basically means, set the goal, let the teams be responsible for how they are carried out. Training is centred around this, discipline and training carry you through the unexpected, as long as you know the end goal. Effectively, the German high command no longer trusted the lower ranks, and only gave them enough information, goals etc for the immediate goals and set them
Read more