Agility in a global software development team

In February 2001, the 17 apostles of lightweight software development met for a weekend in a mythical place called the “Snowbird resort, Utah”, now known as the birthplace of the Agile movement. They came out with 12 principles, out of which they derived the “Manifesto for Agile Software Development”. It consists of 4 values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Looking at those values, we can understand that Agile software development encourages many practices: shorter release cycles, inspect and adapt, reactivity to changes, decreased overhead, value driven prioritization... At the heart of it all lies an effective and efficient collaboration between involved parties. An increased collaboration also means more communication. But in the last few years, a shift have been observed in the way we go about software development: the continuing improvements in Internet access and the increased use of telecommuting have caused the modern development team to evolve. This has brought more challenges to team collaboration, regional colors (accents) and time shift between members to name a few.

In this article, we will explore various communication and collaboration tools, drawing from my personal experience, and we will look at their strong and weak points. Finally, making the hypothesis that we are approaching this the wrong way, we will look at alternative to distributed teams.

Communication

One of the principle behind the manifesto is that “The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.” (Kent et al.). David Parnas corroborates this by saying that the root cause of most software failure is ineffective communication. But how do you substitute face to face interaction in an non-collocated team? We will look at three commonly used communication types: textual, audio and audio-visual.

Textual

First there is textual communication: email,chat, text messages… We will not discuss the latter because we haven’t seen them used as a communication tool beside the usage that will be discussed here, so we will focus on email and chat.

Written communication tend to be very precise because each question, answer or statement can be revised and rewritten until it appears perfect to the eye of the writer. The flip side to that is that it’s in the eye of the writer, who doesn’t know how the reader will interpret each statement. It also is bad at conveying emotions and sarcasm and is often misinterpreted, sometimes leading to unnecessary friction between team members. Promoting team camaraderie is very difficult if your team relies mainly on written communications.

Email latency is a real problem, often people don’t respond right away to message they receive, they will wait until they have the time to write, and they even sometimes go forgotten (by accident or intentionally). Something that would have taken a few minutes in a face to face conversation can degenerate to many hours, even days, when using email. To palliate this problem the team can agree on a maximum time delay to answer emails, for example your team could agree they have to respond to email message within an hour of receiving them, and if the sender doesn’t have an answer after that delay they can send a text message to the other involved parties to confirm reception and remind them about it.

Chatting has the advantage that it’s more engaging and interactive, like a real conversation but it can still be forgotten behind another window on your computer desktop. It can also be distracting because the rhythm can get awkward which cause the participating parties to be distracted every few minutes by a new message, and a feeling of urgency will prompt them to answer right away, this is also made worst by having a sound playback for each new message you get.

Spoken

Secondly there is voice communication, those include phone, skype and others voice only communication systems. When holding a meeting over the phone the dynamics of it change. People are often distracting on the phone, doodling something on a piece of paper or taking a quick glance at their email and they may then wander about the response to will give to this one, not paying attention to the meeting until their name is called.

Some people rely on the gestual of their interlocutor to decode their emotions and to know if everything is really well or if they have something else to add but are keeping it to them self. Not having visual clues about someone feelings will sometime lead to others not picking up on a situation right away and it may then degenerate further until the person decide to speak up. This can lead to a sentiment of isolation and helplessness.

Dealing with regional accent can sometimes be challenging, for example I once was on a team with a strong eastern-european representation, and a fellow team member told me that it was in my best interest to do something before a certain date. I thought he meant that my job was in jeopardy but in fact it was a friendly reminder that after that date it would be a hassle to do what I wanted to do. To minimize those kind of misunderstanding team members should not be anxious about asking for clarification until they are satisfied with their grasp.

Teleconferencing

