Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^3: "Bah! Scrumbug!" (Lessons from the scrap-bin)

by chromatic (Archbishop)
on Dec 15, 2010 at 16:57 UTC ( #877315=note: print w/replies, xml ) Need Help??


in reply to Re^2: "Bah! Scrumbug!" (Lessons from the scrap-bin)
in thread "Bah! Scrumbug!" (Lessons from the scrap-bin)

... rework when the system is not yet deployed is always scrap...

I question that because:

... keep room for fixing bugs...

... and:

In a project you really need to do the "big design up-front", otherwise you'll have too much scrap, and nobody wants to pay that.

"Just plan harder so you don't write bugs" is hardly realistic.

(If you define "scrap" as "stuff you have to throw away because it has provided no value", then you have a circular definition you can only break by redefining "value". You get to pick what you rework: is it the BDUF spec several months later or is it code minutes to days later?)

Even if you want to embrace agile methodologies, you need to understand that the first release must be managed as a project, with a start, an end and a specific product to deliver.

Every reputable agile method of which I am aware suggests this explicitly.

  • Comment on Re^3: "Bah! Scrumbug!" (Lessons from the scrap-bin)

Replies are listed 'Best First'.
Re^4: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by ruoso (Curate) on Dec 16, 2010 at 02:06 UTC

    The problem are not in the bugs -- bugs are inevitable. What you can avoid is going in one direction for a time and then realizing that was not the right direction before delivering any value to the customer. This is the kind of rework that nobody wants to pay for, and that happens too often in some so-called agile teams -- specially the ones that try to agil'ize the first release.

    daniel

      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?

        I'm not saying agile methodologies suggest it, I'm saying so-called agile teams do it too often

        daniel
      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.

        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"

        daniel

        (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?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://877315]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (2)
As of 2021-01-20 04:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?