XM Principle 10: Partner Patterns
10-07-2014A is for Agile… and changing the world
14-08-2014The participants of my last course had a lot of questions about working with distributed teams. What tools do you need to work with distributed teams?
I developed echobravo with a team from Brazil. As product owner, I was located (mostly) in Zurich. My team was in Maringa.
One aspect which encouraged the trust between myself and my supplier was the use of a cloud-based source code repository like bitbucket. Knowing that I had access to the source code in the event a dispute took a lot of the worry away from the collaboration.
We found “Web 2.0” tools like Google Docs, Google Hangout, Dropbox and Skype to be essential for collaboration. You can communicate with each other, share screens and access common files, e.g. definition of done. I liked Skype better than hangout for convenience, especially the ability easily recall old chats, but Google Hangout has better video and screen sharing (an extra cost feature on Skype).
In my experience, proprietary tools introduce cost which is a hurdle to using them, and more importantly, they introduce arguments over who will pay for them which can be an even bigger hurdle! Beware of proprietary video conference solutions. Make sure that it is possible for people to call in from home without proprietary hardware.
I find an online spreadsheet is an excellent, collaborative tool for distributed teams to maintain story maps and backlogs, and for holding a distributed retrospective. A wiki is also good for documenting stories, sprints, and acceptance criteria. You can also record the state of the task board every day by taking a picture and uploading it to the wiki, a capability which is, AFAIK, unmatched by any virtual task board.
I would only recommend a virtual task board if the development team is not co-located. (And I would not recommend a development team which is not co-located!). My Brazilian team and I used a Target Process to manage the backlog and the flow of stories (not tasks!) from waiting to working to done in the Sprint, but they used a physical task board to manage their actual tasks.
Target Process is dear to my heart for a number of nonfunctional reasons (ask me about “my” feature!). Greenhopper/Jira is quite widely used, because of its integration into the other Atlassian products, as are Rally and VersionOne. I don’t have any strong preference for or against any of them. Most products have an online version which is free for five users, so you can try it out and figure it out before you actually pay money.
The main drawback of virtual tools are twofold: First, a virtual tool doesn’t function well as an information radiator — people have to actively look at the appropriate web page to see the status (if they even have access). With a physical board, anybody walking by can take look.
Second, Products must appeal to a wide spectrum of users, so they can do far more than you actually need. They often support practices which are not really recommended any more (like estimating tasks in hours). Wading through this excess can be confusing and cause you to waste time forever on unnecessary process.
I would therefore recommend, before you pick a product, start on paper. Then maybe move to an online spreadsheet. These are both very flexible tools. Figure out what your requirements and workflow really are. Then you are well positioned to pick a tool that suits you needs.