Many people ask me what is the best tool for distributed agile teams. It’s the wrong question. What many people miss is that a distributed agile team needs a common workspace and a collection of tools that work together in that space.
While the team members may not be collocated, they need a common work area that they can all access and be present to collaborate with teammates. If you have been collocated with teams in the past but are now working on a distributed team, think about what you used in the environment to work together. Some tools might be obvious, but other tools may not be so obvious. I have found six types of tools that any distributed agile team needs to collaborate on a project. This collection of tools need the ability to:
- Track the Work
- Store and Manage the Work
- Work Out Loud
- Show “Who is ready to collaborate?”
- Jump Into Planned or Unplanned Collaborative Work
- Take a Break
Let’s unpack each of these.
Track the Work
You need to know two pieces of information: who is doing which work and to know the team is sequencing the work in a reasonable way. You need to know this data so everyone can tell no one is duplicating anyone’s effort. And, you need to know that the right tasks are happening at the right time to achieve the team’s goals.
For many agile teams, the overall goal of the work is represented by a story. Tasks in the story typical represent a sequence of steps the team must take to build a portion of the product that achieves that goal.
If you are on an agile project team, you plan this work together as a team and it’s even more critical that everyone on the team can modify the tracking board. It doesn’t matter which tool you use: Trello, Jira, Leankit, Rally, VersionOne or any of the multitude of other agile tracking tools. Everyone needs access to view and update the board to show current progress of the work including goals (stories) and steps (tasks).
Store and Manage the Work
Whether it’s software, documentation, graphical elements, or any other kind of knowledge work, work of the team on the tasks will produce output or “artifacts”. The artifacts represent the completion of a task that is part of an overall flow of work to complete a story. For instance, some of these artifacts are the raw materials (e.g., MarkDown or source code in a specific programming language), some are partial products (e.g., book chapters or compiled software components) and some are final products like an complete e-book or a complete software application.
Often, the work proceeds in various “stages” of planning and execution. Your team might not be able to deploy to production, even if the team can complete all the other tasks of a story. The team members need to share the tools for each stage of this work. Everyone needs to be able to examine and update the artifacts, store them until someone is ready to move them to the next stage, and also provide additional information about how to assemble the components for either a manual or automated build process.
Also, each stage of the work may have a unique “workbench” associated with that stage and a collection of tools that are best used for that stage. The overall workflow may require different types of workbenches in the shared workspace, but most tools should be accessible to all team members. However, there may be exceptions where special knowledge is required for specific tools at a workbench. For instance, a new team member at the “push to production” workbench may quickly get into trouble without sufficient knowledge of the tools for that stage of work. However, once a team member has learned the skills needed for that workbench, they should be allowed access. This allows multiple people to help at multiple workbenches and reduce the chance of any new product being delayed at any stage of the team’s work.
Work Out Loud
As described in John Stepper’s book, Working Out Loud, you can build relationships by generously sharing what you are working on in public ways. Within a distributed agile team, this is more than just updating the task board on a daily basis. You might share comments in the team’s chat channel or write a blog (either internal or external to the company) about the current problem you are trying to solve and how you are solving it.
It’s not about sharing the final solution to show “how brilliant” you may be be, it’s being brilliant by sharing your work in progress and attracting others that might be able to bring knowledge and ideas to the work. (Hint: This is how Johanna Rothman and I ended up collaborating on our new book.)
With more modern chat tools, updates on your work can be shared from various tools with small status updates straight into a team’s chat channel. Depending on the team, the frequency of these updates might be made more or less frequent.
For sharing deeper thinking about the work, a shared documentation tool can also help a distributed team. Team members can share their ideas, ask for feedback, and then review comments in the same shared document. When team members can collaborate within a shared document and link ideas (such as in a wiki), the entire team can learn faster. Linking also allows team members to connect related concepts or share options in other documents. The linking ability is another way for the team to “work out loud” to create a shared understanding of their work.
Show “Who is ready to collaborate?”
Distributed agile teams need to know who is in the workspace with them, what they are working on, and if they are available to collaborate. This goes beyond the 20th century tool known as the In/Out board used by office workers to let coworkers know when they were in or out of office.
In distributed teams, they may use a tool like Sococo that allows team members to see who is collaborating (in the same room), who might need deep focus time (solo in a room with a closed door), or who might just be working with some focus but is willing to be interrupted (solo in a room with an open door).
However, some of this same “visibility” can be shown through a modern chat tool like Slack or Stride. The team might have several channels that act as rooms. Each individual can indicate their status as Available/Away/”Do Not Disturb”. Finally, the tool can be set to show them away if they step away from their keyboard for a period of time. Also, these chat tools have a way to address everyone in a channel or across the channels to determine who might be available to collaborate.
Jump into Planned or Unplanned Collaborative Work
The point of working on a distributed agile team is that you collaborate on many stages of the work. Collaboration may happen in planning, analysis, coding, testing, documentation, and preparing for pushing the work to final delivery. The team plans some of the collaboration. Some may be unplanned as one team member may need the help of others for a quick review or brainstorming on a problem.
Here, a few different tools may be needed. First, a shared team calendar where all planned team meetings are scheduled and updated. Ideally, anyone on the team should be able to add or edit this calendar.
Second, a shared meeting tool that allows for quick collaboration. There are many free and paid options for online meetings such as Google Hangouts (and the business-version, Meet), appear.in, Amazon Chime, Zoom and others. What is important for these meeting tools are that they allow anyone on the team to start a meeting at will or to easily add to a regularly scheduled meeting. These tools should also support simultaneous audio and video for team members. This allows everyone to be seen and better understood as reactions to ideas can be viewed.
Take a Break
It’s just as important for team members to take breaks together as it is for them to work together. For some, this could be simply sharing vacation photos or favorite music in “watercooler channel” of the chat tool. In other cases, you might have special interest groups have their own chat channels or wiki pages sharing hobbies such as coffee brewing, automotive hacking, or drone pilot tips.
These “shared recreation areas” are just as important for the virtual team as the ping pong and foosball table is for the collocated startup team: it helps them learn more about each other and builds stronger social bonds within and even across teams.
Best for Me or Best for You?
With these six types of tools, a distributed agile team can define their own workspace. Also, what works for my team may not work for your team (or organization). Again, this is why asking someone else “what is the best tool” is not a useful question.
For example, it’s important for the teams to have as much control as possible within the larger organizational environment. This level of authority will allow the teams to explore new ways of working together and build better collaboration overall. This is easier in some organizations than others.
Also, what might your teams prefer in these different types of tools? Have they used Jira, Rally, or Trello for planning and tracking their projects before? Did they find it useful? Do they like Slack or are they tired of all the online communities that use Slack? Provide some flexibility in letting the teams experiment and pick the types of tools that work best for them in their distributed workspace. What’s best for your distributed agile teams is to give them a choice.
Member discussion: