Working with a distributed agile team was a first time experience for me, and one that came with very interesting challenges. The most obvious of these challenges was of course, communication. The other was related to keeping good practices like pair programming still feasible. Even something as simple as recognizing my own teammates in person, after having worked virtually with them for several months, was a unique challenge. Despite these challenges, there were a few ways that helped me optimize my work within a distributed team, and I'd like to share them:
Scenario 1 - When we design
Engaging business analysts, customers and subject matter experts in a design session is vital. These sessions set the tone and common vocabulary for the feature in development. However, this activity can prove itself difficult when each side is in different locations, because drawing over a board is not an option.
We tried using the tool yUML, as it made it possible for us to diagram the class model we needed. We were then able to convey our understanding on the domain problem, by having each side access the same URL with edit privileges.
It is crucial to have a tool that helps collaboration in real time, with a learning curve no more than a couple of minutes.
Scenario 2 - When we pair on coding
How can we pair successfully, when our coding peer is in a different location? This is harder than the design brainstorming sessions, as we need to code over the same base at the same time, through video conference or a tool that would allow us to edit the code simultaneously.
Initially, we thought that time-boxing would work well while pairing. But our time-boxed turns (beginning with 5 minutes and then increasing it to 10 minutes) revealed that connections and rendering delays were our most fierceful foes. We would end sessions with a half coded idea which never materialized as code, because we were waiting for displays to render, control to be transmitted to the other end and so on. We had a lot of dependencies before we could resume the session.
We then tried out a strict “ping-pong” process, which was a great relief. This consisted of each solving the pairs' just written test and talking about it. We would then write another test, while explaining the point of the test. This worked really well for us.
A ping-pong process catalyses a higher quality of communication. This in turn, reduces the amount of code needed to grow the feature.
Scenario 3 - When we have a stand-up
Over time, we began to realise that all the equipment and tools that are used by people working in multiple locations have one goal - they trick our brain into believing everyone is in the same room! This is done to build a strong team relationship. It also fosters a safe environment, where people are comfortable to ask questions, seek help and discuss problems. This reduces miscommunication considerably, and ensures more transparency within the team.
So the next time you’re attending a stand-up from a remote location - turn the camera on! It always helps your peers if they can put a face to your voice!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.