Questions on Distributed Agile
Our Agile Guru series of webinars gives our coaching and training participants an opportunity to ask follow-up questions of their coaches and trainers. One of the perennial questions we get is on the subject of geographical distribution and whether & how it works with agile practices. In my last session, we had a few questions on the subject, and I’ve transcribed them and my answers below:
Q: How to manage distributed teams and remote teams?
A: The first thing to recognize is the damage done to communication, alignment, trust, and team flow by geographic distance. These effects won’t magically disappear with agile practices – quite the opposite – they’ll become more painful and obvious. Agile practices will shine a very harsh light on these impediments so that you’ll no longer be able to deny them. But I will say agile teams who commit to minimizing the effects of distribution will do better than those that don’t.
Will agile ‘work’ with distributed teams? Again, only to the degree that the organization commits to removing the impediments agile practices reveal. I have a client who before trying Scrum, regularly spread feature teams across more than 12 time zones: UK, India, Australia. After using Scrum for a few months they realized what an impediment it was, and are now prohibiting teams from spanning any more than 8 time zones. This distribution had been hurting them badly for years, but I’m not sure they would’ve realized it before doing Scrum. Scrum most definitely did what it was designed to do – it worked by showing them just how painful and damaging this spread was to communication and productivity. With all the practices aimed at high-bandwidth communication & collaboration, they couldn’t deny the obvious – it’s a huge impediment.
Q: How to manage remote development with local product owner and remote dev team? With local team and remote owner? What practical tips do you have? For example, what time to run the standup?
A: The answer here is no different – it’s a huge impediment to not have ready access to your PO or customer. Remember one of the agile principles is “Business people and developers must work together daily throughout the project”. That gets nearly impossible when the PO and the dev team are on different sides of the planet. Lack of product ownership is one of the most common problems I see with agile adoptions, so it’s hard enough for most people even without adding a planet-sized impediment into the mix. I’m not saying it can’t be done, only that most people trying it fail miserably.
As for the daily standup, teams will have to work out an equitable solution. I have one client that alternated times each day so that no one location had to stay up until 9pm or get up at 5am every day. It still was pretty painful for them, though. Most people throw in the towel and make their “daily standup” a weekly, which is awful – you don’t know for most of the week whether progress is being made or who’s blocked on what. And productivity goes down the tube. All in the name of saving money on development.
I will add that the question of tools becomes critical with distributed environments. Single collocated teams can manage their projects just fine with wallboards and paper and markers – everyone’s in the same place. But these don’ t scale to multiple and distributed teams, and this case it’s important to have a truly agile project management tool to centralize artifacts like your backlog and taskboard and to make sure everyone can easily access the same information in real time, with a minimal barrier to use. In distributed environments, good tools can make all the difference.