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

Re: [scrumdevelopment] A Tool or a Methodology

Expand Messages
  • Ward Cunningham
    ... Call it a method if methodology sounds too pompous. The light weight stuff holds up well against the rest which is why there is so much interest at the
    Message 1 of 4 , Nov 25, 2000
    • 0 Attachment
      Ken Schwaber wrote:

      > I've been invited to a session on "light methodologies"
      > or "minimalMethodologies". This caused me to rethink about whether
      > Scrum is a methodology.

      Call it a method if methodology sounds too pompous. The light weight stuff holds up
      well against the rest which is why there is so much interest at the moment.

      "A methodology is a method that's been to college" -- saying from IC-CAD's
      formative years.


      --
      Ward Cunningham
      v 503-245-5633 mailto:ward@...
      f 503-246-5587 http://c2.com/
    • Krotowski, Randy (RKRO)
      I suggest that Scrum is a methodology which I define as a set of principles and processes, in this case with a heavy emphasis on the principles. I believe
      Message 2 of 4 , Nov 27, 2000
      • 0 Attachment
        I suggest that Scrum is a methodology which I define as a set of principles
        and processes, in this case with a heavy emphasis on the principles. I
        believe Method/One and other (massive) methodologies focus more heavily on
        the cookbook approach because they have been augmented over the years with
        additional detail, tools and templates. My copy of a Method/One binder for
        a project 3 years ago is 600 pages with 240 deliverables and innumerable
        process steps. But, if you want several thousand people to use the same
        methodology the same way, maybe this is what you need.

        But Method/One and other massive methodologies are totally inappropriate in
        situations where there is either high uncertainty or low agreement. Where
        this is a case, a process where you "manage to a vision", using empirical
        project management approaches and a hands-on style is more appropriate.
        Ralph Stacey proposed a certainty matrix to select the appropriate
        management process for a complex environment based on level of uncertainty
        and level of agreement
        (http://www.vha.com/edgeplace/think/main_aides3.html). Interpreting this
        matrix in a project management/ application development context points to
        the use of traditional waterfall, cookbook methodologies where there is a
        high level of certainty and agreement -- we know want we want to do and we
        know how to do it so the best approach is to plan the work and work the
        plan. In an environment of greater uncertainty, a process based on
        iterative or evolutionary delivery focused on a vision that is refined
        during development (e.g. SCRUM) is more appropriate as an approach that will
        reduce the uncertainty and deliver the best possible outcome. Where there
        is certainty but no agreement, prototyping and a good dose of organizational
        politics is probably the right answer.

        So yes, in my view Scrum is a methodology and an excellent one in the right
        situation.

        Also, if anyone else has been looking at the application of complexity
        theory to application development or project management I would be
        interested in hearing from them.

        -----Original Message-----
        From: Ken Schwaber [mailto:kschwaber@...]
        Sent: Saturday, November 25, 2000 11:07 AM
        To: scrumdevelopment@egroups.com
        Subject: [scrumdevelopment] A Tool or a Methodology


        I've been invited to a session on "light methodologies"
        or "minimalMethodologies". This caused me to rethink about whether
        Scrum is a methodology.

        My experience with Summit, Method/One, SDM, UML, and other
        methodologies are that they are cookbooks. You follow the cookbook
        and you are following good engineering practices, and you will, as a
        matter or course, get a good product.

        One argument about methodologies is their degree of specificity. For
        instance, a methodology is usually tool neutral. A methodology also
        usually presumes the presence of a development and computing
        infrastructure.

        My experience is that the influx of new technologies and techniques
        makes most methodologies irrelevant. Since they are so neutral,they
        contain nothing of relevance. The new stuff that causes products to
        be competitive is still experiential, or - at most - published.

        I am in the middle of using Scrum at an ASP ... a recently reapplied
        concept (like time-sharing) where the product vendor not only
        provides the application but the whole computing infrastructure.
        There were so many unknowns that Scrum worked great ... but not as a
        methodology, but as a tool with which to organize, prioritize, and
        get work done.

        The ASP is a startup company, which only had sales and product
        development doing everything. But when the orders started pouring
        in, they needed quality control, customer support, systems
        engineering, and implementation services. Based on what we were
        discovering, the backlog changed almost every week.

        For instance, to test a product, you need a stable build. To have a
        stable build, you have to have a coordinated code checkin/checkout
        and unit testing process. For the unit testing to make sense, the
        teams had to have a high degree of coherence, with low coupling to
        other teams. This got sorted out, day by day, in daily Scrums. In
        the daily Scrums, we identified the new work, set up Scrums to handle
        the new requirement ("oh!! We need a customer support function,
        otherwise we'll never get to the work on this release because we're
        too busy working with customers on enhancements!!"). This chaos,
        driven by marketing and venture capital dates, was continually
        organized and reorganized by Scrum.

        So, we used Scrum as a tool to get work done. Does that make it a
        minimalMethodology? Or are we into something different here?
        Ken



        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
      • Grant Heck
        ... From: Ken Schwaber To: Sent: Saturday, November 25, 2000 2:06 PM Subject: [scrumdevelopment] A
        Message 3 of 4 , Nov 28, 2000
        • 0 Attachment
          ----- Original Message -----
          From: "Ken Schwaber" <kschwaber@...>
          To: <scrumdevelopment@egroups.com>
          Sent: Saturday, November 25, 2000 2:06 PM
          Subject: [scrumdevelopment] A Tool or a Methodology


          > I've been invited to a session on "light methodologies"
          > or "minimalMethodologies". This caused me to rethink about whether
          > Scrum is a methodology.
          >
          Ken

          I believe Scrum is at least a methodology. As Yourdon points out about
          Hawrysh and Ruprecht's article "Methodologies, whatever there name and
          origin, have some universal components: task lists, techniques, tools, and
          management approaches".

          We know that Scrum has task lists, techniques, etc. Could it be that you
          know them so well that they are second nature to you now and you are not
          conscious of employing them?

          It also has some additional characteristics. One of Scrum's strong points
          is its ability to force a prioritization onto the work ahead, the backlog.
          This covers both process and project management. (In my view, process
          management specifies or determines what and in what order work is to be done
          and project management determines when, by whom and at a different level,
          the work priority.) It seems to me that process and project management
          intersect at the act of prioritization of the backlog, because they both
          deal with enforcement of certain principles (what, in what order, who, when)
          as well as risk mitigation. It is at this intersection where Scrum excels,
          indeed it exploits the intersection.

          So, I think Scrum is a methodology that also reaches into project
          management. So is it a process/project management tool? Is it a light
          methodology or a methodology plus? Framework and environment are too
          general, sounds like we need a new term.

          Grant Heck

          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...
          >
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.