Teleconferencing on the other hand is almost as good as face to face communication. It palliate most ot the issue of the other styles, people being distracted will be picked up by their peers and be gently (or not) reminded that their attention is expected. Teleconferencing also allows desktop sharing between members, this can help during presentation, planning, retrospective and reviews. Desktop sharing can also be used for peer debugging or programming, enabling collaboration rivaling the one of a colocated team. Teleconferencing has some inconvenients: it requires some minimum infrastructure that may be less accessible in some part of the world. Where bandwidth is limited it can also get expensive. Another disadvantage is that you can not just drop in as when colocated, encounters have to be planned and take into account time zones.

But each communication media has it’s advantages and disadvantages, let’s recap them in a table

Collaboration

How do we collaborate when we are not in close proximity?

The whiteboard is one of the most used information radiator, besides the Kanban it host a multitude of information : burndown charts, definition of done, important incoming dates, group norm, anything relevant to your project can be put up there. Having a whiteboard that is readily accessible by all at most time is of very high value to the team. It will keep the members informed of the current status and other relevant information. But to be useful it needs to be regularly accessed and updated by team members.

Realtimeboard.com (RTB) is one of the better virtual whiteboards alternatives. You can draw in it, add Post-it, add comments, attach files and videos and it will alert you whenever someone modify it. It uses flash so it’s not accessible on most mobile devices, it would be a nice feature and is surely something they're working on. What sets it apart from other ones is its intuitive user-interface, most people will pick it up quickly.

Real example of RTB being used

Implementing a Kanban with this tool is really straightforward with virtual Post-it of any color you may want. The difficulty, as is often the case, will be to discipline everyone one to update it regularly and consistently. It’s even more relevant in non-collocated teams because you cannot just turn around and ask.

Collaboration during Ceremonies (meetings) can be challenging, but by combining teleconferencing, desktop sharing and a virtual whiteboard you can get everyone involved. Designating one team member to share his desktop and update the whiteboard as the meeting evolve is helpful and engaging for others.

Alternative

Looking back at communications, is there any way that we could make face to face communication more feasible, or at the very least reduce the amount of  indirect communications?

Kruchten (2011) makes a link between team distribution and a need for more explicit communication and coordination, and goes as far as talking about  those being required by the interface to the software modules. We assume he actually was thinking about component based development (CBD). Component based development is a practice where each team will work on a specific component of a system. Implementing CBD in a consulting setting can be difficult, especially when acting as contingent. Production will start slowly; this is where keeping a component expert on site can help by providing quick answers to the team's questions.. Having an experienced staff will help during the transition to CBD. After the initial knowledge transfer phase, the experienced developer will be able to act as mentor for new ones. Once the transition of ownership of the component is over, the inter-office communication will be reduced. The client will only need to state its requirements to one or two person of the team who will understand them very well. They will then act as a proxy of the client, you can see them as internal Product Owners. The next step would be to get them to do the design and analysis of the wanted changes. Once trust is established, building long term partnership with the client will be possible.

Conclusion

Here we looked at various communication types and evaluated their strong and weak points. We also found out that they cannot replace face to face interaction but that, using the whole array of available tools, we can communicate efficiently. We then saw how a virtual whiteboard can bring value to the team. There are other ones available that may better fit your needs but we feel this is one of the better offerings out there. But we didn't look at other collaborative tools like wikis and issue/project trackers, these could probably be the object of another post. Finally we looked at an alternative to global teams by trying to create smaller component based teams. We looked at CBD from a consulting point of view and found that, while being less efficient during the ramp up phase, it will pay up after. It also boosts trust between the parties leading to better partnership.

In a very agile manner these are not rules to follow, but merely the fruit from our observations, your mileage may vary.

References

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . . Thomas, D. Manifesto for agile software development. Retrieved 11/14, 2014, from http://agilemanifesto.org/

Kruchten, P. (2013). “Contextualizing agile software development.” Journal Of Software: Evolution & Process, 25(4), 351-361. doi:10.1002/smr.572

Simons, M. (2006). “Global software development: a hard problem requiring a host of solutions.” Communications Of The ACM, 49(10), 32-33.