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

Paper discussing Scrum...

Expand Messages
  • Steve Bannerman
    All, I introduced myself a while back as a newbie to Scrum and particularly interested in requirements management as it relates to Scrum. Thanks to those
    Message 1 of 4 , Aug 26, 2003
    • 0 Attachment
      All,

      I introduced myself a while back as a "newbie" to Scrum and particularly
      interested in "requirements management" as it relates to Scrum. Thanks to
      those who have helped me (start to) understand how requirements management
      is "done in Scrum." Also, thanks to Ken and Mike for the book on Scrum...I
      had our library buy it and I've found it easy to read and very sensible
      given my own 12 years in industry (prior to my current "sabbatical" in this
      "ivory tower"). I'm particularly glad to see a justification for the
      "empirical" method that we usually "degenerate" to anyway.

      I've just recently submitted a paper to a journal discussing an
      "alternative" requirements management "architecture." In the paper, I
      suggest how the architecture "could" be used to benefit agile teams, XP and
      Scrum in particular. Would anybody be interested in discussing my
      suggestions here? If so, I'd be glad to try to distill some "discussion
      points" from the paper [1], which is double spaced and ~35 pages long :-(

      Let me know what you think.

      Cheers

      [1] http://reqs.comlab.ox.ac.uk:8080/reqs/pdfs/rmadp.pdf
      --
      Steve Bannerman
      steve.bannerman@...
      44.(0)1865.273866
    • Mike Cohn
      Steve-- I plan on reading your paper and will post my comments back to this group. I ll try to get to it asap but I m buried right now. --Mike ... From: Steve
      Message 2 of 4 , Aug 26, 2003
      • 0 Attachment
        Steve--
        I plan on reading your paper and will post my comments back to this group.
        I'll try to get to it asap but I'm buried right now.

        --Mike

        -----Original Message-----
        From: Steve Bannerman [mailto:steve.bannerman@...]
        Sent: Tuesday, August 26, 2003 5:05 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Paper discussing Scrum...

        All,

        I introduced myself a while back as a "newbie" to Scrum and particularly
        interested in "requirements management" as it relates to Scrum. Thanks to
        those who have helped me (start to) understand how requirements management
        is "done in Scrum." Also, thanks to Ken and Mike for the book on Scrum...I
        had our library buy it and I've found it easy to read and very sensible
        given my own 12 years in industry (prior to my current "sabbatical" in this
        "ivory tower"). I'm particularly glad to see a justification for the
        "empirical" method that we usually "degenerate" to anyway.

        I've just recently submitted a paper to a journal discussing an
        "alternative" requirements management "architecture." In the paper, I
        suggest how the architecture "could" be used to benefit agile teams, XP and
        Scrum in particular. Would anybody be interested in discussing my
        suggestions here? If so, I'd be glad to try to distill some "discussion
        points" from the paper [1], which is double spaced and ~35 pages long :-(

        Let me know what you think.

        Cheers

        [1] http://reqs.comlab.ox.ac.uk:8080/reqs/pdfs/rmadp.pdf
        --
        Steve Bannerman
        steve.bannerman@...
        44.(0)1865.273866



        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 http://docs.yahoo.com/info/terms/
      • ashinw
        Hi Steve, You certainly cover a lot of mileage in this paper! ... I have the following feedback based on having walked a similar path 4 years ago: With
        Message 3 of 4 , Aug 27, 2003
        • 0 Attachment
          Hi Steve,

          You certainly cover a lot of mileage in this paper!

          --- In scrumdevelopment@yahoogroups.com, "Steve Bannerman"
          <steve.bannerman@c...> wrote:
          > I've just recently submitted a paper to a journal discussing ...
          > Let me know what you think.
          >

          I have the following feedback based on having walked a similar path 4
          years ago:

          <snip>
          With that definition, we categorize existing architectures as:
          (1) "heavyweight" – specific software tools that store and share
          requirements with a database (DOORS [44] and RequisitePro [35]);
          (2) "lightweight" - general software tools that store and share
          requirements with files (Word, Excel, and Wikis); and (3) "ultra-
          lightweight" – non-software mechanisms that use pen and paper for
          storing and sharing requirements.
          </snip>

          I would not link "weight" to the persistence medium itself. Instead,
          I would associate travel weight to asset management as changes
          occurs. I think Ambler says it best (see Travel light from
          http://www.agilemodeling.com/principles.htm)


          > [Heavyweight strengths] It embodies requirements at the correct
          level of granularity

          Some tools may indeed force/incline requirement abstractions
          to /persist/ at a course/fine level of granularity.

          Perhaps a better characteristic to identify is "It enables the units
          of configuration management to be user defined". In this manner, a
          team is given the flexibility as to whether a package of requirements
          or even a business rule can be an item in configuration management.


          > [Heavyweight strengths] It gives developers a lot of flexibility in
          embodying requirements

          Heavyweight tools are typically bound to a meta-model. Most meta-
          model::ModelingElements are associated to Properties. Properties
          provide the flex point. Lightweight tools are typically use
          unstructured modeling elements. Such elements can be even more
          flexible.


          > [Heavyweight strengths] It provides general accessibility to the
          requirements.

          Ambler identifies the following practices ( "Active Stakeholder
          Participation", "Collective Ownership, "Display Models
          Publicly" see
          http://www.agilemodeling.com/practices.htm ). Whiteboards (your
          ultra-lightweight) and Collaborative Development Environment
          (CDE)/Wiki (your lightweight) will often provide greater
          accessibility than most heavyweight tooling.


          > [Heavyweight weakness] It is costly. Individual licenses can cost
          thousands of dollars

          Gross generalisation. Furthermore, there are heavyweight open-source
          tools!


          > [Heavyweight weakness] It stores requirements in a proprietary
          database.

          Some heavyweight tools persist models in XML.


          > [Lightweight strength] It is cheap. Developers usually have the
          tools for other reasons.

          Perhaps what you really mean here is "It is pervasive". Open source
          licensing may = initial zero cost but <> ultimately zero/low cost.


          > [Lightweight strength] It is open.

          I typically associate open with "open for extension" as in the
          Open/Closed Principle OCP. Thus, any tool can be open if it was
          designed to observe OCP (many heavyweight tools are open).


          > [Lightweight weakness] It does not embody requirements at the
          correct level of granularity

          Further to the related response above; lightweight tooling does not
          necessarily suffer from this weakness. Consider a Wiki generation2
          tool that can abstract requirement artifacts (ie. model views,
          business rules, constraints, changes cases, screen
          sketches/navigational proto etc) as separate files that become
          independent manageable units under SCM
          eg UC diag.
          http://www.self.com.au/aid/visit/project/self/aid/requirement/uc/Proje
          ctStakeholderGoals
          eg UC Spec.
          http://www.self.com.au/aid/visit/project/self/aid/requirement/uc/Revie
          wStatus
          eg Screen Sketch (SVGViewer required).
          http://www.self.com.au/aid/visit/project/self/aid/requirement/screens/
          SearchingSelfAidReqFolder
          eg Business rule.
          http://www.self.com.au/aid/visit/project/self/aid/requirement/br/Execu
          tableDocumentAsBinary


          > [Lightweight weakness] It does not provide reasoning support for
          the requirements. Because the requirements are stored in natural or
          semi-formal language, they cannot be reliably manipulated or
          transformed.

          You are assuming that an unstructured data field (eg. Blob, Clob, or
          file) is storing data that cannot be easily parsed. What it the file
          was storing the contents of a java properties file?


          <snip>
          It should embody requirements at the correct level of granularity;
          It should give developers a lot of flexibility with respect to
          embodiment;
          It should provide general accessibility to the requirements;
          It should provide reasoning support for the requirements;
          It should be cheap;
          It should be simple;
          It should be open.
          </snip>

          This is a good. After 11 years of Rational tooling, I too started
          this exercise with a series of constraints and principles. I evolved
          those requirements and was influenced by observing systems that
          worked until a model started to take shape. Those influences included:
          - Ward Cunningham's Wiki
          - Scott Ambler's Agile Modeling
          - Ellen Gottesdiener's Wall of Wonder

          Sadly, I no longer have the original requirements model (it was on
          paper and pencil <g>), but the following url presents one that I
          created to serve multiple purposes:
          http://www.self.com.au/aid/visit/project/self/aid/requirement/Index

          You may find the following links of interest for your research:
          http://www.self.com.au/aid/visit/grp/am/lean%20tools/Index
          http://www.self.com.au/aid/visit/self/www/presentation/opening%20up%
          20a%20wall%20of%20wonder/Index
          http://www.self.com.au/aid/visit/self/www/presentation/aid%20show%
          20and%20tell/Purpose.wik

          My vision was that /any artifact/ (in its native form) that entered
          into the CDE had the ability to morph (ie Wiki metaphor) and hence
          promotes collaboration/parallel contributions. This included:
          1. any diagram can morph -
          http://www.self.com.au/aid/visit/self/www/presentation/aid%20show%
          20and%20tell/sandbox/EditorGoals.ucd
          2. any structured data can morph (UCS in bredemeyer format) -
          http://www.self.com.au/aid/visit/self/www/presentation/aid%20show%
          20and%20tell/sandbox/MaintainDocument.bmucs
          3. generated javadocs can morph -
          http://www.self.com.au/aid/visit/self/www/presentation/aid%20show%
          20and%20tell/sandbox/docs/self/aid/demo/editor/package-summary.html
          4. java source code can morph -
          http://www.self.com.au/aid/visit/self/www/presentation/aid%20show%
          20and%20tell/sandbox/impl/Command.java
          etc.

          ---
          If I had to walk this path again, I would leverage from Fitnesse as a
          framework.

          I hope the feedback was useful. Good luck and enjoy this highly
          rewarding journey.

          rgds ash
          <self>Helping you get there on your own</self>
        • Steve Bannerman
          Ash, Thanks for your comments and suggestions. However, since none of them are really specific to Scrum, I will mail you separately regarding them. Cheers ...
          Message 4 of 4 , Aug 29, 2003
          • 0 Attachment
            Ash,

            Thanks for your comments and suggestions. However, since none of them are
            really specific to Scrum, I will mail you separately regarding them.

            Cheers

            > Hi Steve,
            >
            > You certainly cover a lot of mileage in this paper!
            > .
            > .
            > .
            --
            Steve Bannerman
            steve.bannerman@...
            44.(0)1865.273866
          Your message has been successfully submitted and would be delivered to recipients shortly.