Loading ...
Sorry, an error occurred while loading the content.

Avoiding extremes of being prescriptive and figuring everything out on our own

Expand Messages
  • Peter Alfvin
    ... One of the things that always bothered me about the Scrum literature (not the process per se) was its constant derision of defined process (the quotes
    Message 1 of 121 , Feb 8, 2009
      --- In leanagile@yahoogroups.com, "Alan Shalloway" <alshall@...> wrote:

      > We need to avoid the extremes of being prescriptive or figuring
      > everything out on our own.

      One of the things that always bothered me about the Scrum literature
      (not the process per se) was its constant derision of "defined
      process" (the quotes are important) in favor of "empirical process".

      I was interpreting "defined process" in what I consider to be the
      traditional software engineering sense, namely a process that has
      associated documentation such as policy and guidelines, is subject to
      some form of process quality assurance, is improved over time, etc.
      Those are good things in my view, at least in concept, and even Scrum
      itself (the process) incorporates them in its own definition (well, at
      least everything but continuous improvement ;-))! See
      for the CMMI definition in particular.

      I finally remembered a while ago that Ken was using the term "defined
      process" in the sense of industrial process control, where it refers
      to a process that is fully understood and controlled such that the
      same set of inputs will be produce the same outputs. The difference
      is huge, because while knowledge acquisition activities like software
      development or problem solving cannot be described or managed as
      "defined process" in the industrial process control, they very much
      can be defined in the traditional software engineering sense.

      Unfortunately, I think this overloading of the term has contributed to
      a false dichotomy in the minds of many agilists. Since software
      engineering processes are obviously empirical in nature, then we
      should never attempt to define our processes, never leverage the
      defined processes of others and the Lean notion of "standard work"
      must not apply, right?

      As I've said many times, I think Scrum is a great example of a good
      "defined process". It has solid documentation, crisply describing
      both policy and practice, it provides for quality assurance (i.e. the
      ScrumMaster role), it permits customization in a structured way (i.e.
      the initial paragraph in the rules) and the definition is subject to
      change control. In fact, I would say that, ironically, it's these
      elements as much as anything that have led to its widespread adoption.
      The XP literature also provides many good examples of effective, lean
      and agile "defined processes" (in the traditional software engineering

      Getting back to your original words, Alan, I think "prescriptive" is
      not necessarily bad. To use our favorite analogy, I think it's
      generally a good thing that patients turn to doctors to get
      "prescriptions" for both precisely defined things like medications and
      imprecisely defined things like "physical therapy" rather than trying
      to develop these on their own. This does not take away from our
      responsibility to improve our overall health through nutrition,
      exercise, stress management and ultimately deciding which
      doctors/prescriptions we will rely upon. And some of us might even go
      into medical research and develop new drugs or therapies.

      This is all part of the agile phenomenon of throwing the baby out with
      the bathwater, from my perspective. Because of the large number of
      ineffective managers, the large number of ineffective defined
      processes, the large amount of poorly written documentation and the
      dearth of effective quality assurance functions, the agile movement
      tends to deprecate managers, defined processes, documentation and
      quality assurance functions. It's understandable and excusable in the
      sense of a pendulum swing; it's not as an underpinning of a profession.

    • Mary P
      I think we agree on this much more than was apparent, Brad. People that are impacted should be involved or consulted. Absolutely. I think I showed my strong
      Message 121 of 121 , Feb 15, 2009

        I think we agree on this much more than was apparent, Brad.  People that are impacted should be involved or consulted. Absolutely.


        I think I showed my strong bias against “rules.”  The company I spend most of my time in had a very ad-hoc approach to getting things done. McKnight – who set the culture at 3M – had this saying : “Get it done, and QUICK!” and then there was the “Ask forgiveness, not permission.” and “Take an idea and run with it.” and so on. The whole system was set up to make it very easy and cheap to get a new product commercialized. In fact, new products were considered experiments. The process was effective.  It produced high quality. And there were amazingly few rules. But not so many companies do things that way. I know your company has a very different culture that you have to work within. 


        Mary Poppendieck



        Author of: Lean Software Development & Implementing Lean Software Development


        From: leanagile@yahoogroups.com [mailto:leanagile@yahoogroups.com] On Behalf Of Brad Appleton
        Sent: Sunday, February 15, 2009 10:34 AM
        To: brad@...
        Cc: leanagile@yahoogroups.com
        Subject: Re: [leanagile] Re: Controlling Say (was Definition and Scope of Scrum / PO Role)


        I think I may have misused the term "stakeholder" in my earlier
        response. Rather than meaning everyone impacted by (i.e. "with a stake
        in") the process, what I really meant was representatives from each
        group that executes all or part of it (i.e. they "touch it" somehow in
        the value-stream map, and hence their time/effort spent would be part of
        the overal "touch-time" or "takt-time")

        Sorry about the confusion.

        I agree that for really complex processes, it may not be feasible to
        have every group in the room. Obviously all the "major players" need to
        be there. I was attempting to critique the approach where a single
        "master architect" talks to each group individually, and then proceeds
        directly to try and put all the pieces together himself (without direct
        dialogue and learning discussion with all/most of the other groups

        Brad Appleton wrote:

        > Mary P wrote:
        >> You can't get everyone in the room to fix a complex process
        > I'm sorry - this seems to be the opposite of what youve been preaching
        > when you talk about making value-stream maps.
        > Are you equating getting all stakeholder viewpoints represented in the
        > room with getting every single individual in the room?

        Brad Appleton <brad {AT} bradapp.net>
        Agile CM Environments (http://blog.bradapp.net/)
        & Software CM Patterns (www.scmpatterns.com)
        "And miles to go before I sleep" -- Robert Frost

      Your message has been successfully submitted and would be delivered to recipients shortly.