A Paragon Expert Perspective on Agile.
Back in the late 80s and early 90s when the bones of Agile were first being formed, working virtually and large offshoring initiatives were the exception...not the norm. It's no wonder that Agile methodologies were envisioned as a colocated development solution and there were very few alternatives.
There are quite a few advantages to being colocated.
Communication is easy and the team can benefit from Osmotic Communication. It's a term coined by Alistair Cockburn, one of the originators of Agile, who defines it as: "Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work."
I've participated on both types of development teams and I can say that a colocated team is easier in a lot of ways. Still, that was quite a while ago and things have changed a lot since then.
Collaborative technologies have improved dramatically allowing teams to remain in close touch throughout the day. So when I hear someone say that to practice Agile you must create colocated teams, I get a little defensive ... and annoyed. That's a knee jerk reaction that puts up an unnecessary barrier to what might be an amazing experience. Let’s talk about the differences between the two.
Colocated and distributed teams differ in three distinct ways: planning, communication and collaboration.
For colocated teams, planning is a bit easier because you have white boards that are always visible. Your sprint tasks are typically on a board and if you’re like one of my teams there was a bell on the wall and we rang it every time we completed a task. It engendered friendly competition. At any time I could look at the ‘The Wall’ and see the status of the sprint. Communication was easier because at any time any developer or tester could just ask a question and probably get an answer or at least a conversation right away. Pair programming was collaboratively used so that most of the developers learned new skills on a frequent basis. When you are working together day after day it creates an environment of trust and mutual respect. It’s a little hard to stay mad at someone for too long when you sit across from them every day.
Distributed teams take a little more work.
Never underestimate the attraction of convenience, but don’t pass on the benefits of Agile just because your teams are not colocated. A little extra work and the use of effective technology can make all the difference. The reality is that in today’s market, the utilization of globally disperse skills is a huge advantage. With colocated team you are restricted to the skills that are available in close proximity.
With a distributed team, the world is your oyster.
And the ability to support the team in multiple time zones can be quite enticing. In the 10th Annual State of Agile Report conducted by VersionOne between July and November 2015, more than 82% of the respondents had at least some distributed teams practicing Agile within their organizations, up from 35% just three years earlier. Go to www.stateofagile.com to download the full survey results.
My preference is a mixture of the two. While I really enjoy working with colocated teams, I like and appreciate the expanded availability of distributed teams. What I find is that the entire team, but most especially the Scrum Master, must be more diligent in each of the three ways that colocated and distributed teams differ.
You need to come up with a hybrid solution that works for your team.
- Planning: A little up front planning can pave the way for a smooth ride. Make sure before you start that everyone has the tools needed to do their work and that any additional tools such as teleconferencing is pre-scheduled. Another planning challenge with distributed teams is coordinating the various holidays and working hours. Part of one of the distributed teams I worked with was located half a world away. We used to ask each of our colleagues both in the US and abroad to educate the rest of the team on their holidays and their significance so that as a team we could learn to appreciate the differences in our cultures. Finally, if there is any possibility of bringing the entire team together at or near the beginning of the project, then by all means do it. The cost will be balanced by the good will and comradery that is created. If it is not possible then teleconferencing is your best bet. Video is the second best way to build that comradery. And it does work.
Communication: One of the most valuable tools I've found to increase team communication, aside from video conferencing of course, is group chat. As a Scrum Master I monitored the group chat to make sure questions and concerns were answered promptly. I made sure everyone logged into group chat at the beginning of their shift and if they didn't, I would contact them as a reminder. It took a while to convince everyone to not only ask questions but to log what they were doing. The conversations would be something like "I'm just about to code X and I've done this a lot of times if anyone wants to watch", or "I'm just about to code X and I've never done this before. If anyone has any tips that'd be great". Getting a developer to admit that they are not very confident about some portion of their work is difficult but as the trust builds it becomes easier.
Collaboration: Today's collaborative tools are amazing. Advances in network stability have made connectivity easier than ever. But you still need to ramp up your diligence when it comes to the ceremonies. Even a 15 minute stand-up meeting takes on a higher sense of importance when you don't get that many opportunities in one day to talk to each other. It may seem like a small thing, but it is the consolidation of many small things that culminates in success. Things like reminders that you are all working as a team and that you succeed or fail as a team, not as an individual. Maybe you will need to increase your demo's, maybe find alternatives to pair programming. Whatever the issue, creative solutions are there. You won't know if they work unless you try.