Agile software development talks a lot about communication and collaboration, and rightfully so. Communication and collaboration are a huge part of being successful with Agile: the collaboration between the team and the business; the communication between team members and Scrum Master. So, how can teams maximize collaboration and communication? How do things like distributed teams affect the ability to have great collaboration and communication? How does the use of physical and virtual tools affect this ability? Are there compromises that we simply must accept when it comes to having great collaboration and communication? I think the key is to find what works for your team and adjust often so that communication and collaboration are as effective as possible.

Real-Life Stories

Story 1: Physical Board Seems More Satisfying

I was on one Agile team that was lucky enough to be co-located. We had the Scrum team, Product Owner, and User Experience team all in one place. We started by using index cards for our User Stories, then transferred them to sticky notes and moved them to the task board. It was the typical Scrum board with the blue tape and everything. It worked really well for that team. Every day we would go into the conference room and go around the table to get an update from everyone. It was great to see subtasks and stories moving across the board every day. It was also nice that anyone could walk into the conference room and see exactly what the progress of the team was for the Sprint.

In addition to the physical Scrum board, we also used Jira to track issues. The reason for using something like Jira was to report to executives and for the Project Management group. So, even though it meant a little more work, we maintained both the physical and virtual task boards. For the most part, everyone on the team did a good job of keeping things up to date. The virtual board was synced every morning with the physical board after our Daily Stand-up meeting. Often the Scrum Master would do this synchronization task, which left developers free to get back to developing.

Thoughts

Having a physical Scrum board really worked for the Agile team in Story 1. I have been on several Scrum teams since then that used a physical Scrum board and have seen that it usually works really well for co-located teams. There is just something about moving a series of sticky notes across the board that feels good. It was also easy to see exactly how the Sprint was going just by looking at the board (i.e., it was obvious if the board was not changing every day). By the end of the Sprint seeing a bunch of sticky notes all moved to the “Done” column was a visual reminder of all the work the team had done during the Sprint.

Yes, you can track User Stories, subtasks, action items, and so on in a virtual tool like Jira, but I find it slower and it just doesn’t have the same impact. Of course, you don’t always have a; maybe your team is distributed or management mandates using something like Jira. Don’t get me wrong, using something like Jira has many benefits that are very useful (reporting, trending, etc.). My recommendation would be, if you must use a virtual Agile tool, to also try to use a physical Scrum board and see if it helps the team.

Story 2: Combined Team Meetings

Distributed teams are common for many companies and organizations. For organizations doing Agile software development this can be a challenge. I’ve been on several Agile projects that had distributed teams. When I talk about distributed teams here, I am talking about Agile teams distributed on the same project. On one such an Agile project, two Scrum teams were working together out of the same Product Backlog.

The manager of the project decided that the two teams should have all Scrum meetings together. Although I don’t agree with that approach, it might have worked on its own. However, in this case the two teams were in different locations. That compounded the issue because it made communication and collaboration much harder. We tried many techniques to help make communication and collaboration better. This included having a monitor set up all day with Skype so the two teams could see each other and ask questions through the day. We tried to always use VTC (video teleconferencing ) for meetings so that it felt like the teams were together.

None of these things really made a difference. In some ways they made things worse. We spent the beginning of every meeting setting up whichever tool we were using to video conference. People dialed into meetings would get lost as soon as there were side conversations (there always seemed to be side conversations). The Daily Stand-up meeting was a good example. Sometimes we would just dial into a conference bridge and it seemed like we were just going through the motions and not getting the real value that the Daily Stand-up is supposed to provide.

Thoughts

As I mentioned, I think that having Scrum teams share the Scrum meetings is actually a bad practice. I think it is fine to have teams work from the same Product Backlog, but I think it is better to maintain separate teams and meetings. Beyond that, when the teams are not co-located, I think it is even worse to share meetings. Technology can only help so much with distributed teams. When you are spending half the meeting setting up and sharing documents, and so on, does that really add value?

If you are lucky enough to have members of a team co-located but perhaps the Product Owner is in a different location, then I think it is better to have separate meetings for each Scrum team. The Product Owner can attend the meetings for each team (Sprint Planning, etc.). If there is a concern that the teams will not know what the other is doing (specifically when they are working from the same Product Backlog), that is where a “Scrum of Scrums”-type meeting can provide some value.

The main point I’m trying to make in regard to Story 2 is that sometimes we lose sight of what adds real value (i.e., communication and collaboration) when we try to use tools to compensate for teams not being co-located. If you see this happening, it is time to re-evaluate how your team is working and raise red flags in the team’s Retrospective meeting.