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

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

Expand Messages
  • Mike Beedle
    ... Mark: Many of the people that first did Scrum were also Smalltalkers, Jeff included, and many other people at EASEL. (In 1989, I was one of the architects
    Message 1 of 40 , Nov 14, 2003
    • 0 Attachment
      Mark wrote:
      > Also, since Scrum doesn't provide any much in the way of engineering
      > practices, you steer people towards more "complete" methodologies,
      > such as XP, who's basis itself is a number of best practices that
      > existed prior to the adoption of the name XP. (I was doing continuous
      > integration, test driven design, and pair programming in Smalltalk
      > prior to XP, which is no big surprise, since these practices were part

      > of the Smalltalk culture for some time.)


      Mark:

      Many of the people that first did Scrum were also Smalltalkers,
      Jeff included, and many other people at EASEL.

      (In 1989, I was one of the architects of the OfficeVision project in
      "West Lake", Texas. Within this project and other projects
      at IBM we developed a number of OO 4GLs, as they were called back
      then. Most of these 4GLs were developed by SmallTalkers at IBM.
      EASEL was one of them and was externalized and made into a
      startup by a VP at IBM. We later supported EASEL applications from
      1989-1993 through the SAA Express program under the banner
      "cooperative processing", which later because client-server programming.

      I led EASEL and Smalltalk projects at American Airlines, Sprint, MCI,
      and a many other outfits within that timeframe.)

      Do you see where Scrum gets some of its *basic* practices now?

      Deep down mostly from Smalltalk !!! (As XP does, as you mentioned,
      btw.)
      See: http://c2.com/cgi-bin/wiki?XpRoots


      (Also, Jim Coplien documented many of the organizational patterns of
      the Quattro team, that inspired the Daily Scrum meetings. Unfortunately,

      he missed them as *patterns*, we later captured
      them as the "Scrum patterns", but nevertheless, he did capture a
      number of important patterns that are Scrum-friendly
      because one of Jeff's goals in 1993 was to emulate the Quattro team.
      See:
      http://www.bell-labs.com/user/cope/Patterns/Process/QPW/borland.html
      http://www.agilealliance.org/articles/articles/PatternsOfProductiveSoftw
      areOrganizations.pdf
      http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?CoplienOrganiz
      ationPatterns
      http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?BookOutline
      )


      Mark wrote:
      > Getting back to the original theme of this thread, I believe that's
      > exactly what Scott Ambler was pointing out: Scrum as it stands by
      > itself requires the engineering practices of other methodologies.

      I am sorry, I don't follow this is a "logical" conclusion.

      Scrum *needs* practices from other methodologies? No. Scrum as
      a software development method has had a basic bag of
      "engineering" practices. (This is different from Ken's
      Scrum Product, btw.)

      You can you replace them, complement them, extend them,
      or customize them, but the fact is they are *required* for Scrum
      to work as a software development method.

      Try doing Scrum without continuous integration, regression
      testing, Daily Builds/(customer reviews), Product Backlog
      definition (requirements), Sprint Backlog definition (detailed
      requirements),
      spontaneous pairing .... and with enough of these things missing
      your project will eventually flop!!


      Mark wrote:
      > Hopefully Mike and you can write a second edition of the Scrum book,
      > and "formally" incorporate these best practices into the methodology.
      > :-)

      A second edition of the current Scrum book would still be focused
      on "Scrum as a project management technique".

      I think another book focused more into software development
      would be nice.


      Mark wrote:
      >I have a distinct feeling that Mike and you feel I'm some how slamming
      >Scrum, or trying to pick a fight, because I believe that there's room
      >for more than one set of engineering practices within the Scrum
      >umbrella.

      There *is* room for more than one set of engineering practices.

      I agree with that.

      You can substitute, extend, complement, and/or customize practices.

      But you have to realize Scrum from its inception did recommend:
      regression testing, configuration management, continuous integration,
      Daily Builds (daily builds for customer review), sharing knowledge
      and cooperation among developers, etc.

      That is a fact.


      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.
    • 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
      • 0 Attachment
        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.

        Jeff

        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.