Skip to main content

Can you recommend a virtual task board?

The 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.

Comments

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Five Simple Questions To Determine If You Have the Agile Mindset

My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …