Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^4: Selling swimsuits to a drowning man

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

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

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.

  • Comment on Re^4: Selling swimsuits to a drowning man

Replies are listed 'Best First'.
Re^5: Selling swimsuits to a drowning man
by mr_mischief (Monsignor) on Jul 18, 2014 at 14:36 UTC

    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.

Re^5: Selling swimsuits to a drowning man
by sundialsvc4 (Abbot) on Jul 18, 2014 at 16:21 UTC

    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.

      Well, yes, there are certainly risks and caveats. Scrum is not perfect, but it was developed to address the problems created in another situation that was even less perfect.

      I'm not trying to highjack your thread about there being no magic bullets by trying to push a particular magic bullet. Scrum isn't that. It isn't a magic bullet, and people who say it is are deceiving people.

      My point is to not dump out the baby with the bathwater. There is some merit to some of these things. The CCIE is a very difficult and meaningful certification. Scrum is IME a (not the) useful way to adjust to rapidly changing business priorities. Object oriented programming is really useful to model some projects. Databases are really very good for some things, while a light flat-file system is better for others.

      Just because we're tired of overblown sales pitches doesn't mean we should reject summarily everything being pitched. Be wary. Be jaded. In the end, though, weigh some merits and make informed decisions.

        ... and, as we have discussed offline amongst ourselves ... I agree completely with all of the points that you have raised here.

        Uh huh ... there are “people saying it,” and, yeah, they are “deceiving people.”   However, all the rest of us have been plying this most-peculiar trade, now, for a very (bah! never-mind!) long time, and reckon we have work to do. . .