There was an absolutely fantastic question on the agile testing list today:
We started Agile process since few months and everybody has issues with estimations.
I wanted to know if there is any estimation tools available
Please advice
This really is an honest question by someone with a real (and all too common problem), but to anyone that expects to find a tool that will solve this problem I’d like to recommend this. It supports Windows and Linux and you can plug it in either into a PCI or USB slot. And if you’re struggling with estimates, it’s probably going to give you as good an estimate as you would get from any other much more expensive tool.
Henrik Kniberg did a session at Agile 2008 where the participants voted for problems they encountered in their teams and “let’s buy the biggest most expensive XP tool” and expecting that will solve all your problems was on the top of the list. Curiously enough, there were several vendors selling just that in the hall outside the conference room. As Agile 2009 is about to start next week, I have no doubt that people will be trying to pitch some new revolutionary solution for what are essentially human problems.
It’s amazing how many people genuinely expect that there is a magical tool to solve every problem and don’t really want to think about why the problem is there and spend some time learning what to do to avoid it. I think that this psychological phenomenon deserves to be treated as a serious disease, and I propose to name it Toolitis.
|
|
I’ve also seen many examples of the opposite problem – developers persisiting with doing things manually or developing their own tools – when a perfectly good tool is available to do the job already at a fraction of the cost. Let’s call this second problem Toolphobia.
I agree that toolitis is a serious disease.
My reply to the original problem is here (http://www.developsense.com/2009/08/test-estimation-is-really-negotiation.html) and here (http://www.developsense.com/2007/01/test-project-estimation-rapid-way.html). It involves no tools; just the human arts of negotiating and using heuristics to deal with uncertain situations.
—Michael B.
Gojko,
Funny and thought-provoking post (especially the tool you recommend)!
In a long ago former-life, I worked as a mediocre lawyer at a good law firm. This post and the comments to it take me back to law school where, more than once, I would read one judge’s opinion on a case, think “Wow, great points; he’s right” only to read the dissenting opinion on the case and think “Man, brilliant points; he must be right too… hmmm, waitaminnute.”
Same theme here: I agree with all three of you to some extent.
Kudos to Mark for highlighting the other real issue of toolphobia. There are lots of good testing aides out there including, IMHO, our Hexawise test design tool. Using good tools is – on balance – a GOOD thing, provided, of course that testers can avoid the temptation to check their brain at the door and assume that if they “follow the tool” that their job will be taken care of for them. Great testing requires great testers; tools – used sensibly (as opposed to slavishly) – have the potential to help speed up certain processes, optimize other processes, and encourage collaboration between team members.
A few minutes before reading your post here, I sent out a tweet highlighting his very insightful and very amusing blog post that he referenced above… “@Hexawise RT @michaelboltonJust published: Test Estimation is Really Negotiation http://bit.ly/2nSP1i #softwaretesting #testing #qa Me: Amusing & good” It is definitely worth a read; it is no less amusing than your post and his recommended approaches to the estimation problem are, I suspect, more likely to be successfully implemented with good results than your admirably bold recommendation.
Having said that, I would be willing to pay good money to participate with a testing team that used your “recommended” tool for estimation and saw the testing cycle out to the end using its results….
- Justin Hunter
Founder of Hexawise
I’m a software toolsmith (one-man consultancy for the last three years) and I have a standard reply to these sort of discussions.
“No tool can solve all your problems, especially if they are people problems. Good tools can help reduce friction in an organization, and possibly save you some time.”
or more succinctly
“No tool is going to make it easier to work with jerks”
I agree that looking to a tool to solve your problems is rarely a good idea. I think that there can be other reasons for this though – it’s not always about expecting the magical.
Particularly with approaches like an agile approach to process, but also others, people often find themselves in a “first step” paralysis mode. They have a broad feeling for what they’re looking to be doing, they’ve grokked the wider principles behind the approach, but they’re feeling around for where to start. I’ve experienced this feeling in many areas of life, and it’s disconcerting (I don’t think that’s particularly an admission of my idiocy, though I’m not ruling it out).
I think what a lot of people are looking for the stabilisers, that a tool might provide. Sitting down with a blank sheet of paper is more daunting than sitting in front of a piece of software which starts asking you questions. Even a text box with “estimated story points here:” gives you a nudge.
When people are still looking round for tools, it may be that they’re foolishly searching for a magic bullet. It may also be that the guidance, community, etc. for what they’re trying to do hasn’t really yet provided much of a path to get started. This is probably particularly keenly felt with approaches such as agile, which almost eschew a “one true way” by definition.
Estimating is hard. If we want people to be able to solve those human problems (and I agree, they are) then maybe we need to look at making the problem more approachable in light of the weaknesses of human endeavor. Perhaps starting with a prescriptive approach (though it may not be the right one – you will find it later) is better than starting with a “find your own path” approach.
Just ramblings anyway.
This is the Silver Bullet Syndrome, something Brooks wrote about back in 1986 (No Silver Bullet – Essence and Accidents of Software Engineering). But this problem is not limited to tools – it encompass computer languages, methodologies, hardware and even people.
Many people read this great paper, but a lot of them are still hoping to find the magic tool, the miraculous methodology, the final language that will allows them to manage complexity with minimal effort.
Agile development, OOP, Design Patterns, JAVA, VB.NET, UML are all great tools, really, but they were never designed to be silver bullets. The problem is, some people (at least one in every company
) just buy a new tool or dive into a new technology, a new methodology, a new language, hoping that they will get a 50 % productivity improvement.
This is a real problem and it seems to be as old as software development. In fact, this attitude just leads to opposite results.
We have to tell them again and again and again : no, there is no Silver Bullet – you want something great ? It will not be cheap.