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

Experience report: Building an offshore agile team in India - The Australian perspective - Part 1

Experience report: Offshore agile teams – An Australian in India’s perspective Offshoring software development, in this case, using agile as a software development methodology contains many opportunities to learn. These kinds of teams have specialised requirements both in the technical realm as well as social expectations on the individuals hired. A lot of organisations have tried, and failed in a lot of cases, to set up independent agile teams in India . With the right approaches and expectations set, Aconex has shown that it is possible to successfully set up agile offshore operations as we did. To get your offshore program on a sustainable footing you’ve got to understand the market and be prepared to be responsive to local conditions. What sort of people are/were we looking for? A simple explanation would be, agile software engineers and product people with a desire to work in self managed, highly collaborative teams. We use the terms ‘passionate, self-starter, indep
Read more

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

Building agile teams in India: Part 3 - challenges at the hiring stage (especially for a fresh face in the market)

Part 3: Constraints/Challenges of building a ‘boutique’ agile team in Bangalore/India (especially if you’re an unknown in the market) Low brand recognition In India, brand is seen as really important for a lot of candidates even in 'considering' an organisation. Family recognition of the organisation is seen as very important to candidates, acceptance of the organisation by candidates parents is often a key factor. There is also evidence that candidates enhance matrimonial chances by joining a known brand, I've even had conversations that dowry can be increased dependent on the name of the company.  All of this leads to an uphill challenge for smaller organisations, however: The candidates that do join you are joining because you've sold the company culture and challenge well, which increases loyalty/retention. Also, working on brand building is shown to pay off over time, hence partly an answer to the question of “Are you ready for this to take ‘x’ ye
Read more