Introduction

In preparation for a course I'm teaching over the next couple of weeks on OO and Scrum, I spent the weekend reading up on the new books on Agile and Scrum to see if there are points that I need to add to my courses.

During my preparation I read a few books and papers discussing distributed Scrum. They contained good tips, but I felt they missed a few important points. My company partake in quite a few distributed projects, so I though I'd share some of our key lessons.

Also, I though I'd root these lessons in the agile manifesto. The blogpost focus on the challenges distribution introduces to the agile goals and how we overcome them. I'm not going to try to explain agile, XP or Scrum. If these words are unknown to you, you probably have to read up on those topics before coming back to this blogpost.

The agile manifesto reads:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following plan

Distribution often makes this manifesto item hard to follow. In particular, it is hard for individuals to collaborate when not co-located. Often agile teams prefer to work in the same room (often called bullpens) where the cost of collaboration is minimized. In a distributed world, you can't just lean over to the guy with the knowledge you're missing and get the answer immediately.

Individuals and interactions over processes and tools

It is somewhat ironic that we've overcome this obstacle primarily with tools, but I think you'll realize quickly that the tools I'm referring to are different than the tools originally targeted by the manifesto.

Collaboration tools

There are many ways to collaborate online these days. Skype, MSM, Yahoo, WebEx, TeamViewer, NetMeeting and Google (Hangout, documents, chat, phone, etc) to mention a few. These are all good tools, but they still don't come close to the feeling of being in the same office.

At SciSpike we're using a tool called Sococo. Although we could probably make our collaboration work with any of the other tools, Sococo seems superior for agile work. In Sococo, the agile team are given a virtual office that may look something like the picture below (the picture was stolen from the Sococo site, but I'm sure they don't mind :)):

There are several ways to configure the office, but the idea is that everyone has their own office and there are a set of meeting rooms. Each person is represented as an avatar, and I can at any time see who is in the office and who's currently discussing/meeting/...

So… say we have a meeting in one of the meeting rooms, it may look something like this (again the picture is stole from their site…)

The above picture tells me that Me, Berry, Kent and Mary are meeting. Kent is presenting on two screens, Benny on one screen and I am also presenting on a screen (see the little bubble next to the screen). I'm not going to go on to explain Sococo, but notice how I can lower my cost of communication. For the most common scenarios, the process of initiating a collaboration looks like this:

• Say I want to talk to Jim and Jim is in his office:
• Double click on Jim's office
• Start to talk
• Say I want to have a meeting with Jim and Mary
• Right-click on Jim and Mary and invite them
• Jim and Mary clicks on a popup and they automatically enter my office
• We start to talk
• Daily scrum
• Set a time
• Everyone enters the office (you'll see who is there)
• Go around the room (each of the avatar lights up when they're talking, so you can easily see who's talking)

I encourage you to try out the tool for yourself, but the bottom line is that Sococo makes it as easy (or in many cases easier) to interact with your coworkers remotely.

Although the Sococo tool works perfectly for most communication, we do also use other communication tools. We've found the Google Hangout and Skype with screen sharing to work better when two developers want to collaborate (the screen sharing in Sococo doesn't expose the mouse, which makes it hard to 'point' to locations on the screen). For pair programming, TeamViewer is really good.

UPDATE: With the Sococo Version 2.3.0 released July 2013, the screen sharing has been improved dramatically. We are now also using Sococo for pair programming!

Distributed pair programming

One effective agile practice that helps spread knowledge and help collaboration (disputed perhaps, but effective) is pair programming. We've found that this can be quite effectively performed remotely. The screen sharing programs are quite effective here. In fact, it may even be better than sitting together as both can have a comfortable position watching the screen.

We don't use Sococo for this as the screen sharing there is not quite responsive enough, but tools like Skype, Google Hangout, TeamViewer works perfectly for this.

We use pair programming judiciously. We find it to be very effective to communicate, teach, work through critical passes of the design and a few other obvious scenarios. However, in our particular case, our engineers have been picked based on their strength as individuals. They are quite comfortable taking on tasks by themselves and collaborate selectively when required.

Hire engineers can work distributed

