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

SCRUM process with other methodologies

Expand Messages
  • Michael Dowling
    Hey all: The company I work for is implementing a SCRUM process for our development teams, and so far so good! I ve worked with SCRUM before, but I ve also
    Message 1 of 22 , Apr 5, 2004
    • 0 Attachment
      Hey all:

      The company I work for is implementing a SCRUM process for our
      development teams, and so far so good! I've worked with SCRUM before,
      but I've also almost always used SCRUM during development only, and
      using other methodologies and artifacts from other methodologies (i.e.
      JAD to gather requirements BEFORE the item is placed on a backlog and
      some of UP's artifacts such as sequence and class diagrams for effective
      communication of a design idea to your SCRUM team) for other parts of
      the process as a whole.

      I would like to hear whether any one else has experimented with this
      approach, and what their results were? Any recommendations?

      Best regards,

      -Michael

      --

      Michael Dowling
      mdowling@...
      PlanetOut Partners, Inc.
      415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
      www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com
    • Dan Rawsthorne
      Sounds like it would work for me, but why aren t the analysis and artifact construction teaks part of the backlog so that they can be prioritized with the
      Message 2 of 22 , Apr 5, 2004
      • 0 Attachment
        Sounds like it would work for me, but why aren't the analysis and
        artifact construction teaks part of the backlog so that they can be
        prioritized with the rest?

        Dan ;-)

        Dan Rawsthorne, PhD, Sr. Consultant
        www.netobjectives.com
        DrDan@...
        office: 425-269-8628

        Net Objectives' vision is effective software development without
        suffering. Our mission is to assist software development teams in
        accomplishing this through a combination of training and mentoring.


        > -----Original Message-----
        > From: Michael Dowling [mailto:mdowling@...]
        > Sent: Monday, April 05, 2004 11:42 AM
        > To: scrumdevelopment@yahoogroups.com
        > Subject: [scrumdevelopment] SCRUM process with other methodologies
        >
        > Hey all:
        >
        > The company I work for is implementing a SCRUM process for our
        > development teams, and so far so good! I've worked with SCRUM before,
        > but I've also almost always used SCRUM during development only, and
        > using other methodologies and artifacts from other methodologies (i.e.
        > JAD to gather requirements BEFORE the item is placed on a backlog and
        > some of UP's artifacts such as sequence and class diagrams for
        effective
        > communication of a design idea to your SCRUM team) for other parts of
        > the process as a whole.
        >
        > I would like to hear whether any one else has experimented with this
        > approach, and what their results were? Any recommendations?
        >
        > Best regards,
        >
        > -Michael
        >
        > --
        >
        > Michael Dowling
        > mdowling@...
        > PlanetOut Partners, Inc.
        > 415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
        > www.gay.com * www.planetout.com * www.kleptomaniac.com *
        > www.outandabout.com
        >
        >
        >
        > ------------------------ Yahoo! Groups Sponsor
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to: scrumdevelopment-
        > unsubscribe@...
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        > ______________________________________________________________________
        > This email has been scanned by the MessageLabs Email Security System.
        > For more information please visit http://www.messagelabs.com/email
        > ______________________________________________________________________
      • Mike Cohn
        Hi Michael-- I have experimented before with exactly what you describe. In introducing Scrum to a couple of different organizations I couldn t get them to
        Message 3 of 22 , Apr 5, 2004
        • 0 Attachment
          Hi Michael--

          I have experimented before with exactly what you describe. In introducing
          Scrum to a couple of different organizations I couldn't get them to
          initially accept the idea that we didn't need to think up all the
          requirements upfront. To get the project moving I had them do a two week
          "Requirements Capture Sprint" which focused just on getting initial
          requirements written down. We still went very lightweight, using much of the
          advice in Cockburn's "Effective Use Cases" book. They also couldn't get
          around the idea that there'd be no upfront architecting so we did another
          two week "Analysis and Design Sprint" (ADS) that was intended to allay that
          fear.

          Some advice:
          --realize this is a crutch and try to stop it as soon as you can. I never
          had to do it more than once, right at the start. By the second project no
          one needed it.
          --It does work well so there's no problem with it, except developers could
          be tempted to turn it into 4 weeks then 6, then 8.
          --Although when I've done a Requirements Capture Sprint in the past I've
          done it with use cases, I'd probably do it these days with it even shorter
          (1 week instead of 2) and use stories instead of use cases.

          This is written up (in only slightly more detail) in a paper I did for IEEE
          Computer last year. You can read it at:
          http://www.mountaingoatsoftware.com/articles.php and select "Introducing An
          Agile Process to an Organization."

          Good luck,

          --Mike Cohn
          Author of User Stories Applied for Agile Software Development
          www.userstories.com


          -----Original Message-----
          From: Michael Dowling [mailto:mdowling@...]
          Sent: Monday, April 05, 2004 11:42 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] SCRUM process with other methodologies

          Hey all:

          The company I work for is implementing a SCRUM process for our
          development teams, and so far so good! I've worked with SCRUM before,
          but I've also almost always used SCRUM during development only, and
          using other methodologies and artifacts from other methodologies (i.e.
          JAD to gather requirements BEFORE the item is placed on a backlog and
          some of UP's artifacts such as sequence and class diagrams for effective
          communication of a design idea to your SCRUM team) for other parts of
          the process as a whole.

          I would like to hear whether any one else has experimented with this
          approach, and what their results were? Any recommendations?

          Best regards,

          -Michael

          --

          Michael Dowling
          mdowling@...
          PlanetOut Partners, Inc.
          415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
          www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com




          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...
          Yahoo! Groups Links
        • Ron Jeffries
          ... Which approach? Using Scrum? Or using Scrum plus a bunch of artifacts from other methods? Ron Jeffries www.XProgramming.com Computers are useless. They can
          Message 4 of 22 , Apr 5, 2004
          • 0 Attachment
            On Monday, April 5, 2004, at 2:42:14 PM, Michael Dowling wrote:

            > The company I work for is implementing a SCRUM process for our
            > development teams, and so far so good! I've worked with SCRUM before,
            > but I've also almost always used SCRUM during development only, and
            > using other methodologies and artifacts from other methodologies (i.e.
            > JAD to gather requirements BEFORE the item is placed on a backlog and
            > some of UP's artifacts such as sequence and class diagrams for effective
            > communication of a design idea to your SCRUM team) for other parts of
            > the process as a whole.

            > I would like to hear whether any one else has experimented with this
            > approach, and what their results were? Any recommendations?

            Which approach? Using Scrum? Or using Scrum plus a bunch of artifacts from
            other methods?

            Ron Jeffries
            www.XProgramming.com
            Computers are useless. They can only give you answers. -- Picasso
          • Michael Dowling
            ... So, basically Gather Requirements on Feature X be a backlog item to be prioritized? That priority is implicit - engineering work cannot be done on a
            Message 5 of 22 , Apr 5, 2004
            • 0 Attachment
              > Sounds like it would work for me, but why aren't the analysis and
              > artifact construction teaks part of the backlog so that they can be
              > prioritized with the rest?

              So, basically "Gather Requirements on Feature X" be a backlog item to be
              prioritized? That priority is implicit - engineering work cannot be
              done on a "feature" or "bug" without proper analysis (be it short or
              lengthy, depending on the organization and/or team). This is why I
              assume that a backlog item should already have gone through the
              requirements phase already - it is generally, almost always during this
              time that features and needs are found to be either a) necessary, b)
              unnecessary, or c) nifty, but not yet important. From there one can
              pass it to a backlog for prioritization, but only after knowing what the
              heck one wants.

              I know - this does sound a little waterfallish. But think of it this
              way - collaborative waterfall. JAD is similar to SCRUM whereas all
              members of a JAD team collaborate on the project. You're just
              "waterfalling" the collaboration from one phase to the next. And SCRUM
              allows for the (certain and expected) changes in those requirements.


              > Dan Rawsthorne, PhD, Sr. Consultant
              > www.netobjectives.com
              > DrDan@...
              > office: 425-269-8628

              Off-topic - hey - are you from the same group that did (does?) the
              lectures/seminars in Bellvue on proper design techniques? You guys did
              a fabulous job, and with each lecture I walked away with a new idea of
              better design. Do you ever hold these lectures in the SF Bay Area
              (yeah, had to return to San Francisco - Seattle was too wet for me! :) ).


              --

              Michael Dowling
              mdowling@...
              PlanetOut Partners, Inc.
              415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
              www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com
            • Michael Dowling
              ... Using SCRUM alongside artifacts and process from other methods :) -Michael -- Michael Dowling mdowling@planetoutpartners.com PlanetOut Partners, Inc.
              Message 6 of 22 , Apr 5, 2004
              • 0 Attachment
                >>I would like to hear whether any one else has experimented with this
                >>approach, and what their results were? Any recommendations?
                >
                >
                > Which approach? Using Scrum? Or using Scrum plus a bunch of artifacts from
                > other methods?

                Using SCRUM alongside artifacts and process from other methods :)

                -Michael

                --

                Michael Dowling
                mdowling@...
                PlanetOut Partners, Inc.
                415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
                www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com
              • Ron Jeffries
                ... Ah. Yes and no. I use Scrum-style planning along with practices from XP. (We call that XP.) I ve seen many projects using XP, or Scrum, with a few random
                Message 7 of 22 , Apr 5, 2004
                • 0 Attachment
                  On Monday, April 5, 2004, at 4:49:13 PM, Michael Dowling wrote:

                  >>>I would like to hear whether any one else has experimented with this
                  >>>approach, and what their results were? Any recommendations?
                  >>
                  >>
                  >> Which approach? Using Scrum? Or using Scrum plus a bunch of artifacts from
                  >> other methods?

                  > Using SCRUM alongside artifacts and process from other methods :)

                  Ah. Yes and no. I use Scrum-style planning along with practices from XP.
                  (We call that XP.) I've seen many projects using XP, or Scrum, with a few
                  random artifacts that they found that they liked and wanted.

                  If this is done because some aspect of the project needs that artifact,
                  well and good. If it is done because it is believe that all projects
                  "should", this is, in my strong opinion, a mistake. Not all project do need
                  those things.

                  It's best to get down to specifics when it comes to agile methods, namely
                  to consider a specific project and a specific artifact or practices, and
                  whether that project should, or should not, do that thing.

                  Since real Scrum projects ship real software every month, many artifacts
                  become redundant. Others, such as up front considerations, may or may not.

                  With a more specific question, I'd have a more specific answer. In general,
                  my answer is that in general, Scrum is perfectly safe as it stands and is a
                  good place to start. It will provide feedback that will let you assess, for
                  each project, whether it should produce other materials.

                  Ron Jeffries
                  www.XProgramming.com
                  Hold on to your dream. --ELO
                • Michael Dowling
                  Excellent, Mike. For us, its going to take some time to sprint everything. Although - for us, having 2-week requirements gathering might be a bit much. 1
                  Message 8 of 22 , Apr 5, 2004
                  • 0 Attachment
                    Excellent, Mike. For us, its going to take some time to "sprint"
                    everything. Although - for us, having 2-week requirements gathering
                    might be a bit much. 1 week max I would hope. But I see your point -
                    the basic framework can be applied to each phase, slightly customized
                    given the context.

                    We're also considering the use of XPlanner as a tool (www.xplanner.org)
                    to help us track our sprints and create burn graphs for management much
                    easier. I've used it before (and *adore* it), but some folks also want
                    to take a look at some other tools (excel just doesn't cut it). Basic
                    requirement is that it be as simple as scrum itself.

                    What have you had success in?

                    Thank you for your comments - much appreciated!

                    -Michael

                    Mike Cohn wrote:

                    > Hi Michael--
                    >
                    > I have experimented before with exactly what you describe. In introducing
                    > Scrum to a couple of different organizations I couldn't get them to
                    > initially accept the idea that we didn't need to think up all the
                    > requirements upfront. To get the project moving I had them do a two week
                    > "Requirements Capture Sprint" which focused just on getting initial
                    > requirements written down. We still went very lightweight, using much of the
                    > advice in Cockburn's "Effective Use Cases" book. They also couldn't get
                    > around the idea that there'd be no upfront architecting so we did another
                    > two week "Analysis and Design Sprint" (ADS) that was intended to allay that
                    > fear.
                    >
                    > Some advice:
                    > --realize this is a crutch and try to stop it as soon as you can. I never
                    > had to do it more than once, right at the start. By the second project no
                    > one needed it.
                    > --It does work well so there's no problem with it, except developers could
                    > be tempted to turn it into 4 weeks then 6, then 8.
                    > --Although when I've done a Requirements Capture Sprint in the past I've
                    > done it with use cases, I'd probably do it these days with it even shorter
                    > (1 week instead of 2) and use stories instead of use cases.
                    >
                    > This is written up (in only slightly more detail) in a paper I did for IEEE
                    > Computer last year. You can read it at:
                    > http://www.mountaingoatsoftware.com/articles.php and select "Introducing An
                    > Agile Process to an Organization."
                    >
                    > Good luck,
                    >
                    > --Mike Cohn
                    > Author of User Stories Applied for Agile Software Development
                    > www.userstories.com
                    >
                    >
                    > -----Original Message-----
                    > From: Michael Dowling [mailto:mdowling@...]
                    > Sent: Monday, April 05, 2004 11:42 AM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: [scrumdevelopment] SCRUM process with other methodologies
                    >
                    > Hey all:
                    >
                    > The company I work for is implementing a SCRUM process for our
                    > development teams, and so far so good! I've worked with SCRUM before,
                    > but I've also almost always used SCRUM during development only, and
                    > using other methodologies and artifacts from other methodologies (i.e.
                    > JAD to gather requirements BEFORE the item is placed on a backlog and
                    > some of UP's artifacts such as sequence and class diagrams for effective
                    > communication of a design idea to your SCRUM team) for other parts of
                    > the process as a whole.
                    >
                    > I would like to hear whether any one else has experimented with this
                    > approach, and what their results were? Any recommendations?
                    >
                    > Best regards,
                    >
                    > -Michael
                    >

                    --

                    Michael Dowling
                    mdowling@...
                    PlanetOut Partners, Inc.
                    415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
                    www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com
                  • Roberts, David J (CNSP N6124V13)
                    Anyone interested, I find developers to be the most fearful of incremental development (without admitting). You mean I have to revisit my code? I thought I
                    Message 9 of 22 , Apr 5, 2004
                    • 0 Attachment

                      Anyone interested,

                       

                      I find developers to be the most fearful of incremental development (without admitting).

                       

                      "You mean I have to revisit my code? I thought I was done with that..."

                       

                      David Roberts

                      InnovaSystems

                       

                      -----Original Message-----
                      From: Mike Cohn [mailto:mike@...]
                      Sent
                      :
                      Monday, April 05, 2004 12:28 PM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: RE: [scrumdevelopment] SCRUM process with other methodologies

                       

                      Hi Michael--

                      I have experimented before with exactly what you describe. In introducing
                      Scrum to a couple of different organizations I couldn't get them to
                      initially accept the idea that we didn't need to think up all the
                      requirements upfront. To get the project moving I had them do a two week
                      "Requirements Capture Sprint" which focused just on getting initial
                      requirements written down. We still went very lightweight, using much of the
                      advice in Cockburn's "Effective Use Cases" book. They also couldn't get
                      around the idea that there'd be no upfront architecting so we did another
                      two week "Analysis and Design Sprint" (ADS) that was intended to allay that
                      fear.

                      Some advice:
                      --realize this is a crutch and try to stop it as soon as you can. I never
                      had to do it more than once, right at the start. By the second project no
                      one needed it.
                      --It does work well so there's no problem with it, except developers could
                      be tempted to turn it into 4 weeks then 6, then 8.
                      --Although when I've done a Requirements Capture Sprint in the past I've
                      done it with use cases, I'd probably do it these days with it even shorter
                      (1 week instead of 2) and use stories instead of use cases.

                      This is written up (in only slightly more detail) in a paper I did for IEEE
                      Computer last year. You can read it at:
                      http://www.mountaingoatsoftware.com/articles.php and select "Introducing An
                      Agile Process to an Organization."

                      Good luck,

                      --Mike Cohn
                      Author of User Stories Applied for Agile Software Development
                      www.userstories.com


                      -----Original Message-----
                      From: Michael Dowling [mailto:mdowling@...]
                      Sent: Monday, April 05, 2004 11:42 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: [scrumdevelopment] SCRUM process with other methodologies

                      Hey all:

                      The company I work for is implementing a SCRUM process for our
                      development teams, and so far so good!  I've worked with SCRUM before,
                      but I've also almost always used SCRUM during development only, and
                      using other methodologies and artifacts from other methodologies (i.e.
                      JAD to gather requirements BEFORE the item is placed on a backlog and
                      some of UP's artifacts such as sequence and class diagrams for effective
                      communication of a design idea to your SCRUM team) for other parts of
                      the process as a whole.

                      I would like to hear whether any one else has experimented with this
                      approach, and what their results were?  Any recommendations?

                      Best regards,

                      -Michael

                      --

                      Michael Dowling
                      mdowling@...
                      PlanetOut Partners, Inc.
                      415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
                      www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com




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







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




                    • Mike Cohn
                      Michael-- For the most part you really want to do all that analysis work as part of the sprint. Keep in mind that requirements are like inventory and we don t
                      Message 10 of 22 , Apr 5, 2004
                      • 0 Attachment
                        Michael--
                        For the most part you really want to do all that analysis work as part of
                        the sprint. Keep in mind that requirements are like inventory and we don't
                        want to pile up too much inventory that may never turn into finished
                        software. Plus, if you do it too soon you lose the ability to have new
                        learning impact those requirements and the knowledge goes stale quite
                        quickly. A couple of short, to-the-point, upfront conversations don't hurt
                        but when you start writing it all down, referring back to it, pointing to it
                        as though it means something, then you've done too much requirements work
                        upfront.

                        --Mike Cohn
                        Author of User Stories Applied for Agile Software Development
                        www.userstories.com


                        -----Original Message-----
                        From: Michael Dowling [mailto:mdowling@...]
                        Sent: Monday, April 05, 2004 1:48 PM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] SCRUM process with other methodologies

                        > Sounds like it would work for me, but why aren't the analysis and
                        > artifact construction teaks part of the backlog so that they can be
                        > prioritized with the rest?

                        So, basically "Gather Requirements on Feature X" be a backlog item to be
                        prioritized? That priority is implicit - engineering work cannot be
                        done on a "feature" or "bug" without proper analysis (be it short or
                        lengthy, depending on the organization and/or team). This is why I
                        assume that a backlog item should already have gone through the
                        requirements phase already - it is generally, almost always during this
                        time that features and needs are found to be either a) necessary, b)
                        unnecessary, or c) nifty, but not yet important. From there one can
                        pass it to a backlog for prioritization, but only after knowing what the
                        heck one wants.

                        I know - this does sound a little waterfallish. But think of it this
                        way - collaborative waterfall. JAD is similar to SCRUM whereas all
                        members of a JAD team collaborate on the project. You're just
                        "waterfalling" the collaboration from one phase to the next. And SCRUM
                        allows for the (certain and expected) changes in those requirements.


                        > Dan Rawsthorne, PhD, Sr. Consultant
                        > www.netobjectives.com
                        > DrDan@...
                        > office: 425-269-8628

                        Off-topic - hey - are you from the same group that did (does?) the
                        lectures/seminars in Bellvue on proper design techniques? You guys did
                        a fabulous job, and with each lecture I walked away with a new idea of
                        better design. Do you ever hold these lectures in the SF Bay Area
                        (yeah, had to return to San Francisco - Seattle was too wet for me! :) ).


                        --

                        Michael Dowling
                        mdowling@...
                        PlanetOut Partners, Inc.
                        415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
                        www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com



                        To Post a message, send it to: scrumdevelopment@...
                        To Unsubscribe, send a blank message to:
                        scrumdevelopment-unsubscribe@...
                        Yahoo! Groups Links
                      • Dan Rawsthorne
                        Yes, Analyze XXX is a backlog item. One wouldn t do it unless XXX had a high enough priority to do it, right? In a system where we think of 50 use cases up
                        Message 11 of 22 , Apr 5, 2004
                        • 0 Attachment
                          Yes, "Analyze XXX" is a backlog item. One wouldn't do it unless XXX had
                          a high enough priority to do it, right? In a system where we think of 50
                          use cases up front we don't analyze all of them up front, we analyze
                          them as we go.

                          So, these analysis tasks must be on somebody's backlog. If that somebody
                          is another, analysis, team, that's ok, but I prefer my team to be one,
                          big, happy, one - including analysts, coders, testers, etc - with one,
                          big, happy product backlog...

                          Dan ;-)

                          Dan Rawsthorne, PhD, Sr. Consultant
                          www.netobjectives.com
                          DrDan@...
                          office: 425-269-8628

                          Net Objectives' vision is effective software development without
                          suffering. Our mission is to assist software development teams in
                          accomplishing this through a combination of training and mentoring.


                          > -----Original Message-----
                          > From: Michael Dowling [mailto:mdowling@...]
                          > Sent: Monday, April 05, 2004 1:48 PM
                          > To: scrumdevelopment@yahoogroups.com
                          > Subject: Re: [scrumdevelopment] SCRUM process with other methodologies
                          >
                          > > Sounds like it would work for me, but why aren't the analysis and
                          > > artifact construction teaks part of the backlog so that they can be
                          > > prioritized with the rest?
                          >
                          > So, basically "Gather Requirements on Feature X" be a backlog item to
                          be
                          > prioritized? That priority is implicit - engineering work cannot be
                          > done on a "feature" or "bug" without proper analysis (be it short or
                          > lengthy, depending on the organization and/or team). This is why I
                          > assume that a backlog item should already have gone through the
                          > requirements phase already - it is generally, almost always during
                          this
                          > time that features and needs are found to be either a) necessary, b)
                          > unnecessary, or c) nifty, but not yet important. From there one can
                          > pass it to a backlog for prioritization, but only after knowing what
                          the
                          > heck one wants.
                          >
                          > I know - this does sound a little waterfallish. But think of it this
                          > way - collaborative waterfall. JAD is similar to SCRUM whereas all
                          > members of a JAD team collaborate on the project. You're just
                          > "waterfalling" the collaboration from one phase to the next. And
                          SCRUM
                          > allows for the (certain and expected) changes in those requirements.
                          >
                          >
                          > > Dan Rawsthorne, PhD, Sr. Consultant
                          > > www.netobjectives.com
                          > > DrDan@...
                          > > office: 425-269-8628
                          >
                          > Off-topic - hey - are you from the same group that did (does?) the
                          > lectures/seminars in Bellvue on proper design techniques? You guys
                          did
                          > a fabulous job, and with each lecture I walked away with a new idea of
                          > better design. Do you ever hold these lectures in the SF Bay Area
                          > (yeah, had to return to San Francisco - Seattle was too wet for me!
                          :) ).
                          >
                          >
                          > --
                          >
                          > Michael Dowling
                          > mdowling@...
                          > PlanetOut Partners, Inc.
                          > 415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
                          > www.gay.com * www.planetout.com * www.kleptomaniac.com *
                          > www.outandabout.com
                          >
                          >
                          >
                          > To Post a message, send it to: scrumdevelopment@...
                          > To Unsubscribe, send a blank message to: scrumdevelopment-
                          > unsubscribe@...
                          > Yahoo! Groups Links
                          >
                          >
                          >
                          >
                          >
                          >
                          > ______________________________________________________________________
                          > This email has been scanned by the MessageLabs Email Security System.
                          > For more information please visit http://www.messagelabs.com/email
                          > ______________________________________________________________________
                        • Roberts, David J (CNSP N6124V13)
                          Michael, I find the time features are found to be necessary always seems to come after you ve developed something. You re lucky if otherwise is true for you. I
                          Message 12 of 22 , Apr 5, 2004
                          • 0 Attachment

                            Michael,

                             

                            I find the time features are found to be necessary always seems to come after you've developed something. You're lucky if otherwise is true for you.

                             

                            I see developers having these meeting with customers. The developers leave thinking, "I've locked down these requirements!" and the customer leaves thinking "I know what they're going to build me". Both are problematic.

                             

                            What did you mean when you said: "You're just "waterfalling" the collaboration from one phase to the next".

                            What are these phases?

                             

                            David Roberts

                            TRMS Technical Lead

                            (619) 368-9621

                             

                            -----Original Message-----
                            From: Michael Dowling [mailto:mdowling@...]
                            Sent: Monday, April 05, 2004 1:48 PM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] SCRUM process with other methodologies

                             

                            > Sounds like it would work for me, but why aren't the analysis and
                            > artifact construction teaks part of the backlog so that they can be
                            > prioritized with the rest?

                            So, basically "Gather Requirements on Feature X" be a backlog item to be
                            prioritized?  That priority is implicit - engineering work cannot be
                            done on a "feature" or "bug" without proper analysis (be it short or
                            lengthy, depending on the organization and/or team).  This is why I
                            assume that a backlog item should already have gone through the
                            requirements phase already - it is generally, almost always during this
                            time that features and needs are found to be either a) necessary, b)
                            unnecessary, or c) nifty, but not yet important.  From there one can
                            pass it to a backlog for prioritization, but only after knowing what the
                            heck one wants.

                            I know - this does sound a little waterfallish.  But think of it this
                            way - collaborative waterfall.  JAD is similar to SCRUM whereas all
                            members of a JAD team collaborate on the project.  You're just
                            "waterfalling" the collaboration from one phase to the next.  And SCRUM
                            allows for the (certain and expected) changes in those requirements.


                            > Dan Rawsthorne, PhD, Sr. Consultant
                            > www.netobjectives.com
                            > DrDan@...
                            > office: 425-269-8628

                            Off-topic - hey - are you from the same group that did (does?) the
                            lectures/seminars in Bellvue on proper design techniques?  You guys did
                            a fabulous job, and with each lecture I walked away with a new idea of
                            better design.  Do you ever hold these lectures in the SF Bay Area
                            (yeah, had to return to San Francisco - Seattle was too wet for me!  :) ).


                            --

                            Michael Dowling
                            mdowling@...
                            PlanetOut Partners, Inc.
                            415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
                            www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com



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



                          • Mike Cohn
                            I have successfully used: --cards --a wiki --rows in Excel --TestTrack (a defect tracker, with each story/task entered as a record) My preference is for cards
                            Message 13 of 22 , Apr 5, 2004
                            • 0 Attachment
                              I have successfully used:

                              --cards
                              --a wiki
                              --rows in Excel
                              --TestTrack (a defect tracker, with each story/task entered as a record)

                              My preference is for cards whenever we're collocated. I want to try out
                              XPlanner and VersionOne sometime but haven't tried either yet.

                              --Mike Cohn
                              Author of User Stories Applied for Agile Software Development
                              www.userstories.com


                              -----Original Message-----
                              From: Michael Dowling [mailto:mdowling@...]
                              Sent: Monday, April 05, 2004 4:53 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: Re: [scrumdevelopment] SCRUM process with other methodologies

                              Excellent, Mike. For us, its going to take some time to "sprint"
                              everything. Although - for us, having 2-week requirements gathering
                              might be a bit much. 1 week max I would hope. But I see your point -
                              the basic framework can be applied to each phase, slightly customized
                              given the context.

                              We're also considering the use of XPlanner as a tool (www.xplanner.org)
                              to help us track our sprints and create burn graphs for management much
                              easier. I've used it before (and *adore* it), but some folks also want
                              to take a look at some other tools (excel just doesn't cut it). Basic
                              requirement is that it be as simple as scrum itself.

                              What have you had success in?

                              Thank you for your comments - much appreciated!

                              -Michael

                              Mike Cohn wrote:

                              > Hi Michael--
                              >
                              > I have experimented before with exactly what you describe. In introducing
                              > Scrum to a couple of different organizations I couldn't get them to
                              > initially accept the idea that we didn't need to think up all the
                              > requirements upfront. To get the project moving I had them do a two week
                              > "Requirements Capture Sprint" which focused just on getting initial
                              > requirements written down. We still went very lightweight, using much of
                              the
                              > advice in Cockburn's "Effective Use Cases" book. They also couldn't get
                              > around the idea that there'd be no upfront architecting so we did another
                              > two week "Analysis and Design Sprint" (ADS) that was intended to allay
                              that
                              > fear.
                              >
                              > Some advice:
                              > --realize this is a crutch and try to stop it as soon as you can. I never
                              > had to do it more than once, right at the start. By the second project no
                              > one needed it.
                              > --It does work well so there's no problem with it, except developers could
                              > be tempted to turn it into 4 weeks then 6, then 8.
                              > --Although when I've done a Requirements Capture Sprint in the past I've
                              > done it with use cases, I'd probably do it these days with it even shorter
                              > (1 week instead of 2) and use stories instead of use cases.
                              >
                              > This is written up (in only slightly more detail) in a paper I did for
                              IEEE
                              > Computer last year. You can read it at:
                              > http://www.mountaingoatsoftware.com/articles.php and select "Introducing
                              An
                              > Agile Process to an Organization."
                              >
                              > Good luck,
                              >
                              > --Mike Cohn
                              > Author of User Stories Applied for Agile Software Development
                              > www.userstories.com
                              >
                              >
                              > -----Original Message-----
                              > From: Michael Dowling [mailto:mdowling@...]
                              > Sent: Monday, April 05, 2004 11:42 AM
                              > To: scrumdevelopment@yahoogroups.com
                              > Subject: [scrumdevelopment] SCRUM process with other methodologies
                              >
                              > Hey all:
                              >
                              > The company I work for is implementing a SCRUM process for our
                              > development teams, and so far so good! I've worked with SCRUM before,
                              > but I've also almost always used SCRUM during development only, and
                              > using other methodologies and artifacts from other methodologies (i.e.
                              > JAD to gather requirements BEFORE the item is placed on a backlog and
                              > some of UP's artifacts such as sequence and class diagrams for effective
                              > communication of a design idea to your SCRUM team) for other parts of
                              > the process as a whole.
                              >
                              > I would like to hear whether any one else has experimented with this
                              > approach, and what their results were? Any recommendations?
                              >
                              > Best regards,
                              >
                              > -Michael
                              >

                              --

                              Michael Dowling
                              mdowling@...
                              PlanetOut Partners, Inc.
                              415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
                              www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com




                              To Post a message, send it to: scrumdevelopment@...
                              To Unsubscribe, send a blank message to:
                              scrumdevelopment-unsubscribe@...
                              Yahoo! Groups Links
                            • Ron Jeffries
                              ... Isn t that why Scrum ships software every month, and XP and Crystal even more often? Ron Jeffries www.XProgramming.com Anyone can make the simple
                              Message 14 of 22 , Apr 5, 2004
                              • 0 Attachment
                                On Monday, April 5, 2004, at 9:23:18 PM, Roberts, David J (CNSP N6124V13) wrote:

                                > I find the time features are found to be necessary always seems to come
                                > after you've developed something. You're lucky if otherwise is true for you.

                                > I see developers having these meeting with customers. The developers leave
                                > thinking, "I've locked down these requirements!" and the customer leaves
                                > thinking "I know what they're going to build me". Both are problematic.

                                Isn't that why Scrum ships software every month, and XP and Crystal even
                                more often?

                                Ron Jeffries
                                www.XProgramming.com
                                Anyone can make the simple complicated.
                                Creativity is making the complicated simple. -- Charles Mingus
                              • Jens Ƙstergaard
                                I ve used it before (and *adore* it), but some folks also want ... Basic ... Hi Michael I have had absolutely no problem using excel and find that it works vey
                                Message 15 of 22 , Apr 6, 2004
                                • 0 Attachment
                                  I've used it before (and *adore* it), but some folks also want
                                  > to take a look at some other tools (excel just doesn't cut it).
                                  Basic
                                  > requirement is that it be as simple as scrum itself.
                                  >

                                  Hi Michael

                                  I have had absolutely no problem using excel and find that it works
                                  vey well. If a team needs additional material for coordination, they
                                  figure it out themselves.

                                  If you sign in and look under files, I have posted an example of a
                                  sprintlog that we use.

                                  Jens
                                • Reginald Braithwaite-Lee
                                  ... Whenever possible, I like to use corkboards or whiteboards. I m considering using a projector and a dedicated PC on my next project for things that don t
                                  Message 16 of 22 , Apr 6, 2004
                                  • 0 Attachment
                                    --- Mike Cohn <mike@...> wrote:
                                    > I have successfully used:
                                    >
                                    > --cards
                                    > --a wiki
                                    > --rows in Excel
                                    > --TestTrack (a defect tracker, with each story/task entered as a
                                    > record)

                                    Whenever possible, I like to use corkboards or whiteboards. I'm
                                    considering using a projector and a dedicated PC on my next project for
                                    things that don't work well on paper.

                                    http://www.braithwaite-lee.com/opinions/cork-board.html

                                    --
                                    Reginald Braithwaite-Lee
                                    http://www.braithwaite-lee.com

                                    "Even when my proposals are seen as significant improvements, they are
                                    often rejected on the grounds that they are not intuitive. It is a
                                    classic Catch-22: The client wants something that is significantly
                                    superior to the competition. But if it is to be superior, it must be
                                    different. (Typically, the greater the improvement, the greater the
                                    difference.) Therefore, it cannot be intuitive, that is, familiar. What
                                    the client wants is an interface with at most marginal differences from
                                    current practice... that, somehow, makes a major improvement." --Jef
                                    Raskin


                                    __________________________________
                                    Do you Yahoo!?
                                    Yahoo! Small Business $15K Web Design Giveaway
                                    http://promotions.yahoo.com/design_giveaway/
                                  • Roberts, David J (CNSP N6124V13)
                                    I would say so. That s why we do empirical. David Roberts TRMS Technical Lead (619) 368-9621 ... From: Ron Jeffries [mailto:ronjeffries@XProgramming.com] Sent:
                                    Message 17 of 22 , Apr 6, 2004
                                    • 0 Attachment

                                      I would say so. That's why we do empirical.

                                       

                                      David Roberts

                                      TRMS Technical Lead

                                      (619) 368-9621

                                       

                                      -----Original Message-----
                                      From: Ron Jeffries [mailto:ronjeffries@...]
                                      Sent: Monday, April 05, 2004 7:23 PM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: Re: [scrumdevelopment] SCRUM process with other methodologies

                                       

                                      On Monday, April 5, 2004, at 9:23:18 PM, Roberts, David J (CNSP N6124V13) wrote:

                                      > I find the time features are found to be necessary always seems to come
                                      > after you've developed something. You're lucky if otherwise is true for you.

                                      > I see developers having these meeting with customers. The developers leave
                                      > thinking, "I've locked down these requirements!" and the customer leaves
                                      > thinking "I know what they're going to build me". Both are problematic.

                                      Isn't that why Scrum ships software every month, and XP and Crystal even
                                      more often?

                                      Ron Jeffries
                                      www.XProgramming.com
                                      Anyone can make the simple complicated.
                                      Creativity is making the complicated simple. -- Charles Mingus



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



                                    • Claude Montpetit
                                      We just implemented a Scrum process and there are many stories that were added just for requirement analysis. This became necessary because the product is
                                      Message 18 of 22 , Apr 6, 2004
                                      • 0 Attachment
                                        We just implemented a Scrum process and there are many stories that
                                        were added just for requirement analysis. This became necessary
                                        because the product is already sold and installed at some customer
                                        locations (a server product). These customers have custom
                                        requirements that we do for them and they (generally) pay us. So we
                                        need to estimate the work required for it. Producing an estimate is
                                        therefore a story that must be prioritized. Once the estimate is
                                        completed and the quote sent to the customer, another story is created
                                        in the product backlog:

                                        Implement request X for customer Y based on estimate Z

                                        Implementing Scrum is very new to me and I am not sure about how to
                                        deal with, for example, urgent estimates that must enter the current
                                        sprint. Telling the salesman to wait for the next iteration for the
                                        quote is not usually a good thing as it means that the implementation
                                        would in theory start very late:

                                        - month 1: submit the request
                                        - month 2: produce the estimate
                                        - month 3: implement the request

                                        This is not practical of course so we have been inserting estimates in
                                        the current sprint and informed the customer that he must decide in
                                        the current month whether he wants to go ahead or not if he wants it
                                        to be done in the next sprint.

                                        One of the strongest problem I had (and still have) implementing this
                                        process was to convince people outside of the development team
                                        (client, marketing, sales) that they should know about details of the
                                        products (bugs, certain improvements that look "too technical"...)

                                        Once the product backlog was transfered to "clients", and when I asked
                                        them to prioritize items, they thought that there was too many
                                        details. I then realized that they felt this way because they did not
                                        understand the product enough, and that the development team had been
                                        driving the product on their own since day one. Changing this around
                                        is a real challenge. For this reason, I am currently acting as both
                                        the Scrum master and the product owner until I can find someone
                                        outside the dev team that will take the product owner role and manage
                                        priorities.

                                        But overall, the implementation of a well defined process (Scrum) has
                                        been welcomed by the client/marketing/sales side as they know what we
                                        are working on now and they have control on what is next.

                                        -
                                        Claude Montpetit
                                        http://www.montpetit.net
                                      • Ron Jeffries
                                        ... The teams I have worked with can estimate things at a rate of several hundred per day, so I would think that if all you need is an estimate, you could just
                                        Message 19 of 22 , Apr 6, 2004
                                        • 0 Attachment
                                          On Tuesday, April 6, 2004, at 5:58:14 PM, Claude Montpetit wrote:

                                          > Implementing Scrum is very new to me and I am not sure about how to
                                          > deal with, for example, urgent estimates that must enter the current
                                          > sprint. Telling the salesman to wait for the next iteration for the
                                          > quote is not usually a good thing as it means that the implementation
                                          > would in theory start very late:

                                          The teams I have worked with can estimate things at a rate of several
                                          hundred per day, so I would think that if all you need is an estimate, you
                                          could just wander in and ask. But of course there's this pig / chicken rule
                                          in Scrum, so I don't know what the official answer should be.

                                          On the other hand, my experience with sales people suggests that often
                                          things need not be as urgent as they tend to be described ...

                                          Ron Jeffries
                                          www.XProgramming.com
                                          Fear is the mindkiller. --Bene Gesserit Litany Against Fear
                                        • Mike Cohn
                                          If these are truly one or two at a time I handle them in the next morning s Daily Scrum. We ll do the Scrum meeting as normal then everyone will stay for a few
                                          Message 20 of 22 , Apr 6, 2004
                                          • 0 Attachment
                                            If these are truly one or two at a time I handle them in the next morning's
                                            Daily Scrum. We'll do the Scrum meeting as normal then everyone will stay
                                            for a few minutes and we'll estimate a story or two from the previous day or
                                            that came up early in the morning.

                                            We routinely also slip in an occasional one-hour estimating session in each
                                            sprint just to look outward at future stories. That will eventually stop but
                                            we're working through a large backlog of unestimated stories.

                                            --Mike Cohn
                                            Author of User Stories Applied for Agile Software Development
                                            www.userstories.com

                                            -----Original Message-----
                                            From: Ron Jeffries [mailto:ronjeffries@...]
                                            Sent: Tuesday, April 06, 2004 6:04 PM
                                            To: scrumdevelopment@yahoogroups.com
                                            Subject: Re: [scrumdevelopment] Scrum and requirements (was Re: SCRUM
                                            process with other methodologies)

                                            On Tuesday, April 6, 2004, at 5:58:14 PM, Claude Montpetit wrote:

                                            > Implementing Scrum is very new to me and I am not sure about how to
                                            > deal with, for example, urgent estimates that must enter the current
                                            > sprint. Telling the salesman to wait for the next iteration for the
                                            > quote is not usually a good thing as it means that the implementation
                                            > would in theory start very late:

                                            The teams I have worked with can estimate things at a rate of several
                                            hundred per day, so I would think that if all you need is an estimate, you
                                            could just wander in and ask. But of course there's this pig / chicken rule
                                            in Scrum, so I don't know what the official answer should be.

                                            On the other hand, my experience with sales people suggests that often
                                            things need not be as urgent as they tend to be described ...

                                            Ron Jeffries
                                            www.XProgramming.com
                                            Fear is the mindkiller. --Bene Gesserit Litany Against Fear



                                            To Post a message, send it to: scrumdevelopment@...
                                            To Unsubscribe, send a blank message to:
                                            scrumdevelopment-unsubscribe@...
                                            Yahoo! Groups Links
                                          • Claude Montpetit
                                            Just in case it was misunderstood, what I was referring to in my post were not the usual product backlog estimates, but estimates used to establish a fixed
                                            Message 21 of 22 , Apr 6, 2004
                                            • 0 Attachment
                                              Just in case it was misunderstood, what I was referring to in my post
                                              were not the usual product backlog estimates, but estimates used to
                                              establish a fixed price bid for some requested product extensions.
                                              Because they are for fixed price extensions, these estimation
                                              requests become stories on their own as opposed to the rough estimates
                                              that we set on most stories that enter the backlog.

                                              (I have personnally never worked on a team that can produce such
                                              estimates at a rate of hundred per day... must be great though ;)

                                              Claude

                                              --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                              <ronjeffries@X...> wrote:
                                              > On Tuesday, April 6, 2004, at 5:58:14 PM, Claude Montpetit wrote:
                                              >
                                              >>Implementing Scrum is very new to me and I am not sure about how to
                                              >>deal with, for example, urgent estimates that must enter the current
                                              >>sprint. Telling the salesman to wait for the next iteration for the
                                              >>quote is not usually a good thing as it means that the implementation
                                              >>would in theory start very late:
                                              >
                                              >The teams I have worked with can estimate things at a rate of several
                                              >hundred per day, so I would think that if all you need is an
                                              estimate, you
                                              >could just wander in and ask. But of course there's this pig
                                              > / chicken rule in Scrum, so I don't know what the official answer
                                              should be.
                                              >
                                              >On the other hand, my experience with sales people suggests that
                                              >often things need not be as urgent as they tend to be described ...
                                              >
                                              > Ron Jeffries
                                              > www.XProgramming.com
                                              > Fear is the mindkiller. --Bene Gesserit Litany Against Fear
                                            • Ron Jeffries
                                              ... Yes. If it s a whole product, that would take a half-day or a day. I m talking about story estimates. If the group is commonly called upon to do that, I
                                              Message 22 of 22 , Apr 7, 2004
                                              • 0 Attachment
                                                On Tuesday, April 6, 2004, at 11:33:23 PM, Claude Montpetit wrote:

                                                > Just in case it was misunderstood, what I was referring to in my post
                                                > were not the usual product backlog estimates, but estimates used to
                                                > establish a fixed price bid for some requested product extensions.
                                                > Because they are for fixed price extensions, these estimation
                                                > requests become stories on their own as opposed to the rough estimates
                                                > that we set on most stories that enter the backlog.

                                                > (I have personnally never worked on a team that can produce such
                                                > estimates at a rate of hundred per day... must be great though ;)

                                                Yes. If it's a whole product, that would take a half-day or a day. I'm
                                                talking about story estimates.

                                                If the group is commonly called upon to do that, I guess I'd just plan for
                                                it in the team's velocity.

                                                Ron Jeffries
                                                www.XProgramming.com
                                                Accroche toi a ton reve. --ELO
                                              Your message has been successfully submitted and would be delivered to recipients shortly.