Re^2: Selling swimsuits to a drowning man

[locked_user sundialsvc4]

Straight from the manifesto book.   Well done.     And, you may be sure, this Monk does “understand it.”

And, in the end, it doesn’t work.   I’m sorry to say it bluntly, but it does not.   Too-many years of “I see dead projects” have shown me it does not, and you just can’t fool the coroner.   The entire proposition is geared around the notion that the clowns are running the circus “the rock stars” are ultimately running the show.   They get to tell the boss, by way of their guardian angel, how much work they will “accept,” and at that time they pressure for, as you say, “better specs” and the removal of pesky “impediments.”   In other words, what you are describing is:   “lone wolves, in a pack.”   Yes, you (whoever else you are ...) are the thing that is standing in our Glorious Way, so hurry-up and march to our drum.   Yes, scrummers, you are literally making it up as you go, and preparing to blame everyone else for the actual root cause of the problem ... which is that you all have “gone off half-cocked.”   That there never was a real, thought out in-advance project plan to begin with.   And that yet-another project failure, or shortfall, is anyone someone else’s fault.

Multi-million dollar projects do not have to fail ... including yours.   The only thing that is required is:   serious advance planning (including firm advance commitments), test-driven development, and the recognition that this thing which we are building is a Machine that will operate unattended, and unknowingly, entirely ruled by if/then/else controls.   We are constructing an automaton.

(Tweeeeet!!   Time out!!)   I do not intend, nor do I wish, to divert this thread 90º toward a debate of the (non-)merits of SCRUM.   There is a better way to build a machine, or a motion-picture, or a building, or any other multi-million dollar project, and every other industry ... except(!) this one ... has already found, and perfected(!), an effective and repeatable way to do it.   They have no need to fix blame.   When the time comes to shoot film, they know exactly what to shoot.   When the time comes to pour concrete, that slab will not move nor be adjusted for the next fifty years.   Whereas the only thing that this self-important and self-aggrandizing industry has managed to do is to canonicalize repeated failure, by means of nonsense like this.   Therefore, I suggest that we instead take our lessons from the successful industries of construction, motion-pictures, machine manufacturing, and so on, instead of arguing that our failures are because we’re so damned different.   (We’re not.)

Software is a Mechanism.   Not a thing.   Not a directory of source-files.   That’s the light-bulb moment.   Go buy a Kindle and read that book.

But, please ... beyond this ... a new thread, please.

[mr_mischief]

It was you who started the thread, so it's odd that you find it so distasteful a thread.

Scrum isn't for designing rocket trips to the moon. Not all development happens on projects of that scale. There are projects for which it works and ones for which it'd be downright silly.

Scrum is for those quick-turnaround improvements on chronically under-specified projects. Not all developers work on waterfall projects with everything designed well by engineers then implemented in code. Lots of development is "we want this" and two weeks later "we want that". Scrum is a way to deliver "this" quickly and then switch to working on "that" rather than delivering a wrong "this" that had lots of things still underspecified six months late.

It's a system of encouraging quick turnaround of small changes. Planning up front that's not perfect results in lots of changes later anyway. If you have to throw away work it's better to scrap a couple of weeks' worth than a couple of years' worth. It's just a way to deal with not having a perfect understanding of what your customer needs up front in the first place. This is a good thing because the customer usually doesn't know what they want up front, either. On top of that, the customer's needs can change during development if you take too long to deliver.

If that's not the type of project you're working to deliver, then it shouldn't be delivered under Scrum.