I like to go to “networking events” now and again (if the price is cheap), but sometimes it is depressing to watch the hawkers.

The thing that they are selling are little TLA’s (three-letter acronyms) to attach after your name.   And, apparently, they’re not cheap.   But one comment that was announced to the crowd, by someone who I’m pretty-much sure was a “shill,” went something like this:

“The very best thing I did for my career was to become a “SCRUM Master Level II”!!   I had to dig to find the money, but you know, you have to ‘invest in yourself to get ahead.’   You don’t even have to know how to program.”

(Blink ...)

And then there was this other guy – let’s be kind and say he didn’t exactly look like Chuck Norris – who nevertheless styled himself a “third-degree black belt master” about some sort of management-theory or another . . .

So, is “the blind leading the blind” an accepted business-practice these days?   Even though the person who runs the shop where I get my car serviced might not be holding an grease-gun when he introduces himself to me, I do want to know that he has held one in the fairly recent past.   And, while I know that jobs like “car servicing” require a tremendous amount of intellectual study these days, at the end of the evening it’s all still all about:   a machine.   You can’t abstract-away the experience of having actually done this and replace it with a little piece of very-expensive paper.   You can’t learn to swim by reading a book about it.

Now, I, likewise, do not wish to here “abstract away” the value of intellectual study, or employee training, or personal self-education.   That’s not my point.   But I feel like I was watching swimsuits being sold to drowning people.   A little friendly-conversation around that room showed me that the length of the courses was usually “over the weekend,” and the prices of those weekends were high – $1000 to $3300 (USD).   Ouch.   If I had thought that I could just buy a bottle of “SCRUM sauce” and pour it over my career (with or without saying, “Shazam!”), I might at one time have been fairly-easily convinced to do so.   Maybe I’m just too old and gray to believe it now.   I do not see a credible value-proposition here, despite the intense sales pressure.

So ... can I now ask the Monks for what is your perspective here?   Whether you, yourself, bought a Golden Ticket, or (I think more-likely) hired one, or didn’t, what were your experiences and insights into this matter?

