Distributed teams are a reality in today’s workforce, based on data from the November 2009 DDJ state of the IT Union Survey only 45% of agile teams are actually co-located. Distribution can come in a variety of shapes and forms, ranging from team members on a different floor in your building to being on the other side of the globe. Stating the obvious here, but the missing element is the inability to work face to face.
When starting out many people operate under the assumption that Agile can’t work across distances or worse yet they convert their distributed waterfall organization over to just start doing Agile and are surprised when they don’t like the results they get. It should be no surprise to us that when team members get a chance to work face to face, the results can be quite good. Working face to face certainly doesn’t guarantee good results (it certainly didn’t for decades before off-shoring and distributed workforces came into vogue) nor does taking a distributed Agile approach have to mean pain and failure. What it does mean is you have to know what you are getting into and make sure you are addressing the specific needs of doing Agile over distance.
Agile needs a high degree of collaboration to work successfully. I’m talking true collaboration, not just people working on the same project together. So anytime we take on an agile endeavor, we have to create an environment that allows collaboration to flourish. In order for collaboration to work; 1) people need to know and be comfortable with each other 2) everyone has to bring something to the table 3) you have to be able to work on the same thing at the same time (you may not always be working on something at the same time as someone else, but you have to be able to do it when you need to).
When we look at distributed teams, the main challenges that stand out to me are: geography, time zones, and talent spread.
Geography:
With the conveniences of modern technology like video conferencing, web chatting and instant messaging, the globe is getting smaller and geography issues are becoming more conquerable. It still isn’t the same as sitting next to someone, but I think it is workable. I’ve even heard of some cool new technology that connects two rooms with a display wall that makes the rooms feel actually physically connected to each other.
Time zones:
Time difference plays a bigger role than the actual distance between team members. The less overlap there is in “normal working hours”, more independent or solo work is going to be taking place (read: less collaboration) which can easily take teams off track. Successful Agile teams have strong and immediate feedback loops that allow them to validate work with each other before investing too heavily in an approach. The more of the workday team members are spending without the ability to reach out to someone in another role, the deeper the investment becomes in something that could be discarded.
It’s not uncommon for people to be asked to work adjusted hours to better accommodate everyone on the team, but this can create issues with employee’s family schedules or cause “extended days”. With extended days, team members may often get stuck working their adjusted hours to work with their team and also working their“ normal working hours” because they are expected to be in the office during those hours. This isn’t a sustainable model and will lead to burnout very quickly.
Talent Spread (or alternatively cross pollination of disciplines within a physical location):
In software, truly successful collaboration happens across disciplines, where you have a developer working with a Product Owner, or a UI designer and a QA tester, or a QA tester and a developer. There are numerous permutations, but the point is people representing different skill-sets, concerns and areas of expertise get a multiplier effect when they are able to work together and collaborate. I personally love having analysts and testers work together on creating test cases/requirements. My rationale is analysts are good at building things and figuring out how to make stuff work, testers are great at breaking things and seeing the cracks. By having the two disciplines collaborate, teams get really solid sets of tests that are well thought through and cover most scenarios. Obviously, Product Owners, developers and anyone else on the team are welcome and necessary partners in that collaboration as well.
Applying this idea against the backdrop of outsourcing and off-shoring models that many companies have adopted where entire departments or disciplines are moved to a new location (i.e.: development or QA to India) and you can see how challenging real collaboration can be for many teams. I’ve heard the argument for 24-hour workdays for years, but in practice, I’ve only seen it work for short bursts on a project where the team had a good grasp on what they were doing for the next week or so. However, beyond that, obstacles are encountered, feedback is needed, design reviews happen and the list goes on. All these things effectively put traffic lights into the 24-hour workday and all the lights are rarely green at the same time.
So what to do?
When setting up a distributed team, consider the following:
• Have the fewest number of different physical locations involved in that team.
• Don’t ever have one person working alone in a location.
• Make sure you have team members with different skill-sets in the same location and try to build a critical mass there.
• A double-digit time difference between team members is going to be a challenge and is not likely a sustainable approach. If this is unavoidable because of the locations your company operates in, build a fully enclosed product development team in each location that ideally has a product owner embedded with them and can work side by side with the team.
• Have a remote PO or PO proxy that is empowered to make product decisions when the primary PO is not available. Expecting the PO to be available 24 hours a day is unreasonable, conversely constantly waiting to the next day for a decision is a big red traffic signal that backs everything up.
• Travel – team members should get together to spend time face to face to build strong relationships and an understanding of each other. Ideally an entire sprint can be spent together working side by side so team members actually get a sense for how they work over the cycle of a full sprint. It’s helpful if travel can happen repeatedly over the course of the project to help to continue to grow the relationships.
I ran a mid-size Agile program a few years ago with a mix of distributed and co-located teams where many of these techniques were employed so I can say with first hand knowledge, you can do Agile across distances if you follow some basic guidelines and are willing to invest in the right things.
I’m sure there are many other creative techniques that can be used to bridge the gaps and I’d love to hear from anyone else who has successfully done something different.
The post Pitfalls in implementing Distributed Agile appeared first on BigVisible Solutions.
