Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^2: Selling swimsuits to a drowning man

by sundialsvc4 (Abbot)
on Jul 17, 2014 at 18:23 UTC ( #1094105=note: print w/ replies, xml ) Need Help??


in reply to Re: Selling swimsuits to a drowning man
in thread Selling swimsuits to a drowning man

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.


Comment on Re^2: Selling swimsuits to a drowning man
Re^3: Selling swimsuits to a drowning man
by mr_mischief (Monsignor) on Jul 17, 2014 at 19:58 UTC

    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.

      I didn’t start the thread to debate the virtues or lack-thereof of SCRUM.

      However, I do feel obliged to observe the following:

      If the project is ‘[chronically, or not] ‘under-specified,” then “there’s your problem,” and the situation will never get better until, and unless, you deal with that root cause.
      “Specification” does not mean that you must know every aspect of everything before you are allowed to embark upon anything.   However, if your customer-base is flip-flopping between “we want this” and “we want that,” then this is a manifestation of your root-problem that nothing in “Scrum” is ever going to address.   You have to negotiate and cement these things and you should have done it well ahead of time.   Or else.

      A business customer knows his business, and he very-rightly expects you to also know yours.   Sure, he might be able to give you what you call a “user story,” in his own business frame-of-reference, but he can’t be expected to know anything about the software-machine that you are responsible for.   Yes, he knows what he wants, but no, he does not know how to make y-o-u-r software-machine do it.   He cannot know how his user-request translates into “changes to that machine, acceptance-test cases, roll-in scripts and roll-back plans.”   A wide gulf is fixed between these two perspectives, and a story won’t bridge it.

      Agile invites the framers who will be tasked with nailing-up the 2x4s to also figure out where the walls should go.   “What would you like to build today?   Or not.”   A recipe for project failure, and this is what happens.   You can’t “wander” toward the goal of building something that moves on its own.

      Today, this role is being filled by people who are able to mix “business analysis” with “systems analysis” with “project management” in a hybrid role.   They’re not programmers, although they must have been one for a long time.   They’re management.   And they do direct the project.   Their hard-hat is white, and yours is yellow.


      However, to steer this back to the OP of this thread ... here we had someone, who was an obvious huckster’s shill, selling a “weekend certification” in this snake-oil to a group of (I now surmise ...) “mostly recently-unemployed individuals,” for thousands of dollars a pop, while baldly claiming that you didn’t know how to write source-code to get it.   A certification in cosmetology but you never have to cut hair.   A certification in home-construction management but you never have to drive a nail.

        My customers are mostly sysadmins and developers. They understand computers pretty darn well. The specs change often because their priorities actually do change often.

        One week it's important to be able to add capacity to a set of servers more quickly. The next there's been a bug found in some third-party software that needs to be worked around. Some tool that does what was asked might have been too easy to misuse, and some junior member of their staff might have misused it. Therefore, new tweaks to protect the user from himself become a high priority that was previously unforeseen.

        Most software is not shrink-wrapped and put on a shelf. Most of it is written and maintained for internal customers or as part of an ongoing consulting relationship. Getting those people what they need quickly and then adding bells and whistles later, as time allows, is more important than having a full product two years from now.

        Agree with that, mr_mischief.   Totally.   It is much better to break a project down into small pieces whose completion and roll-out can be meaningfully overlapped.   That part of the Agile idea is very good.   The breakdown occurs in actual practice when the team is “pantsing” its way along, in a way that results in great amount of rework and a significant amount of “churn” in the source-code base.   Uncomfortably soon, no one really knows what’s in and what’s out, what’s done and what’s not.   Agile trusts the idea of a “self-directed team” far too much.   A programming team simply cannot opportunistically direct itself.

        A team should be able to move quickly and to make meaningful progress in short installments.   but, each time it does move, the move should “stick,” and go from one point of provable integrity and stability to the next one without “suh-prize” along the road.   This takes real, dynamic, planning.   Strategy, not just tactic.

        Instead, what do we get?   Weekend courses to teach you how to pour magic voodoo-sauce onto any project.   The myth of the “abstract I-can-manage anything PM,” taken to a new level of absurdity ... for profit.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (8)
As of 2014-10-25 21:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (149 votes), past polls