in reply to "Bah! Scrumbug!" (Lessons from the scrap-bin)

I have read your SCRUM articles with great interest. I myself was once trained in eXtreme Programming but more recently every company has to SCRUM (another silver bullet?). So I Enjoyed your articles very much and it got me thinking as well:) However, what you wrote in you post is, IMHO, wrong.

Let me give an example. We developed a prototype to elicit and validate the requirements. Now that we know what we want we throw it away and redevelop it properly. We are happy to throw it away, although it sort of works and the look-and-feel is OK, the quality of the SW is very poor. Management on the other hand does not appreciate this, why throw something away that works? In fact if we would not throw it away, let's assume we were forced to keep it, we would have areal problem. It's basically exactly as moritz++ describes in his post: "The things that really devastate a project are things that should wind up in the scrap bin, but don't."

I don't think the "scrap rate" metric is very useful, maybe for some specific types of projects. If you do a lot of refactoring the scrap rate will probably be high and that's perfectly OK for many projects.

Cheers

Harry

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

Replies are listed 'Best First'.
Re^2: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by eyepopslikeamosquito (Archbishop) on Dec 15, 2010 at 11:34 UTC

    I have read your SCRUM articles with great interest.
    Which articles are you referring to? Just in case you're referring to the Nobody Expects the Agile Imposition series, please compare the author names. :)

[reply]
[reply]
Re^2: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by locked_user sundialsvc4 (Abbot) on Dec 20, 2010 at 02:19 UTC

    To my way of thinking, “management’s” perspective on this situation is pefectly defensible ... even to the exclusion of all other possible perspectives.

    From “management’s perspective,” it does indeed seem that they have just paid you whatever-it-is your salary happens to be.   And now, what exactly do they actually have to show for their hard-earned money?   It would seem that you are saying ... “100% sunk cost!” ... and, now you are dishing out to me what certainly appears to be very-lame apologies for a double-helping of thoroughly unacceptable excuses for blatant incompetence.   (Ahem...)

    Please explain to me, once again, why I must pay a competent building contractor to construct a rather-routine building twice, in order for said “competent” building contractor to figure-out how to correctly build such a building once? . . .

    Are you sincerely telling me that, at this late hour, I must fund and pay for a building-construction school in order to timely obtain for myself (and my clients...) a competently-constructed rather-ordinary building?

    “I know how to budget for $1,000,000.00 worth of useful improvements to a city street, and actually get them.”   But now, it certainly seems to me that you are telling me that I must invest $1,000,000.00 in experiments ... just to “figure out how to” (throw away) $1,000,000.00 more...

    “Pardon me if I am not impressed.”

      Please explain to me, once again, why I must pay a competent building contractor to construct a rather-routine building twice, in order for said “competent” building contractor to figure-out how to correctly build such a building once? . . .

      What makes you think software development is anything like construction? Given that I can duplicate the equivalent of a building in the software world with the cp command until my fingers get tired, the economics of software and construction seem rather different.

[reply]
[d/l]
        Don't you know? In sundialsvc4's world, every construction project is delivered on time, on budget, and completely flawless. Each contract is given by customers who know exactly what they want, never change their minds, and have foreseen all possible consequences.
[reply]

In Section Meditations