Is One Tool or a Suite of Tools Better for Scrum?

Posted by Rob Wells on Stack Overflow See other posts from Stack Overflow or by Rob Wells
Published on 2009-12-15T14:04:57Z Indexed on 2010/03/30 1:43 UTC
Read the original article Hit count: 471

Filed under:
|
|

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,

© Stack Overflow or respective owner

Related posts about scrum

Related posts about tools