Replies are listed 'Best First'.
Re: Selling swimsuits to a drowning man
by wjw (Priest) on Jul 16, 2014 at 18:13 UTC

    So, is “the blind leading the blind” an accepted business-practice these days?

    In short: Yes. More importantly from my perspective is that it does not stem from salesmen; but instead business management and leadership. I realized this around the time a book came out(heavily touted by corporate management as something everyone at every level should read) which stated in the forward that:

    "...leadership is finding a parade and getting in front of it."

    I had been working for that well respected R&D company for four years at that point, and it is at that point that I lost all respect for that company. Unfortunately, that is the general attitude about career advancement these days and work performance measurement too. It is pervasive in what I have observed over the last ~15 years.

    Generally, I try to keep my posts here pretty much on topic, but this is one issue which threatens to get me all up on my high horse. So, I am going to allow myself to rant just a bit.

    Some of this is spurred by the excellent series posted by eyepopslikeamosquito, Nobody Expects the Agile Imposition (Part I): Meta Process and follow ons. I am still reading through that work, cogitating, and attempting to wrap my abused brain around what all that means to me. The point brought up here is a tiny micro-symptom of the business "Magic Pill" syndrome. So many pills to take over the years! Just look at the list of references and the volume of subject matter!

      A few of the pills we have/are taken/taking:
    • RUP
    • Lean Mfg.
    • World Class Mfg
    • Black/Green Belt
    • SPC
    • SCRUM>
    • AGILE
    • ...all the other training in leadership, productivity etc...
    In a poor attempt to be fair, I learned some cool stuff from almost all of these methodologies/philosophies.(OK, enough of being fair). Each one of these was sold as The solution to today's and tomorrows problems. If not by the author and authors sponsors, then by the management team that 'bought in from the top down -100% committed!) There are good things to be learned from each and every one of those methodologies/philosophies. But they are NOT solutions. They never were, and they never will be. They are tools! However we treat them as a pill you hand out while singing hymns of praise to the guy who wrote the white paper introducing this revolutionary approach to solving business problems, and pushing folks to do things they know won't work every time, and often not even most of the time.

    I alluded to this in a response to the previously mentioned articles. What I have concluded from my contemplation regarding that writing thus far, and within the context of my experience is:

    1. There is no pill/formula/methodology/philosophy that provides solutions to problems
    2. There is a tendency to believe that #1 is not true.
    3. We substitute complexity for a basic lack of principled work ethic
    4. We encourage the "Magic Pill" by quickly promoting those who introduce "Magic Pills" instead of expecting them to live with the medication they foist on the rest of us, thus exacerbating #3
    5. Our metrics for measuring performance are as short sighted as most business outlooks: about a fiscal quarter in length
    6. Our metrics create competition where there should be collaboration and cooperation. Way too much focus on the individual as compared to the team, and more importantly: The work at hand.
    7. We take our pills regularly even though we know them to be doing more damage than good. We do this because we are afraid of being left behind.
    What we need to do is:
    1. Be open to ideas, and flexible enough to adopt the pieces that work for us, while acknowledging that other pieces might work much better for others, even within the same department within an organization
    2. Be open to telling leadership what works and what does not, firmly, professionally, and without rancor.
    3. Be respectful to ourselves and thus to others around us in the work place. Competition is good in its time and place. In my experience, it is bad news when it carries into the job at hand.
    4. Be patient and honest with ourselves, our roles and our abilities.

      Not one of those "Magic Pills" ever delivers in the long term. They don't build skills, develop relationships, enhance productivity, or deliver on any of the other promised benefits. People do....we deliver, a system does not. A system is a tool until we let ourselves become tools of some silly system. Cart before the horse? It takes time to learn to use a tool, the more complex the tool the longer the time it takes... The focus needs to remain on the job at hand, not the tool to do the job. If the tool requires so much effort that it detracts from the focus on the job at hand, then it is the wrong tool.

    5. Be willing to be left behind for a while.

      Don't have to be Luddite like, but being in front is not always an advantage, and there are advantages to being at the back of the pack for a while. (I am reminded of the little creatures in Canada and Alaska that swarm up, start running, right over cliffs to their demise,,,lemmings?). Yeah, sometimes it is better to feel left out than it is to be included in a game of follow the latest leader.

    The disturbing thing about that salesmen who is selling swimsuits to the drowning isn't the salesmen. It is the drowning people who buy from him. His pitch fits right in at the individual level in a system of levels that encourage pill popping. Face it: He would not be selling if we weren't buying... and we buy because we know we have little chance of advancing without proving we popped the pill corporate prescribed this week. The frustrating thing is that even if we take the meds, there is little chance that we will get any real good out of it. After all, to be a level II SCRUM master, you don't even have to know how to program.... End Rant:

    Update: s/SCUM/SCRUM/ LMAO @ myself! :-)

    ...the majority is always wrong, and always the last to know about it...

    Insanity: Doing the same thing over and over again and expecting different results...

    A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

      After all, to be a level II SCRUM master, you don't even have to know how to program
      Indeed. I've noticed that folks who strongly pursue the Scrum Master role as a career either cannot program at all or are mediocre programmers. Which I'm fine with, BTW, because I like to see talented programmers writing code, not running stand-up meetings. The Scrum Master role is essentially a management/co-ordination/facilitation role requiring organizational and people skills, not technical ability. It can be a tough gig too, based on this excerpt from a Ken Schwaber talk:

      You will have, if you use Scrum, someone on each team whose name is, it's called the ScrumMaster, also known as "The Prick". And this person's job is to make sure that you don't cut quality. D'oh. And they have no authority but they, what they can do is if we've defined that an increment has a certain level of quality for it to be demonstrated to our product management, their job is to make sure that quality's there. And if the quality isn't, not to let you demonstrate it, but instead to say to the product manager, "Hmph, we lost our heads, we're not done, it's gonna take us another month to finish this".

      This person is probably the least loved person in the world because they stand right at the nexus between product management believing that any amount of stuff can be done and our willingness to help them cut quality to support that belief.

      The burnout rate on these people is usually, like, 13 to 14 months. Throw 'em away. We often get them from hopeless, professional areas like QA. People in QA are used to doing incredible things with no authority, no respect, and no hope of success, so that's where we take these people.

      -- Ken Schwaber, Google tech talk on Scrum, Sep 5, 2006 (46:34)

      The Scrum Master role reminds me of the Political commissar, commonly attached to military units during WWII. The political commissar role was not created to do any actual fighting, rather to teach ideology and exercise social and political control over the soldiers, to guard against anti-revolutionary thought and action.

      On the subject of non-programmers making big bucks in the software industry, I'm reminded of this little piece from Joel Spolsky:

      The whole fraud is only possible because performance metrics in knowledge organizations are completely trivial to game. The best part is that most management consultants, the stunningly good-looking, bright, earnest chipmunks with 4.0s in Russian Lit from Harvard who work for these companies, have absolutely no way of knowing this, so they can go through this whole exercise without even knowing that they're doing it! They get all the way through the 2-year associate program on their way to MBA school without even realizing that they haven't done a goddamn thing about productivity, all they've done is caused a fairly pointless transfer of wealth from ExxonMobilConoco to BainMcKinseyGartner's senior partners. And it's a lot of fun! First class flights to Houston and Oslo! Helping the world be more productive! Rock on, young stunningly-good-looking Management Consultant.

        It suddenly occurred to me as I read this where a good portion of my discomfort with these methodologies comes from: The Military and my upbringing. Not that the two were all that similar in any other way than both consisted of consistent roles with well defined expectations and a consistent language describing and defining those roles and expectations.

        There are, to my way of thinking, some very good functional reasons for the rigidity of those role descriptions and definitions. The main one is that everyone knows their basic functions. They are simple:

        • Functional Skill Set - ex. Grunt, programmer, eldest sibling.

          In the service, everyone was a Grunt first. You had to know how to kill(shoot, toss things that go boom, set up stationary things that go boom when the other team was properly aligned as a target, avoid the other teams things that go boom, keep oneself reasonably serviceable in nasty environments, etc...) Everyone had the same basic skills and there were metrics, and if you didn't measure up, you were out(which is a big favor to everyone including the ousted; better ousted than dead).

          An individual on a development team should have the basic skills to program 'something'. Otherwise, they should not be on a development team. The basic metric is you can write some sort of functional code or you can't. If you can't, what the hell are you doing in software development?

          In the family, the eldest helps build the basic skill sets of the younger and protects them from ignorance. Up until their own ignorance/stupidity(in my case) gets in the way of that, which is when mom/dad step in and make sure the problem isn't being handed down the line. Some pretty simple metrics their too, though I am sure it varies from family to family.

        • Role - While the basic skill sets are common and expected, the role one plays on the team may vary.

          In the service it is rank and rank type(Officer/Enlisted). The skill sets may differ(supply vs motor transport), but even so, those support roles are still aimed at the basic skill sets which enable the core mission.

          In a development team, there may be a SCRUM master or a technical lead or a developer. Each has a role which is aimed at the basic mission which is writing serviceable software.

          In the family, well... I won't go there, as the roles in many families vary in many ways and often interchange, which is really cool. Never-the-less, the functioning families I have encountered have designated roles, and each knows what their current role is. Each role maintains the members of the family as well as the family unit itself.

        • Mission - Everyone knows the mission, their role in it, and how the basic skill sets apply, which roles are direct and which are in support. I will leave this point alone...

        The bothersome thing with all these methodologies is that they keep changing things up. What they all really boil down to (at least in my neolithic mind) are a constant re-shuffling of the basics above. That continual shuffling around undermines the basis of how I function. I need to have a clear understanding of what my role is and what the role of those around me is. I expect to be expected to understand and contribute at some level in the basic skill sets regardless of my role. I think part of the reason that this article hits the nail squarely on the head ( Joel Spolsky ) is that it becomes easy to 'game' a system when the system is in constant flux. When it comes to metrics in a changing system, about the only measurable thing is the change itself. Thus, the metrics become frustrating because the standard keeps changing, or at least the way it is talked about and understood.

        Every role needs to be based on the functional skill sets which get the job done. It may be organizational, or technical - manager or architect for example. That role is still based on applying the skill sets to the task at hand. I question whether one can do that without having a functional understanding of those functional skill sets. And that is another part of the reasons those hucksters sell what they do, the way they do... everyone wants the newest paddle for the canoe and they are so busy looking at paddles, they don't see the canoe drifting away...

        Ok. Enough... I will stop. (Past?)Time to get off my high horse... :-)

        ...the majority is always wrong, and always the last to know about it...

        Insanity: Doing the same thing over and over again and expecting different results...

        A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

        At this point, I’m mostly a “hybrid Business Analyst / Project Manager who has done a helluva lot of coding over the past 30 years.”   Which means that I have sat in that role, and I agree that it is tough.   However, the first thing that I say to a team (when it isn’t remote, as it most commonly is ...), is:   “please, sit down.”   And I take a seat next to my coffee.   The shocked looks are quickly replaced by smiles of relief.

        The next thing that I is to very briefly describe my own history, not in flowery terms, and to say, “Therefore, I know what I am doing – and, so do you.”   Raised eyebrows, smiles, “I’m from Missouri” glances.

        But this normally isn’t what team members are told:   they’re expected to be “rock stars” and tend to try to act the part ... not because they necessarily want to, but because they assume that all of the pressure, and all of the blame, rests upon their shoulders.   And, bluntly, they expect project failure.   No one ever told them (or, told the owners higher-up) that the project consists of building a software mechanism and that the work must be done in that way if it is to have any hope of success.   They are used to dealing with higher-ups who try to bribe them to do good work and to spank them if they don’t.

        I feel for – feel very badly for – the earnest folks who swallow these “methodologies” so willingly and then try to digest it.   Computer software-building is ruthlessly unforgiving of a misinformed approach, and it is much harder than it looks, for reasons that are not initially apparent.   (I guess you’ll have to buy a Kindle, but ... read that book.)

        - - - - -

        Right after graduating from undergraduate, I worked for the school and therefore had the opportunity to essentially get an MBA for free, from an excellent school.   I declined.   I knew that I knew nothing about business yet, let alone business administration, and that school wasn’t going to teach me that.   At least, not yet.   I never did go back and get one.

      After all, to be a level II SCUM master ...
      That wasn’t a typo, now was it?
