Long live the Waterfall Martin Jansson
A cheer to those of you who were able to attend this conferance: http://www.waterfall2006.com/
My favorites:
http://www.waterfall2006.com/crispin.html
http://www.waterfall2006.com/jeffries.html
Thank god everyone is not a believer of the hype around the Agile Movement. Process is king!
I would have loved to see the keynote by Brian Marick:
“Put Testing Where It Belongs–At the End”
http://www.waterfall2006.com/marick.html
I have made some calculations with Grubb’s method, and for a conference like this, with the specified objectives, taking 6 Standard Deviations into account, the delay will probably mean that the conference take place early next year!
Should we book some group tickets?
Intresting blog brother. I have couple of questions:
What is your (all three of you) experience of Agile?
Why is agile bad?
Why is Agile a hype ? Is it because it works or because every one is fooled by the dark side? 😉
Welcome Ola!
Agile is just a hype, just like the internet. We know that noone really use it, they just “say” they do.
PS.
This was a ironic article, perhaps not all too obvious. Still, I used the famous Irony-tag.
All three of us got lots of experience with different kinds of project models. Is there anything in particular you is interested in?
DS.
I know that Agile is not flawless and its also very hard to speak of all practices (xp,scrum, agile, lean etc) as one “hype”. Waterfall is very good for predictable project (made by engineers and architects). From my perspective game design benefits very much from something else than waterfall (i.e scrum).
I’m interested in if Agile is particularly hard to use as a tester. What is your opinion on that?
I have never worked in a truly Agile project, but I’m pretty sure that the actual work as a tester (providing important information about the application) isn’t easier or harder because of the process (the people and the product are more important.)
However, there are many ancient ideas and expectations about testing that are difficult to fulfill.
In Agile it is probably more difficult to answer questions like:
* How many testing resources are needed for each period of time?
* How many tests will you run?
* When will testing be done?
On the other hand, for most projects it is possible to assign a reasonable number of test resources, and then do your very best.
“I’m interested in if Agile is particularly hard to use as a tester”. If Agile means getting builds more often and earlier, thus being able to spend more time testing than waiting for testing, it is easier to use.
One down side with Agile is that project members tend to cut down on describing what they build and what they plan. Things are more flexible and it often means that testers has to do more guessing. Naturally specifications are not the salvation to everything, but my experience so far is that you get less information in general.
Whatever you wish to call the project model I think that working incrementally, not describing the whole system from start, is a good thing for all actors in the project.
[…] was originally meant as an answer to the (ironic) thread http://thetesteye.com/blog/2009/06/long-live-the-waterfall/ where a new thread was forked when Ola Janson launched a couple of questions regarding agile […]