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

59A Tool or a Methodology

Expand Messages
  • Ken Schwaber
    Nov 25, 2000
    • 0 Attachment
      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
    • Show all 4 messages in this topic