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

RE: [scrumdevelopment] Re: mention of Scrum in "Software Development"

Expand Messages
  • Mike Beedle
    Mark: You probably missed it, but we have already *openly* admitted, several times, for the lack of good documentation of the Scrum engineering practices. Most
    Message 1 of 40 , Nov 12, 2003
      You probably missed it, but we have already *openly* admitted, several times, for the lack of
      good documentation of the Scrum engineering practices.
      Most of the information on these practices was found on web sites and some OOPSLA papers,
      I'll give you examples of Scrum engineering practices:
          Partitioning by vertical and horizontal packages
          Daily Build
          Continuous Integration (constant checkins, integration, constant testing, etc.)
          Requirements Practices (Meetings, some have used Use Cases and CRC cards over the years, etc.)
          Regression Testing (script, or scriptless functional testing)
          Spot Testing (informal daily testing)
      These were practices that have been in Scrum sites since at least 1996, both at Jeff Sutherland old
      I have used in practice since then,
      - Mike

      -----Original Message-----
      From: woynam [mailto:woyna@...]
      Sent: Wednesday, November 12, 2003 1:54 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: mention of Scrum in "Software Development"


      Can you please provide the references that detail the full
      software development methodology behind Scrum? I've studied
      and used Scrum for years, (including reading the book :-), and
      I have to agree with Scott. I don't see much in the way of
      engineering practices, other than letting the team do their

      Having tailored and used RUP in a lightweight fashion, I don't
      see Scrum addressing many of the artifacts and workflows
      necessary to get from requirements to tested software, whether
      formal or informal. If you have a group of experienced engineers,
      this isn't necessarily that big of a deal. However, junior staff
      don't automatically know how to transition through the various
      stages. RUP's various templates, guidelines, etc. provide some
      form of a roadmap. Of course, if used without tailoring, RUP
      can certainly be labeled as anti-agile.


      --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
      <ken.schwaber@v...> wrote:
      > I send an email to Scott that he seemed to be unaware that Scrum
      a full
      > methodology and perhaps is unaware of it entirely other
      > Perhaps nobody should be allowed to write about
      Scrum that isn't a CSM?
      > Ken
      >   -----Original
      >   From: Mike Cohn
      >   Sent: Sunday, November 09, 2003 8:42
      >   To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] mention of Scrum in "Software Development"
      >   The new "Software Development" magazine came a
      couple of days ago. As
      > always, Scott Ambler has an interesting column. I
      often agree with his
      > points but I don't this time and since Scrum is
      mentioned in the
      article I
      > want to pass along the reference.
      >   The article is about using "the right
      tool for the job" and its teaser
      > says that "When it comes to
      methodologies, one size doesn't fit all. By
      > examining all the options,
      you can create a mix-and-match approach
      that best
      > suits your
      >   The part of the article
      that I think is subject to debate is a
      figure he
      > shows. The figure
      has a vertical axis with "full lifecycle" at the
      top and
      > "partial
      methodology" at the bottom. He puts Scrum near the bottom
      on this
      axis saying that "Scrum [focuses] only on one aspect of software
      development, .project management." At similar levels on this scale
      are Code
      > and fix, test-driven development, his own Agile Modeling and Agile
      >   The horizontal axis goes
      from Ad Hoc on the left to Prescriptive
      on the
      > right. Scrum is shown
      slightly to the Prescriptive side of the
      middle. At
      > similar levels on
      that scale are DSDM, FDD, and Agile Data.
      >   Scrum is defined in a sidebar to the article as "a partial
      > methodology" and says that to use it "Tailor Scrum into agile
      > development methods." What's odd is that other
      processes that seem
      far less
      > agile to me (e.g, FDD) are listed as
      agile while Scrum is "partial
      > Similarly, XP is listed as more
      ad hoc than Scrum. That's a hard
      one-in some
      > ways (good ones) XP is
      fairly prescriptive and there was a lot of
      early talk
      > in XP circles
      that if you weren't doing all 12 practices you weren't
      >   If I had to place Scrum on a
      scale between Ad Hoc and Prescriptive
      I'd put
      > it pretty far to the Ad
      Hoc side.
      >   Placing it between
      Partial Methodology and Full Lifecycle is
      harder. Yes,
      > it's partial
      because it doesn't define how everything happens but it
      > fairly
      full lifecycle in that the path to a potentially shippable
      increment is defined. There's nothing in Scrum about how to end a
      project or
      > about how to handle a project in its earliest, pre-funding
      > phases but some of that is what Ken's been adding in
      the CSM
      classes. Still,
      > I'd say it seems more toward the Full
      Lifecycle end of things than the
      > Partial Methodology end of
      >   Anyone else have any
      thoughts about Scott's article and placement of
      > Scrum?
      >   In any event, the article is quite good. The print
      issue is out
      now and
      > they seem to put the articles online at
      www.sdmagazine.com a few weeks
      > afterwards. (As a bonus, this issue has
      another great article-Bob Martin
      > showing how tracking velocity and
      product burndown help manage a
      >   --Mike

      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Jeff Sutherland
      While I agree with Mike in general, it is of interest that the first Scrum was building an OOAD tool and we decided the team should eat their own dogfood. It
      Message 40 of 40 , Nov 14, 2003
        While I agree with Mike in general, it is of interest that the first Scrum
        was building an OOAD tool and we decided the team should eat their own
        dogfood. It was also the first round trip engineering tool.

        Every developer had the model of his components on his wall.

        Our senior consultant, Jeff McKenna, an ace Smalltalker, would walk into a
        cube and an hour later the model was in shreds on the floor. He had shown
        the developer how to refactor the model and eliminate half the code while
        enhancing performance and functionality.

        I've never seen another team that can operate at that level.


        At 05:07 AM 11/14/2003, Mike Beedle wrote:
        >Mark wrote:
        > > Mike has said repeatedly that he feels that
        > > modeling isn't necessary in order to produce quality code. Scott
        > > Ambler, myself, and some within the XP community have the opinion that
        > > modeling, when necessary, and to the proper level of detail and
        > > formality, provides an important element in the design and
        > > implementation of software.
        >This is also a fact:
        > We produce hyper-productive, high-octane, high-quality,
        > high-quantity software with little or no models.
        >So no, models are not important to us, as they are not as
        >important to most agile developers. (We minimize "documentation time"
        >by documenting after the fact.)
        >But like I said earlier, if you feel modeling helps your team, or
        >is needed for political reasons, or you like how the models look on
        >display on the walls, hey, more power to you.
        >Good luck with all of your projects!!!!
        >- Mike
        >(It was nice to talk to you on the phone earlier this evening, btw.)
        >Mark wrote:
        > > P.S. I'm looking forward to taking the CSM course some time in the
        > > near future. Perhaps I'll walk away cured of my modeling sickness. :-)
        >In 1994-1996 I was involved in a 100+ person, 30 million dollar
        >software development project. By year 2 we had 1000+ pages of:
        > Elaborated Use Cases
        > Class Package Diagrams
        > Class Diagrams
        > Sequence Diagrams
        > Test Plans
        >but no working software. Within the last 4 months of the project
        >I took over the project, *ignored all the previous models*,
        >applied Scrum to the project and delivered the first instance
        >of the application to production on 1/1/1996.
        >(I have many other, almost countless experiences like that.)
        >This is why I don't do models anymore -- they NEVER delivered the
        >goods for me in the trenches.
      Your message has been successfully submitted and would be delivered to recipients shortly.