|
Re^5: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by chromatic (Archbishop) on Dec 16, 2010 at 18:20 UTC
|
As I wrote before, every reputable agile method to my knowledge suggests delivering a product with actual customer value (no matter how minimal) from the first iteration. Which agile methods to your knowledge suggest differently?
| [reply] |
|
|
| [reply] |
|
|
I got a chuckle from your reference to "so-called agile".
I find it depressingly common at work to hear someone argue that one course of action
is superior to another simply because it is more "agile".
When challenged, the arguer often has only the vaguest notion of what "agile" truly means.
So I prefer not to use the word "agile" when discussing alternative courses of action anymore.
Like "object-oriented" and "strong typing", the word "agile" has suffered from semantic diffusion, as pointed out by
Martin Fowler:
Semantic diffusion is essentially a succession of Chinese whispers where a different group of people
to the originators of a term start talking about it without being careful about following the original definition.
These people are listened to by a further group which then goes on to add their own distortions.
After a few of these hand-offs it's easy to lose a lot of the key meaning of the term unless you make the point
of going back to the originators. It's ironic that it's popular terms that tend to suffer from this the most.
That's inevitable, of course, since unpopular terms have less people to create the Chinese whisper chains.
A related indicator to popularity is desirability. A word that sounds good may be more likely to suffer from semantic diffusion.
'Agile' sounds like something you'd certainly want to be, the antonyms of agile aren't at all appealing.
Who would want to still be merely 1.0 of the web? Kent Beck noticed this effect and thus deliberately picked Extreme Programming
as a name because it is less inherently desirable: 'extreme' is often used as a pejorative. Using a less desirable term may reduce
semantic diffusion, but I don't think it avoids the problem completely. After all we saw semantic diffusion occur
to 'object-oriented' which is a neutral term.
Semantic diffusion is a painful process to watch, particularly for those who find the ideas useful.
At the moment I see signs of despair for both of these terms, some people in the agile world
are talking of ditching the word agile.
| [reply] |
|
|
|
|
| [reply] |
Re^5: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by JavaFan (Canon) on Dec 16, 2010 at 20:30 UTC
|
It may happen more often in agile teams, but then there's less to "throw away", as they make small steps, and detect they're wrong earlier. If you first spend 6 months designing, then 6 months implementing, and it turns there's a flaw in the design and it's back to the drawing boards. It may have taken you a year to get to a case that needs scrapping, but there's a huge cost for that one time.
But still, it's not the same as scrapping metal. If you have a production line producing expensive, complicated cuts, doing the last cut wrong is expensive. The metal has to be scrapped, and the time spend so far is completely wasted. But coding isn't the same - there's no "scrap" in the sense of a complete wasted effort. As Thomas Edison said "I have not failed. I have found 10000 ways that do not work". Taking a decision (whether it's in the design phase, or in the coding phase) that turns out to not work, does have value. You now know what doesn't work.
One may argue that a baby that keeps falling over is wasting effort: it should spend a few months studying how people walk, then walk on its first try. But babies don't. They try. They fail. They learn from failure. In the end, they walk. | [reply] |
|
|
Except you are not considering the baby a "walk consultant" and you are not paying the baby to deliver a "walk method".
Again, the problem is not in the bugs, is not on the risks, but on the neglected requirement analisys of what the first release should be. I've seen too many so-called agile teams work the first release in "sprints" and have each of those sprints point to different directions because the initial requirement analisys for the first release was neglected, since it wouldn't fit the "two months"/"two weeks"/"whatever"
| [reply] |
|
|
(Blink!) Did you actually hear yourself? “Six months designing...” (Then...) “Six months implementing...”
Obvious question: Heavens to Betsy! Just how many “Six Months” does it take?” . . .
Inquiring Minds want to Know ...
Thomas Edison might quite-plausibly be excused; after all, no one had invented a Light Bulb before. But, let’s face it... “by now, we are supposed to know what-the-hell we are doing!”
I mean... even in the worst possible of conditions, our dear CMC Machine Shop does not have to tell Boeing, “so sorry, Boss, see you next year!”
“Jimminy Cricket ... we do need to deliver!” This is Engineering, after all ... isn’t it?
| |
|
|
This is Engineering, after all ... isn’t it?
No. And programming isn't baking, nursing or farming either. Or piloting. Or dentistry. Or archeology.
| [reply] |