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…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …