A lot has been written about the difficulty of using Agile software development strategies in distributed teams. Some thoughts are that the obstacles are so excellent that Agile can never function; others believe that, whilst communicating is challenging, the other positive aspects of Agile outweigh these difficulties.
We use Agile strategies to manage software development and, personally, I prefer Scrum to numerous others as a management tool to track progress. With all Agile strategies, communication is key and this becomes harder the far more geographically distributed the client, team and other stakeholders are, but you’ll find methods around it.
In my case, here’s a prime example. 1 of our clients is based inside 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 offer support to the live application) are in India – couldn’t get much more distributed if we tried! Those within the “all too difficult” camp would by no means have taken this project on, which is a shame as they would have learned a fantastic deal about managing distributed teams.
Let me take you by means of a typical day:
First let me set the scene. Our development and support team are based in India, five? hours ahead of UK time. This provides the very first of the challenges – the time zone difference. Given that the client is UK-based and that we need to have 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 far more closely align to our working day. This still means they begin work a couple of hours prior to 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 require to function on a certain issue or problem. Among the benefits of this is that it extends our development day – the team might be working on a issue overnight and present a answer for when the client arrives within the office inside the morning.
At the begin of my working day, I’ll firstly check emails to see if the development team has sent me anything overnight which wants urgent action. At the exact same time I’ll log into our chosen IM tool, which we use as our primary real-time communications media. I can see who’s on the web and contact them swiftly if we want 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 typically logging in and, once again, we’ll catch up on any key events or problems.
Our Product Backlog and Bug Tracker are managed in a project Wiki and this offers us all with great visibility. I’ll run via this and look by way of anything new, discussing any key points with my Technical Lead in India.
We have a nicely 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 every person together. This normally entails me, the development team along with the client’s team. We all have the Product Backlog open so we can quickly run via the items to go into the next Sprint. Conference calling brings it own challenges if you can’t see those involved and at initial it took a whilst to develop a conference rhythm, but we know each and every other quite well now and so have picked up the nuances of every of the callers. I’ll lead and, as we run via the call, I’ll continuously confirm the understanding of all involved. This usually takes an hour or so and, when accomplished, I’ll follow this up having a really fast “actions list” email. Once we’ve finished the conference call the offshore Technical Lead will discuss the items with his team and then create the Sprint Backlog, which he will share with us all.
Our Everyday Scrum is a virtual meeting and is normally held at 2.30pm our time. Once more, we’ll use conference calling and each team member in turn has their opportunity to update us. This meeting is ring-fenced at 15 minutes and truly I’ve discovered that it’s less complicated to keep to this timing in a virtual meeting instead of face to face, when it can sometimes be tough to stop people talking. We have deviated here slightly from the typical Scrum rules and, if acquiring everybody on-line proves a issue, I’ll get the offshore Technical Lead to generate a (very basic) Daily Scrum written report – but I still insist on every team member completing a section for their region of work, which need to remain unedited by the management team. Not strictly inside the spirit of a every day stand-up meeting, however it works for us having a distributed team.
Daily progress is managed via the Sprint Backlog & Burndown Chart, with each and every team member updating the effort remaining for each and every of the tasks they’re working on. We’re constantly looking at how to improve our information sharing having 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 a lot more hard by our geographical locations. We use an open source desktop sharing tool as it’s easy (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. Once more, we use conference calling during the review and we constantly confirm the understanding of all involved.
Prior to the offshore Technical Lead leaves for the day we’ll catch up and talk about any problems that the team require to function on overnight. And before I close down I’ll make sure that any traffic from the client is marked up and passed on to the offshore team.
Over time we have refined and improved our distributed communications. We have a client who has a really good working relationship with our development team; they trust each other and work nicely together to resolve any problems. We all appreciate the constraints of working in a distributed environment but, rather than use this as an excuse for poor communications, we all strive to improve our ways of working. Making use of Agile techniques having a distributed team isn’t easy, but it is possible.