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

RE: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc

Expand Messages
  • Mike Cohn
    Deb-- Good points. I think it s OK for an agile process to recommend specific practices. The perfect example is the type of things Scott Ambler recommends with
    Message 1 of 37 , Jun 4, 2003
      Good points.

      I think it's OK for an agile process to recommend specific practices. The
      perfect example is the type of things Scott Ambler recommends with "Agile
      Modeling." When I introduce Scrum into an organization I usually leave them
      with some Word document templates for various things--they're very
      lightweight and the recommendation is always "avoid these unless you need
      them but if you need them here's a start."

      I think your idea for an Agile Alliance program to contribute to SWEBOK is
      great. We don't have long though as they want reviewer feedback by 6/30.
      There's a form on the Alliance page if you want to start it as a program. If
      you do, count me in as a contributor. I printed the SWEBOK and signed up as
      a reviewer and plan to start reading it this weekend. An Agile Alliance
      group that contributed unified feedback and possibly offered to contribute a
      few pages (that's all we need) would be useful. It's criminal to not even
      mention XP, Scrum or agile at all in a "body of knowledge."


      -----Original Message-----
      From: Deb [mailto:deborah@...]
      Sent: Wednesday, June 04, 2003 10:43 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They
      Don't Even Mention XP, Agile, etc

      I looked up SWEBOK, and at http://www.swebok.org/, under "Project
      Overview" I found information that seems to make room for Scrum...
      under "Advanced and Research". I know, it's been around a long time
      now... but "they" don't know that, right?

      I'd think the existence of the Agile Alliance lends it credence (for
      those who require such). Would it be beneficial to make contribution
      to SWEBOK an Agile Alliance program?

      Some additional reflections:
      I'd think that the Scrum entry in SWEBOK would be a relatively short
      one, because it's based on values and principles, with very few
      prescribed practises. Wouldn't this be typical of Agile methodologies
      in general - to remain Agile, we must remain open to whatever
      practises fulfill the values and principles most economically? Also,
      we must remain open to incorporate practises required by a given
      organisation, as long as they don't conflict with the values and
      principles. Please, someone correct me if I've oversimplified this.

      Side note:
      On the page noted above, I found this on PMI:
      "The Guide to the Project Management Body of Knowledge is now an IEEE

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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Mike Beedle
      ... From: Fabian Ritzmann [mailto:usefri@gmx.net] ... Oh, I don t know -- we are still sort of on topic. ... We call tests by the user acceptance tests or
      Message 37 of 37 , Jun 6, 2003
        -----Original Message-----
        From: Fabian Ritzmann [mailto:usefri@...]
        > Need to bring this back on topic for this list. :-)

        Oh, I don't know -- we are still sort of on topic.

        > --- Fabian Ritzmann <usefri@...> wrote:
        > XP as I understand it uses unit tests and system
        > tests, unit tests for unit testing and system tests for
        > whatever the users want to test, including quality
        > aspects like performance, reliability, etc.

        We call tests by the user "acceptance tests" or ATs.

        I think this is a valid definition across XP and
        Scrum but I don't know if other agile methods call
        them the same way.

        self wrote:
        > The combination is very powerful:
        > * test as _specification_ from Test-First, and
        > * program as executable _specification_ from
        > functional programming
        > Both strategies drive development more into the
        > quantifiable _what_ space, much more than worthless
        > "exhaustive requirements documents" or "models".
        > Perhaps, this is what we need to concentrate in
        > software architecture -- in patterns that tell us
        > _what_ to program and that are executable,

        Fabian wrote:
        >The principle problem is that provable (and executable)
        >specifications don't help if the specification is wrong.
        >And we all know that specifications always change,
        >that's why we do Scrum or another Agile development
        >method. Of course that shouldn't keep anybody from
        >improving the way we are programming these days.

        True. In our view, the need for acceptance tests
        conducted through people-2-people interaction
        never goes away for the exact reasons you list
        (and regardless the programming styles used):

        - making sure that the specification is not wrong
        - making sure that we keep up with changes
        for the specification
        - making sure that the user experience is
        comfortable i.e. timely, convenient, beautiful, etc.

        It is just easier, faster and even more economical
        in some paradigms of programming to do the above
        3 things,

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