Re: Selling swimsuits to a drowning man
by SuicideJunkie (Vicar) on Jul 16, 2014 at 14:41 UTC

    I think its more the slimeballs mugging the blind. And then the blind pushing the +2.00 glasses on everybody else since they've been told it will "solve all their vision problems".

    I do not see a credible value-proposition here, despite the intense sales pressure.
    Value tends to be inversely proportional to sales pressure (in addition to other factors of course).

    On another note, was that guy's career selling the course or actual development? If he has no dev skills as he implies, perhaps it is allowing him to paper over that sad fact with distracting letters.

Re: Selling swimsuits to a drowning man
by Your Mother (Archbishop) on Jul 17, 2014 at 05:05 UTC

    …sometimes it is depressing to watch the hawkers … I now ask the Monks for what is your perspective here?

    My perspective is you encountered too much of a mirror for comfort.

    Given Hawker eq Salesman and these recent musings of yours–

    Never assume that you don’t have business-value that is highly prized. The key is, as always, “selling it.”

    Craft your entire marketing message to sell the Brush, not you.

    Re: Perl Job Marketability Question - very important for me!

    Your advice, whether you will stick by it or not, is that business value is secondary to sales pitch.

    Took awhile with a properly polite sleep between requests but here are some metrics from this site I just compiled with a couple dozen lines of perl–

                     Code in posts ->  7.6%
       Links to external resources -> 15.2%
            One or t’other or both -> 21.6%
      Your Mother
                     Code in posts -> 38.4%
       Links to external resources -> 31.5%
            One or t’other or both -> 56.1%

    Eight times out of ten you post nothing but opinion. Of those eight, some are objectively, spectacularly wrong. This would not be an issue for a beginner but it is a real problem for industry veterans to be putting bad info online because the beginner cannot tell the difference and will listen to anyone who seems to have authority. I cite the recent Re: Check randomly generated numbers have not been used before. This one rankled me particularly because of several heated arguments I had at work with a dev who thought that random numbers were as secure as GUIDs for session IDs and a boss who thought that dev the smartest person in the group.

    My Golden Ticket, as you put it, was *this* place. I learned more here just trying to answer questions with code and research than I did in all my Perl books and classes combined. Please participate with that in mind and consider content before you post pure opinion editorial. Either give code to solve a problem or point to a resource that might do the same. No one loves to hear the sound of one’s own clacking away on the keyboard more than I. Please consider the growth you would undergo providing real answers and not just water-cooler BSing.

      sundialsvc4 Code in posts -> 7.6% Links to external resources -> 15.2% One or t’other or both -> 21.6%
      Excellent work! Some suggestions for more metrics:

      A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Selling swimsuits to a drowning man
