in reply to Selling swimsuits to a drowning man

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.

  • Comment on Re: Selling swimsuits to a drowning man

Replies are listed 'Best First'.
Re^2: Selling swimsuits to a drowning man
by eyepopslikeamosquito (Archbishop) on Jul 23, 2014 at 09:37 UTC

    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

[reply]

      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.

[reply]
Re^2: Selling swimsuits to a drowning man
by locked_user sundialsvc4 (Abbot) on Jul 17, 2014 at 18:23 UTC

    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.

[reply]
      A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations