Jakob Wolman
As with any craft, you will do better with the right tools, while bad tools will slow you down and create frustration.
Before digging into my toolbelt I want to point out that any tool is pointless without discipline. Working agile, and working distributed, requires a large portion of discipline. The threshold for communication can be much larger than just shouting across the desk. It takes some getting used to your team members being available online instead of present in the same room. It requires discipline to stay transparent and open when sharing becomes unnatural.
The topic of tools always draws a crowd because it is something graspable that we can bring home. I am not going to discuss which tool is better because I don’t believe that debate to be valuable. Rather I believe in an iterative process of trying tools out and finding what fits your needs. More important than the brand and actual software you use is what you want to achieve with it. That debate is well worth having.
Communication
This is the heart of teamwork. Without effective communication a lot of things will get really hard. A distributed team needs a channel for written communication as well as audio and video calls paired with screen sharing. The threshold for starting a chat must be very low and you need a way to talk with the whole team at the same time. Since written communication quickly gets confused and important messages disappear in long threads you need some way of segmenting the chats and make sure only those that are interested participate in the discussion.
For most communication we use Slack (and love it). In combination with Webex and Skype (corporate standard) we have several tools to choose from depending on who we need to talk to and in what form. Remember to make sure everyone has proper hardware: webcam, proper headset (earbuds that come with your phone does not count as proper) and a speaker with microphone that can catch a whole room (like the Jabra we use).
File and code sharing
The team has to be able to collaborate and share the work they have done. This goes for both code, documentation and files in general. There has to be a good way for teams to work together on a document, preferably in real time (locking work in progress until you are done is an old paradigm by now). The created work has to be archived and accessible in a structured matter, preferably searchable.
We primarily use GitHub and Confluence, sometimes combined with OneDrive, Office365 (corporate standard) and DropBox.
A note on using GitHub: using pull requests has changed the way we do work across teams. We used to talk about dependencies between teams. This has now shifted into teams inviting others to their codebase, as long as they can review the pull requests. This has made working together more convenient and secure.
I wish more systems would adopt this way of dealing with access. Instead of locking the system down, allow anyone to commit suggestions for changes.
Transparency of work
The team needs to be able to show what they are working on, both to team members and people outside of the team. They also need to plan their work, and show what they have planned (and re-planned). This goes for both short term plans (sprints) and long term plans (milestones and longer). For some teams this means having a visible backlog.
For a co-located team I always prefer a physical board in the team space. A board is an information radiator. If you have to visit a specific URL to see the board, there is not radiation. A team board is so much more than a system to visit during standups and planning. Therefore I push for teams having their board always visible, be it on a tv-screen, first thing you see when you open a browser or some other way. It should be in your face.
These tools are probably the ones that create the most heated tool debates in the agile community. We are mainly using Jira in combination with Confluence to create boards and do planning. I personally prefer more lightweight tools, but they get the job done.
A whiteboard
For a facilitator like me it is essential to have a way of sharing a whiteboard-like workspace. I use it to run retrospects, design sprints, planning, visualizing work, tracking value and almost anything. Having the ability to work with post-its and collaborating on a board in real time overcomes a lot of barriers.
We have fallen in love with Realtimeboard, that gives us the creative freedom we need. Since we adopted it throughout R&D people are creating boards for all kind of purposes from drawing architectures to creating team plans.
Developer tools
I won’t go into the details of developer tools that are needed for distributed (and co located) teams, but some of the same rules apply as for other tools. Discipline and some kind of common standard for how to create the work is important. There needs to be a transparent way of continually building, testing and deploying the software. When it comes to developer specific tools I believe in giving people the autonomy to choose for themselves, as long as they can fulfill the common standards that the team or the organisation has agreed on. The debate of which IDE is better is as meaningful as watching paint dry. Tabs vs spaces is however important, because you need to align the whole organisation.
Using the data
One of the benefits of using digital tools is that you get a lot of data. It allows you learn more about your progress and explore the data to find new insights. Especially if you combine the datasources. We use this wonderful tool called Qlik Sense ;-) to analyse data from GitHub, Jira, Confluence and our build systems. We extract the data and leave it open for anyone in the organisation to analyse. For a system thinker like me this is a gold mine. It allows me to have a data driven discussion about our mean time to market, see waste in the system and visualize bottlenecks.
I am curious about what you have in your tool belt. What is the one tool you would not be able to live without? Which tool has had the biggest impact on the way you work?