by RonW (Parson) on Jul 16, 2014 at 16:39 UTC

    Sadly, "buzzword compliance" is a necessity to get through HR screening - even when you know the manager and she/he wants to hire you. I have more "golden tickets" than I care to keep track of. I just add new ones to my resume as I acquire them.

    While continuing education is a good thing, too many of these certificate programs are far more about raking in profits for the businesses selling the course materials and providing instructors than improving the actual skills of the workforce.

Re: Selling swimsuits to a drowning man
by QM (Parson) on Jul 17, 2014 at 12:08 UTC
    As a counterpoint, any management or collaboration methodology can be useful without experience in the field it is applied to. Sure, it helps to know what's going on, and perhaps have done it all yourself at one point, so you don't get bamboozled, can anticipate issues before they appear, and help find solutions. Demonstrating relevant experience helps people to trust you, because people are people, and without the obvious battle scars, why should they listen to you?

    But all of these tools are just ways to manage the chassis around the process of getting things done. If Foo depends on Bar, and Bar isn't working, then fixing Foo is pointless. It doesn't matter if Bar is a rocket engine or a CAT-5 cable or a wedge-shaped doorstop.

    So at these networking events, you'll find people trying to make a living draping themselves in the latest JAFAs. You have to decide if the JAFAs for sale have any substance, and if the delivery mechanism is up to the task. If they're just selling the alphabet soup, of course, then you're only getting soup.

    Quantum Mechanics: The dreams stuff is made of

