Using Tools in Agile: Can Tools hinder rather than help Agile processes? How would you employ tools in Agile Development?

Tools can be an asset if it the right tool. It could be a rock star with one enterprise and booted off in another. Right tool selected for the right process given to the right people results in right results. It is when people start staring at their screen rather than communicating, that’s where the Agile process fails. People sometimes get too much engrossed in the tool that they get sidetracked and forget the real benefit to the project. In my opinion, keep things in perspective is the best approach.


What are your experiences in this area?

Views: 20

▶ Reply to This

Replies to This Discussion

Permalink Reply by Iain McCowatt on October 21, 2009 at 12:20
On those - mercifully rare - occasions when I am immersed in tool development, I like to schedule "people days" to regain my humanity.

An irony of agile is that continuous integration is so tool dependent, yet tooling can be so slow and lumbering.
Permalink Reply by Brian Buckmaster on October 21, 2009 at 15:45
The real irony of Agile is that it is being peddled as something new or unique. This is an indication that we may have run out of ideas for improving software development. I have a recommendation for an anthem for Agile: "Everything Old Is New Again" - Barenaked Ladies...
Permalink Reply by Glenn Halstead on October 21, 2009 at 23:07
What Barenaked Ladies album is that on? I can't find it on Spotify.
Permalink Reply by Mohinder Khosla on October 21, 2009 at 13:01
The key questions taken from a recent presentation, to which I would like answers, by Agile Manifesto guru Jon Kern are:

Can tools help build stories and how?
Do developers use tools while staying true to Agile and which one?
Does test management and functional test automation work in Agile?
How open source tools fit into Agile processes?

The key question is 'DOES TOOLS AND AGILE MIX?'

A comment that is touted around is 'A fool with a tool is still a fool'
Permalink Reply by Joe Strazzere on October 21, 2009 at 16:01
"The key question is 'DOES TOOLS AND AGILE MIX?'"

Of course - why not?

It would be hard to imagine a scenario where someone doing software development or testing (using Agile, or any process) wouldn't use at least some tools.
Permalink Reply by Brian Buckmaster on October 21, 2009 at 15:37
Methinks there is an underlying reliance in the use of tools behind the question. In my experience, there has been an undue emphasis on using tools, in particular, test automation, in the test process, mainly by management. It is generally assumed by the pointy-haired population, that test automation will lead to significant gains in productivity by permitting more testing with fewer errors. This is simply not true. The process of designing, creating, debugging automated tests is a software development project in its own right, with all of the attendant overhead. The only benefit is if you can get from test automation is if you repeat the same tests over and over, amortizing the test development costs over repeated executions. This makes sense when doing reression tests - but this assumes relatively (mature) SUT, where you're mainly fixing bugs and/or introducing relatively few features. I've yet to see automated tests effectively employed at the unit test level. And don't even get me started about so-called Agile development.
Permalink Reply by Sherilyn Tasker on October 21, 2009 at 22:54
We use a lot of blu-tack and post it notes....best tools ever
Permalink Reply by Glenn Halstead on October 21, 2009 at 23:10
Tooling / test automation is useful where you have repetitive work requiring little active analysis.
Permalink Reply by Justin Hunter on October 22, 2009 at 17:40
I would recommend two tools in particular:


Lowdown allows users to create traditional user stories very easily.


For people who are interested in quickly generating highly efficient test cases that use combinatorial testing methods that have been shown to more than double the amount of defects found per tester hour in a few dozen proof of concept pilots (and take less than half as long to put together than manual methods of test case selection and documentation), I would recommend our company's Hexawise test case generator. It reduces the time required to identify tests and creates more effective tests than people can generate on their own.

- Justin Hunter
Blog: http://hexawise.wordpress.com
Permalink Reply by Justin Hunter on October 22, 2009 at 17:45
Three additional screen shots... (First from Lowdown, 2nd & 3rd from Hexawise)


.


.

Permalink Reply by Robert Healy on October 22, 2009 at 22:08
Hi Mohinder,

We moved a while back from Waterfall to Agile and one of the things that facilitated (and partially drove) the change over were some of the commercial tools. I'm not being paid by them so I'm not going to give any free advertising.

The tool we used was a cloud based tool which facilitated high visibility and clear ownership of tasks, a way of measuring task progress and way of planning based on capacity. The tool itself cannot create or even dissect user stories - this is done by proxy customers and the relevant teams - but it can help in breaking down stories for planning and measuring the progress as these are completed across iterations. In the tool we use test cases (usually automated) are a necessary prerequisite for the story to be marked as completed for that iteration.
Our tool comes with it's limitations and headaches and I must remember the "fool with a tool" quote.

Tomorrow I'm suggesting Iain's brilliant idea of a "people day", it's Friday so I'd prefer a hol-i-day but it's a very good alternative.

Thanks,

- Rob
Permalink Reply by Mohinder Khosla on October 23, 2009 at 8:37
For the benefit of those who have not read the Manifesto for Agile Software Development here it is for your information.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more

There are three main ingredients to the success of any software development project ie people, processes and tools of which tools come last. Some people think tools are surplus to requirement because we keep fighting with them and when the time scales are squeezed they distract us from our ultimate goal of delivering application on time. How Agile teams can implement automated tools and still keep on track is the answer I am looking for?

RSS

© 2012   Created by Rosie Sherry.

Badges  |  Report an Issue  |  Terms of Service