Question

G’day,

Edit: We’ve been using Scrum very successfully for several years on several projects of varying sizes. In fact, our team developed the successful iPlayer project for the BBC using a classical Scrum approach.

After using various combinations of tools, some high-tech, some low-tech, across these projects we now wish to try adopting a suitable tool suite. Our manager is to some extent attempting to force the adoption of a single suite of tools for Scrum.

I’ve looked at the SO question “Best Scrum tools” and most people seem to recommend either:

1. a suite of low-tech solutions, e.g. whiteboards, post-its, index cards, etc., or
2. a monolithic tool that tries to satisfy as much as possible of the process, e.g. Agilo, Mingle, ScrumWorks, Target Process, etc.

Our team is currently evaluating several different Scrum tools. However, we are looking at selecting a single, monolithic tool, e.g. Agilo.

All of the “one-stop” solutions have their strengths and weaknesses with the serious enterprise type solutions being the best sort of fit. But all have some short comings.

After reading the paper “Peer Code Review: An Agile Process” over at SmartBear I started wondering if we were trying to force adoption of a tool on a “best fit” basis.

I think you can take a couple of reference artefacts of the Scrum development process, say

1. user stories, epics and themes, and
2. the code base which must use a well-known SCM, e.g. SVN, Hg, etc.

Then if we take that as the common reference points for the tools employed then we would be able to use a group of tools to handle the different aspects of the Scrum process rather than try forcing a fit of a single tool would is a bit like forcing a square peg into the round hole.

In this way, providing you’ve agreed your common reference points, you can use several tools, each performing their role better than a could be done by a single component in a monolithic tool suite.

Is this a more sensible approach?

Are the two reference points I mentioned above suitable, or is their a better choice of points where the tools would meet?

cheers,

Answer 1

Well the agile answer to that is “it depends”. Try something, if it works for your team, persist else adapt/change.

Explanation: Low-tech tools are recommended for the primary benefit of forcing people to get off their chairs, move about, talk-n-interact and feel involved in the teams’ progress. However my personal experience is that adoption depends on the exact composition and attitude of team members. If the team as a whole doesn’t like moving about / agree on post-its, don’t continue with it ; try something else. Although more often than not, I see that “stuck” teams exhibit this resistance. You end up with a multicolored scrum board that has post-its that only the scrum master cares about.

The high-tech tools are preferred by the suits/management primarily because they can press a few buttons and have ready reports. The flip side is that humongous/periodic data-entry to keep it in sync. Now with agile project management tools, the progress (or lack of it) is more obvious (early), hence I’d bet on more of this in the future. If your management has already chosen an ‘organization wide standard’, then you’re stuck with it.

Currently I’m experimenting with a shared spreadsheet, which has the list of stories/tasks for this sprint coupled with computed burndowns. This sheet is projected on a wall during scrums + put on a network share if anyone wants to view it. Updates are done during daily scrums by the SM.