Re: Selling swimsuits to a drowning man
by mr_mischief (Monsignor) on Jul 17, 2014 at 15:16 UTC

    A scrum team has both a Scrum Master and a Product Owner besides the developers. The Scrum Master is about preserving the process, keeping the developers from being overworked, and eliminating problems in the organization or facilities that prevent productive work. The Product Owner's role is to communicate what the customers want to the developers, to determine when something does or doesn't meet the standards for delivery to the customers, and to clarify things like specs, feature lists, and possible completion dates between the team and the customers.

    The Scrum Master is the team's good cop in case the Product Owner asks for too much from the team for too long. They improve the process, improve the working environment, and provide another person to push back against unreasonable demands. The Product Owner is the not bad but potentially overzealous one who wants the team to deliver a lot of business value to the customer every sprint.

    The developers -- which often includes the programmers, QA, and documentation folks -- size the user stories and decide how many they are willing to accept in a sprint. They lean on the PO to get better specs. They lean on the SM to get meetings scheduled, get resources, and for advice about the Scrum process itself. It's very much about splitting the "we need to deliver a lot" and the "we need to observe sane work/life balance and prevent burnout in our employees" roles of a single Project Manager or Sub-project Manager so there's not too much sway one direction or the other.

    A large overall project might have a Project Manager to whom the POs and the teams answer. Alternatively it may work as a scrum of scrums in which there's a head Product Owner and the other Product Owners deliver to that person while the Scrum Masters push impediments up to a head Scrum Master to get bigger or broader-reaching impediments fixed.

    It's easy to dismiss something as snake oil without actually understanding it. At my employer everyone who works as a scrum team member gets certified as a Scrum Master to understand the process better. Then they do their own jobs while a Scrum Master who isn't necessarily as skilled in the technical parts of the job fills the role of keeping the process on track and serving the team's impediment removal needs. It isn't perfect but it can, for the right organization where it is a good fit, work very well. It's kind of like what Churchill said about democracy... Scrum is the worst form of project management framework except all the others that have been tried.

      At my employer everyone who works as a scrum team member gets certified as a Scrum Master to understand the process better

      Just curious, does your company similarly send folks to certification courses in other domains too? For example, are your programmers sent on Perl certification courses? Java certification courses? I'm often astonished by the willingness of companies to shell out big bucks on Scrum training, while skimping elsewhere. I mean, the modern developer has to master many different skills from many different domains, and Scrum is one of the easier ones to master without attending a formal training course IMHO. Perhaps folks push hard for Scrum Master Certification so as to "add value" to their CVs?

      As you might have guessed, I'm not a fan of certifications in general, agreeing with merlyn:

      I will be discouraging individuals from taking such courses, and HR people and clueless managers from looking for such certifications, particularly demanding them to be considered for an application. I will continue to work hard with my clients and my fellow contractors to have actual track records be considered, not some test one has managed to pass and pay for.

      -- Perl Certification -- still Snake Oil by merlyn

      Scrum makes it worse by ignoring important (but hard) agile engineering practices, and the Scrum Alliance makes it worse still with their armies of trainers--some good, some not--issuing dubious "ScrumMaster" certificates to people who demonstrated competence in connecting butt to chair for two days.

      -- The Decline and Fall of Agile by James Shore

        The company actually doesn't care about the certification, at least not for developers, tech writers, and QA analysts. They care about the concepts and terminology getting disseminated to everyone involved. The certification test is free with the class, so one may as well take it.

        I'm not aware of any meaningful certification for Perl. We do have trainers come in for Perl, though. I'm sure merlyn would approve of brian_d_foy being in the building for example. He is right now as a matter of fact.

        As far as I know we have a few infrastructure things that run on JVMs but our products and our infrastructure neither one involve any in-house Java. I've read through some Clojure to get a better idea of what some third-party tools are doing but we don't write it here. We do some Ruby on my team and some C lurks in some corners in various parts of the company. I'd actually love to get a good Ruby trainer in here for a few days.

      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.

        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.

        A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Selling swimsuits to a drowning man