SciSpike's model is entirely distributed. We hire the best engineers we can find no matter where they may be located. However, one of our criteria is that they are comfortable and thrive in a distributed environment. Learning how to collaborate effectively across boundaries like distributed locations is not for everyone. An important part of our interview process is to find out if someone can collaborate well in an online setting.

Use a test driven approach

I would recommend using techniques from the Test Driven Development approach (TDD). The key advantage is that you can formalize what you expect through your tests. Ideally, I like for the consuming and producing team to sit together while defining the tests, but after the test have been defined, the need for communication between teams decrease significantly.

Use formal contracts where bandwidth of communication is low

When being distributed there are cases where you just can't communicate as smoothly as suggested above. The reasons may be many. A few that we come across are:

• Teams in different time-zones with little or no overlapping hours. The prime example of this is of course outsourcing.
• Specialist teams brought in for their individual expertise. The most common scenario for us at SciSpike is that we work with a User Interface company responsible for the front-end experience (UIX) and where our team build the back-end services.
• Integration between two software components that build software using two different processes/technologies.

Bring everyone together for the sprint planning

I like to bring the team together for the sprint planning. I prefer 4 weeks sprints (never any longer). It is possible to do sprint planning remotely also, but I prefer to be co-located during sprint planning. Bringing the team together to one location once every month is not all that expensive and it smoothens out  the online collaboration. I usually use the last day (or at least 1/2 of the last day) to work out the architecture and design and ensure that we have an initial plan for the sprint. In case we use a contract language or TDD to specify components (see discussion later in this article), I'll try to formalize these also in the sprint.

Working software over comprehensive documentation

This manifesto item is really a reaction to common bureaucratic processes (often introduced by some kind of standard organization like ISO or CMM). We've probably all been exposed to projects where we knew we were working on documents that would never be read, but that the process required us to do to be in compliance.

I don't think distribution provides much of a challenge here (that is the principles below are good practices for a collocated team also. In fact, I'll just list them below with no further discussion. Notice that the I'm using cloud-based services for the most part, however if you have a nice corporate cloud that would of course also work. We often setup an Amazon based machine(s) and install our own build development services, but there are plenty of hosted cloud-based offerings available.

• Cloud-based source code repository (e.g. GitHub, centralized SVN).
• Automatic cloud-based build services that checkout and build the software immediately. This software should also distribute the status of the build.
• Cloud-based component management that allows the developers to 'push' and 'pull' components from some centralized repository.
• Processes that 'prove' that the software work. Perhaps you  have a Q/A person or the product manager sign off on a story after a demo

Customer collaboration over contract negotiation

The challenge here is to get customers involved with a distributed process. Here again we rely on online collaboration tools such as Sococo. We insist that our customers partake in the virtual office and that they keep regular hours connected. It is now very easy to setup an ad-hoc meeting with our customers to iron out issues.

We also encourage our customers to partake in the daily scrum and when possible keep them engaged in demos and tests.

Another crucial element is to ensure that the progress is tracked in real-time. We teach our customers to read our agile tracking tool and ensure that they are engaged as frequent as their schedule allows.
If our customer is external, we also highly recommend that they get involved in project in the role of Product Owner and Scrum Master. This ensures that the customer is always fully aware of where we are in the process.

One may argue that the above points are the same no matter if you are distributed or co-located. I would agree with this, but I have to say we spend more time teaching our customer and making sure that they fully understand the agile reporting and how to read progress (e.g., burn down charts).

Responding to change over following a plan

You have to setup a process for handling change (doesn't matter if your team is distributed or not). I have not found any particular challenge with being distributed with respect to this manifesto item. However, I've seen many projects using too much time trying to freeze requirements because they are distributed. I don't see this as being necessary if you follow the advices presented above.

We do make sure that we track the progress of development in real-time. We've tried out many different tools to do this. They all have their advantages and disadvantages, but it is critical that everyone in the project has access. Tools like Jira (with their agile extension), PivotalTracker, Rally, etc works

Conclusion

In this blog article I've described some of the techniques we use at SciSpike to conduct agile practices even when working in distributed teams. We find that you can work effectively when distributed and still follow the agile practices. There are cases where some formalization of contracts are required, however for the most part, the trick is to enable online communication and ensure that the participants use the tools available effectively.