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

Closed. This question is opi开发者_运维百科nion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this 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,

---

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.

---

Personally I can recomend the targetprocess, http://www.targetprocess.com/

I learnt alot SCRUM by just working with this tool.

---

Are you doing SCRUM at the moment? Have you done many iterations?

If not, then I suggest you probably don't know what you need yet. SCRUM can be done with whiteboards or spreadsheets to start off with, moving over to tools IF you decide that it will be valuable.

---

You sound further along in the adaptation then we are. I have been trying to move my team to an agile process for a couple of years and we are getting better and better at it. We have used some enterprise level tools in the past. Mainly from Rational. They always seemed to over complicate what should have been a simple procedure. For us, the get the simplest tool to fit the need seems to be working. Lots of white boards, spontaneous stand up meeting for anyone requesting one. CVS and automated build scripts with lunt (moving to Hudson). Jira for all the project managing fun. We have really been able to increase productivity and cut cost. We are a small team and all collocated.

---

What is wrong with our current set of Scrum Tools?

That is a good question that may not be asked here as management may just have money to spend and they want to buy some big shiny tool package as a sign that they care about the team and want things to be better. Not that it is a bad thing in wanting to throw money at a problem, but could we at least be smart about doing this?

---

i recommend JIRA Greenhopper as it has a planning board, a task board and a burndown chart that seems to hit all of the SCRUM concepts