by DrHyde (Prior) on Jul 21, 2014 at 15:13 UTC
    So, is “the blind leading the blind” an accepted business-practice these days? Even though the person who runs the shop where I get my car serviced might not be holding an grease-gun when he introduces himself to me, I do want to know that he has held one in the fairly recent past.

    I'd prefer that the guy who runs the place was good at scheduling, critical path analysis, and negotiating good prices with his suppliers. He can employ people to do greasy things, including foremen to provide him with the information he needs on what the greasy people do.

    In other words I want the person managing the place to be a good manager. A garage with a good manager is more likely to get the job done quickly and to not keep me hanging around for my appointment. And in fact the place I use to get my truck serviced is exactly like that. It's not the cheapest, but it's higher quality than the cheapest, which usually makes things cheaper in the long run.

      ++ A lot of good devs make atrocious managers.

Re: Selling swimsuits to a drowning man
by bulrush (Scribe) on Jul 17, 2014 at 12:29 UTC
    So, is “the blind leading the blind” an accepted business-practice these days?

    I'm a management minor. It's just typical management BS. "If you can't fascinate them with facts, baffle them with bullshit." This is more common in larger companies, especially Fortune 500 companies. I'm lucky that I have a manager that actually understands programming a bit, or at least takes my advice about strategic directions.

    Perl 5.8.8 on Redhat Linux RHEL 5.5.56 (64-bit)

      If software were something that you could see, like a building, or especially if it (being a machine ...) could be seen “whirling dangerously with a thousand-and-one rapidly moving parts,” then our approach to constructing it would be altogether changed.

        "If software were something that you could see"

        s/you/non-programmers, most managers, etc./

        check Ln42!