Much has been written about the difficulty of using Agile software development methods in distributed teams. Some thoughts are that the obstacles are so great that Agile can never work; others believe that, whilst communicating is challenging, the other benefits of Agile outweigh these difficulties.
We use Agile methods to manage software summer camp software development and, personally, I prefer Scrum to many others as a management tool to track progress. With all Agile methods, communication is key and this becomes harder the more geographically distributed the client, team and other stakeholders are, but there are ways around it.
In my case, here’s a prime example. One of our clients is based in the East Midlands of England, their Tech Lead is based in London (as is my Tech Director), me – the Scrum Master – I’m on the south coast of England and our development team (who also provide support to the live application) are in India – couldn’t get much more distributed if we tried! Those in the “all too difficult” camp would never have taken this project on, which is a shame as they would have learned a great deal about managing distributed teams.
Let me take you through a typical day:
First let me set the scene. Our development and support team are based in India, 5½ hours ahead of UK time. This provides the first of the challenges – the time zone difference. Given that the client is UK-based and that we need to support their live application, the team in India have adapted their working day. They arrive later in their morning and work on into their evening to more closely align to our working day. This still means they start work a few hours before us but, apart from the support team (who provide 9am – 5pm cover), wrap up before us; this works for us and we adapt our hours on the occasions when we need to work on a particular problem or issue. One of the advantages of this is that it extends our development day – the team can be working on a problem overnight and present a solution for when the client arrives in the office in the morning.
At the start of my working day, I’ll firstly check emails to see if the development team has sent me anything overnight which needs urgent action. At the same time I’ll log into our chosen IM tool, which we use as our primary real-time communications media. I can see who is online and contact them quickly if we need to discuss any overnight issues; conversely they can see I’m at my desk and contact me. By this time the client’s team is normally logging in and, again, we’ll catch up on any key events or issues.
Our Product Backlog and Bug Tracker are managed in a project Wiki and this provides us all with good visibility. I’ll run through this and look through anything new, discussing any key points with my Technical Lead in India.
We have a well defined Release Management process and this starts with the pre-Sprint Planning meeting. As Scrum Master I’ll facilitate this and we’ll conference call to bring everyone together. This usually involves me, the development team and the client’s team. We all have the Product Backlog open so we can quickly run through the items to go into the next Sprint. Conference calling brings it own challenges when you can’t see those involved and at first it took a while to develop a conference rhythm, but we know each other quite well now and so have picked up the nuances of each of the callers. I’ll lead and, as we run through the call, I’ll constantly confirm the understanding of all involved. This normally takes an hour or so and, once done, I’ll follow this up with a very quick “actions list” email. Once we’ve finished the conference call the offshore Technical Lead will discuss the items with his team and then produce the Sprint Backlog, which he will share with us all.
Our Daily Scrum is a virtual meeting and is normally held at 2.30pm our time. Again, we’ll use conference calling and every team member in turn has their opportunity to update us. This meeting is ring-fenced at 15 minutes and actually I’ve found that it’s easier to keep to this timing in a virtual meeting rather than face to face, when it can sometimes be difficult to stop people talking. We have deviated here slightly from the normal Scrum rules and, if getting everyone online proves a problem, I’ll get the offshore Technical Lead to produce a (very simple) Daily Scrum written report – but I still insist on every team member completing a section for their area of work, which must remain unedited by the management team. Not strictly within the spirit of a daily stand-up meeting, but it works for us with a distributed team.
Daily progress is managed via the Sprint Backlog & Burndown Chart, with each team member updating the effort remaining for each of the tasks they’re working on. We’re constantly looking at how to improve our information sharing with a distributed client & development team, something I always raise during the Sprint Retrospective.
When it comes to developing and reviewing the UI, this is made more difficult by our geographical locations. We use an open source desktop sharing tool as it’s simple (no download software for those joining in) and free. This allows the UI designer to share his desktop with all those involved with the review and we’re able to easily walk through the design; it also allows reviewers to take control and mark up certain areas of the UI in real time to show what they are looking at. Again, we use conference calling during the review and we constantly confirm the understanding of all involved.
