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

RE: [scrumdevelopment] (unknown)

Expand Messages
  • Ken Schwaber
    Some thirty evaluation criteria were used in the evaluation. They were grouped into these categories: 1.Process - Flexibility to be employed for various types
    Message 1 of 26 , Jun 28, 2001
    • 0 Attachment
      Some thirty evaluation criteria were used in the evaluation. They were
      grouped into these categories:

      1.Process - Flexibility to be employed for various types of projects and
      ease of use in initiating these projects.
      2.Risk Reduction - The agility of the techniques used to reduce project risk
      without attendant reduction in flexibility. Hack resistance without loss of
      agility.
      3.Focus on working software - Focus primarily on building software.
      Artifacts and tools only used to support thinking and collaboration.
      4.Adaptive, emergent, self-organizing work and teams - Teams are presented
      with work and self-organize to do the work as the team determines.
      5.Customer interaction - Customer and team collaborate to adaptively craft
      the most appropriate product given the desired dates, costs, quality and
      functionality.
      6.Iterative, incremental - From the very start of the project, working code
      is constructed incrementally with each iteration of work.
      7.Management practices - Management empirically manages the work based on
      team capabilities, cost, time, quality and functionality. Attempts to plan
      and enforce plans are minimized or not present.

      Ken

      -----Original Message-----
      From: Robert C. Martin [mailto:rmartin@...]
      Sent: Wednesday, June 27, 2001 4:31 PM
      To: 'scrumdevelopment@yahoogroups.com'
      Subject: RE: [scrumdevelopment] (unknown)


      I'm surprised that FDD came in so low. Can you provide more information
      about your comparison system?

      Robert C. Martin | "Uncle Bob" | Software Consultants
      Object Mentor Inc. | rmartin@... | We'll help you get
      PO Box 5757 | Tel: (800) 338-6716 | your projects done.
      565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
      Suite 135 | | www.XProgramming.com
      Vernon Hills, IL, | Training and Mentoring | www.junit.org
      60061 | OO, XP, Java, C++, Python|

      "One of the great commandments of science is:
      'Mistrust arguments from authority.'" -- Carl Sagan


      > -----Original Message-----
      > From: kschwaber@... [mailto:kschwaber@...]
      > Sent: Sunday, June 24, 2001 1:17 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] (unknown)
      >
      >
      > I've written an article that is about to appear in the Cutter
      > Executive report comparing the various agile process. I included RUP
      > from Rational because of their claims of agility. Rated from
      > completely agile (3.0) to not agile (1.0, Scrum and Extrememe
      > programming were 3.0, Dynamic Systems Development Method was 2.3,
      > Feature Driven Development was 1.7, and RUP was 1.3. The RUP rating
      > was quite a surprise given their recent claims.
      >
      >
      >
      > 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/
      >
      >

      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/
    • Shimmings, Ian
      We had the same problem but only on some machines. Change the UCase to read VBA.UCase then make sure the file is saved to the location the add-in is taken
      Message 2 of 26 , Jul 26, 2004
      • 0 Attachment

        We had the same problem but only on some machines.  Change the UCase to read VBA.UCase then make sure the file is saved to the location the add-in is taken from.

         

        Ian Shimmings

        Conchango

         


        From: bearwood120a [mailto:bearwood120a@...]
        Sent: 20 July 2004 10:47
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] (unknown)

         

        I get the following error when trying to install the scrumaster add-
        in with excel. The Ucase variable is highlighted. Does anyone have a
        fix for this

        Function CommandBarExists(n) As Boolean
            Dim cb As CommandBar
            For Each cb In Application.CommandBars
                If UCase(cb.Name) = UCase(n) Then
                    CommandBarExists = True
                    Exit Function



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





        _____________________________________________________________________
        This e-mail has been scanned for viruses by MessageLabs. The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error, please notify Conchango plc as soon as possible. The unauthorised use, disclosure, copying or alteration of this message is prohibited and may be unlawful. The internet cannot guarantee the integrity of this message and therefore Conchango plc will not be liable for the message if modified.

        Reg. Heritage House, Church Road, Egham, Surrey, TW20 9QD T 44 (0) 1784 222 222 F 44 (0) 1784 222 200 E talktous@... No. 2598884
      • Paul Hodgetts
        ... I m kinda curious how you came about making that statement? I was just at the recent Scrum Gathering in Boulder, where around 50 ScrumMasters, Scrum
        Message 3 of 26 , Nov 30, 2005
        • 0 Attachment
          Ashraf Al Shafaki wrote:

          > With the growing popularity of XP, Scurm has repositioned
          > itself now more towards the project management aspects of
          > software development projects in order to fit itself in the
          > technosphere as a complement to XP rather than a competitor
          > to it.

          I'm kinda curious how you came about making that statement?

          I was just at the recent Scrum Gathering in Boulder, where
          around 50 ScrumMasters, Scrum Practitioners, and Scrum
          Trainers got together with Ken Schwaber, Jeff Sutherland,
          and many other Scrum thought leaders.

          I don't recall anyone talking about repositioning Scrum "more
          towards the project management aspects of software development
          projects." In fact I saw quite the opposite -- there was work
          around a wide variety of all aspects of software development,
          from product management, to organizational culture, to
          supporting Scrum through coaching and consulting, and yes,
          even to technical practices.

          In fact, I heard *more* talk about technical practices this
          year than in previous years, probably spurred on by Jeff
          Sutherland's reports of his experiences with "Type C" Scrums,
          and how they require a lot attention to good, continuous
          testing, integration, builds and release practices.

          Scrum and XP will always be "competitors" in the sense that
          each is a specific collection of practices and strategies as
          a starting point. But each is also intended to be an adaptive
          process, and XP practices often fit well with Scrum practices,
          and vice versa. Scrum is less inclusive and prescriptive in
          its practices, specifically engineering practices, than XP,
          but I don't think that implies they are not intended to be
          part of Scrum (or an implementation of Scrum).

          I think project management is a hot topic in the entire agile
          community right now, as agile continues to expand to address
          more areas of development and the development life cycle. So
          I think we see a lot of project management-related postings
          on the list, but I'm not seeing that as some sort of shift in
          emphasis in Scrum or a specialization on just that aspect of
          development. At least not with the practitioners I meet.

          Regards,
          Paul
          -----
          Paul Hodgetts -- CEO, Coach, Trainer, Consultant
          Agile Logic -- www.agilelogic.com
          Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
          Complete solutions for adopting agile processes, Scrum and XP.
        • Dymond, Robin
          To further muddy the waters.... I think software development teams need both Scrum and XP, and Theory of Constraints, and Lean Thinking, and.... Software
          Message 4 of 26 , Nov 30, 2005
          • 0 Attachment
            To further muddy the waters....

            I think software development teams need both Scrum and XP, and Theory of
            Constraints, and Lean Thinking, and....

            Software development methods that are adaptive instead of prescriptive
            are still new, and are just beginning to gain visibility (let alone
            implementation) in large organizations. There is much left to do in this
            space, and some smart insightful people have figured out some very
            effective ideas, setting beacons in the fog for the rest of us. However
            we still have a long ways to go before we can say we have a complete
            body of knowledge.

            From my perspective, XP is the most advanced of the Agile methods in
            terms of its practices. It is also the hardest to adopt because of all
            the personal and organization behaviors that need to change. Scrum is
            only organizational, and therefore is a little easier for transitioning
            teams. Scrum also is complementary to XP software engineering practices,
            these can be adopted over time as the team modifies their skills and
            behaviors.

            Introducing XP engineering practices without Agile management practice,
            either scrum or XP, usually has negative consequences, as it adds more
            work to a team, without providing either motivation or recognition of
            the value of the change. The teams will usually reject the practices,
            and say XP doesn't work for them.

            If you fix the inputs to the team - the prioritized backlog, iterations,
            delivering value, then you have an environment to introduce the
            downstream processes such as TDD.

            Cheers,
            Robin Dymond
            Conclusive Consulting, Inc.

            -----Original Message-----
            From: scrumdevelopment@yahoogroups.com
            [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Paul Hodgetts
            Sent: Wednesday, November 30, 2005 1:42 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] (unknown)


            Ashraf Al Shafaki wrote:

            > With the growing popularity of XP, Scurm has repositioned
            > itself now more towards the project management aspects of
            > software development projects in order to fit itself in the >
            technosphere as a complement to XP rather than a competitor > to it.

            I'm kinda curious how you came about making that statement?

            I was just at the recent Scrum Gathering in Boulder, where around 50
            ScrumMasters, Scrum Practitioners, and Scrum Trainers got together with
            Ken Schwaber, Jeff Sutherland, and many other Scrum thought leaders.

            I don't recall anyone talking about repositioning Scrum "more towards
            the project management aspects of software development projects." In
            fact I saw quite the opposite -- there was work around a wide variety of
            all aspects of software development, from product management, to
            organizational culture, to supporting Scrum through coaching and
            consulting, and yes, even to technical practices.

            In fact, I heard *more* talk about technical practices this year than in
            previous years, probably spurred on by Jeff Sutherland's reports of his
            experiences with "Type C" Scrums, and how they require a lot attention
            to good, continuous testing, integration, builds and release practices.

            Scrum and XP will always be "competitors" in the sense that each is a
            specific collection of practices and strategies as a starting point.
            But each is also intended to be an adaptive process, and XP practices
            often fit well with Scrum practices, and vice versa. Scrum is less
            inclusive and prescriptive in its practices, specifically engineering
            practices, than XP, but I don't think that implies they are not intended
            to be part of Scrum (or an implementation of Scrum).

            I think project management is a hot topic in the entire agile community
            right now, as agile continues to expand to address more areas of
            development and the development life cycle. So I think we see a lot of
            project management-related postings on the list, but I'm not seeing that
            as some sort of shift in emphasis in Scrum or a specialization on just
            that aspect of development. At least not with the practitioners I meet.

            Regards,
            Paul
            -----
            Paul Hodgetts -- CEO, Coach, Trainer, Consultant
            Agile Logic -- www.agilelogic.com
            Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP Complete
            solutions for adopting agile processes, Scrum and XP.




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







            The information contained in this e-mail is confidential and/or proprietary
            to Capital One and/or its affiliates. The information transmitted herewith
            is intended only for use by the individual or entity to which it is
            addressed. If the reader of this message is not the intended recipient,
            you are hereby notified that any review, retransmission, dissemination,
            distribution, copying or other use of, or taking of any action in reliance
            upon this information is strictly prohibited. If you have received this
            communication in error, please contact the sender and delete the material
            from your computer.
          • Steven Gordon
            As long as we are muddying... Because the agile software development approaches are non-prescriptive and recognize that every project and context is different,
            Message 5 of 26 , Nov 30, 2005
            • 0 Attachment
              As long as we are muddying...
               
              Because the agile software development approaches are non-prescriptive and recognize that every project and context is different, I believe there can never be a "complete body of knowledge".
               
              I find this belief to be liberating - there can be no silver bullet or definitive answer, so just try to apply the agile principles as best as you can and keep learning.  We recognize software development is a technical art, and the more colors on your palette and experience (yours and other's) to draw on, the more effective you can be.
               
              Steven Gordon

               
              On 11/30/05, Dymond, Robin <robin.dymond@...> wrote:
              To further muddy the waters....

              I think software development teams need both Scrum and XP, and Theory of
              Constraints, and Lean Thinking, and....

              Software development methods that are adaptive instead of prescriptive
              are still new, and are just beginning to gain visibility (let alone
              implementation) in large organizations. There is much left to do in this
              space, and some smart insightful people have figured out some very
              effective ideas, setting beacons in the fog for the rest of us. However
              we still have a long ways to go before we can say we have a complete
              body of knowledge.

              From my perspective, XP is the most advanced of the Agile methods in
              terms of its practices. It is also the hardest to adopt because of all
              the personal and organization behaviors that need to change. Scrum is
              only organizational, and therefore is a little easier for transitioning
              teams. Scrum also is complementary to XP software engineering practices,
              these can be adopted over time as the team modifies their skills and
              behaviors.

              Introducing XP engineering practices without Agile management practice,
              either scrum or XP, usually has negative consequences, as it adds more
              work to a team, without providing either motivation or recognition of
              the value of the change. The teams will usually reject the practices,
              and say XP doesn't work for them.

              If you fix the inputs to the team - the prioritized backlog, iterations,
              delivering value, then you have an environment to introduce the
              downstream processes such as TDD.

              Cheers,
              Robin Dymond
              Conclusive Consulting, Inc.


            • Ron Jeffries
              ... Do you have in mind a few interesting topics where there /is/ a complete body of knowledge? Ron Jeffries www.XProgramming.com In programming, do, or undo.
              Message 6 of 26 , Nov 30, 2005
              • 0 Attachment
                On Wednesday, November 30, 2005, at 8:08:08 PM, Steven Gordon wrote:

                > Because the agile software development approaches are non-prescriptive and
                > recognize that every project and context is different, I believe there can
                > never be a "complete body of knowledge".

                Do you have in mind a few interesting topics where there /is/ a
                complete body of knowledge?

                Ron Jeffries
                www.XProgramming.com
                In programming, do, or undo. There is always try. --Yoda
              • Ashraf Al Shafaki
                http://www.controlchaos.com/about/xp.php
                Message 7 of 26 , Nov 30, 2005
                • 0 Attachment
                  http://www.controlchaos.com/about/xp.php

                  On 11/30/05, Paul Hodgetts <phodgetts@...> wrote:
                  Ashraf Al Shafaki wrote:

                  > With the growing popularity of XP, Scurm has repositioned
                  > itself now more towards the project management aspects of
                  > software development projects in order to fit itself in the
                  > technosphere as a complement to XP rather than a competitor
                  > to it.

                  I'm kinda curious how you came about making that statement?

                  I was just at the recent Scrum Gathering in Boulder, where
                  around 50 ScrumMasters, Scrum Practitioners, and Scrum
                  Trainers got together with Ken Schwaber, Jeff Sutherland,
                  and many other Scrum thought leaders.

                  I don't recall anyone talking about repositioning Scrum "more
                  towards the project management aspects of software development
                  projects."  In fact I saw quite the opposite -- there was work
                  around a wide variety of all aspects of software development,
                  from product management, to organizational culture, to
                  supporting Scrum through coaching and consulting, and yes,
                  even to technical practices.

                  In fact, I heard *more* talk about technical practices this
                  year than in previous years, probably spurred on by Jeff
                  Sutherland's reports of his experiences with "Type C" Scrums,
                  and how they require a lot attention to good, continuous
                  testing, integration, builds and release practices.

                  Scrum and XP will always be "competitors" in the sense that
                  each is a specific collection of practices and strategies as
                  a starting point.  But each is also intended to be an adaptive
                  process, and XP practices often fit well with Scrum practices,
                  and vice versa.  Scrum is less inclusive and prescriptive in
                  its practices, specifically engineering practices, than XP,
                  but I don't think that implies they are not intended to be
                  part of Scrum (or an implementation of Scrum).

                  I think project management is a hot topic in the entire agile
                  community right now, as agile continues to expand to address
                  more areas of development and the development life cycle.  So
                  I think we see a lot of project management-related postings
                  on the list, but I'm not seeing that as some sort of shift in
                  emphasis in Scrum or a specialization on just that aspect of
                  development.  At least not with the practitioners I meet.

                  Regards,
                  Paul
                  -----
                  Paul Hodgetts -- CEO, Coach, Trainer, Consultant
                  Agile Logic -- www.agilelogic.com
                  Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
                  Complete solutions for adopting agile processes, Scrum and XP.



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




                  YAHOO! GROUPS LINKS




                • Steven Gordon
                  Good point. In agile software development, it is just more clear that a complete body of knowledge is unachievable.
                  Message 8 of 26 , Dec 1, 2005
                  • 0 Attachment
                    Good point.
                     
                    In agile software development, it is just more clear that a complete body of knowledge is unachievable.

                     
                    On 11/30/05, Ron Jeffries <ronjeffries@...> wrote:
                    On Wednesday, November 30, 2005, at 8:08:08 PM, Steven Gordon wrote:

                    > Because the agile software development approaches are non-prescriptive and
                    > recognize that every project and context is different, I believe there can
                    > never be a "complete body of knowledge".

                    Do you have in mind a few interesting topics where there /is/ a
                    complete body of knowledge?

                    Ron Jeffries
                    www.XProgramming.com
                    In programming, do, or undo. There is always try.  --Yoda
                  • woynam
                    I will keep repeating this until the day I die. They are *not* XP engineering practices. The practices existed before XP, were used by many of us who were not
                    Message 9 of 26 , Dec 1, 2005
                    • 0 Attachment
                      I will keep repeating this until the day I die.

                      They are *not* XP engineering practices.

                      The practices existed before XP, were used by many of us who were not
                      "doing" XP (but were doing agile or pre-agile), and can be used
                      independently of XP.

                      XP recognized the existing best practices, relalized that one would
                      gain the most by utilizing them as a full set of complimentary
                      practices, and developed the best marketing department. :-)

                      Mark


                      --- In scrumdevelopment@yahoogroups.com, "Dymond, Robin"
                      <robin.dymond@c...> wrote:
                      >
                      > To further muddy the waters....
                      >
                      > I think software development teams need both Scrum and XP, and Theory of
                      > Constraints, and Lean Thinking, and....
                      >
                      > Software development methods that are adaptive instead of prescriptive
                      > are still new, and are just beginning to gain visibility (let alone
                      > implementation) in large organizations. There is much left to do in this
                      > space, and some smart insightful people have figured out some very
                      > effective ideas, setting beacons in the fog for the rest of us. However
                      > we still have a long ways to go before we can say we have a complete
                      > body of knowledge.
                      >
                      > From my perspective, XP is the most advanced of the Agile methods in
                      > terms of its practices. It is also the hardest to adopt because of all
                      > the personal and organization behaviors that need to change. Scrum is
                      > only organizational, and therefore is a little easier for transitioning
                      > teams. Scrum also is complementary to XP software engineering practices,
                      > these can be adopted over time as the team modifies their skills and
                      > behaviors.
                      >
                      > Introducing XP engineering practices without Agile management practice,
                      > either scrum or XP, usually has negative consequences, as it adds more
                      > work to a team, without providing either motivation or recognition of
                      > the value of the change. The teams will usually reject the practices,
                      > and say XP doesn't work for them.
                      >
                      > If you fix the inputs to the team - the prioritized backlog, iterations,
                      > delivering value, then you have an environment to introduce the
                      > downstream processes such as TDD.
                      >
                      > Cheers,
                      > Robin Dymond
                      > Conclusive Consulting, Inc.
                      >
                      > -----Original Message-----
                      > From: scrumdevelopment@yahoogroups.com
                      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Paul Hodgetts
                      > Sent: Wednesday, November 30, 2005 1:42 PM
                      > To: scrumdevelopment@yahoogroups.com
                      > Subject: Re: [scrumdevelopment] (unknown)
                      >
                      >
                      > Ashraf Al Shafaki wrote:
                      >
                      > > With the growing popularity of XP, Scurm has repositioned
                      > > itself now more towards the project management aspects of
                      > > software development projects in order to fit itself in the >
                      > technosphere as a complement to XP rather than a competitor > to it.
                      >
                      > I'm kinda curious how you came about making that statement?
                      >
                      > I was just at the recent Scrum Gathering in Boulder, where around 50
                      > ScrumMasters, Scrum Practitioners, and Scrum Trainers got together with
                      > Ken Schwaber, Jeff Sutherland, and many other Scrum thought leaders.
                      >
                      > I don't recall anyone talking about repositioning Scrum "more towards
                      > the project management aspects of software development projects." In
                      > fact I saw quite the opposite -- there was work around a wide variety of
                      > all aspects of software development, from product management, to
                      > organizational culture, to supporting Scrum through coaching and
                      > consulting, and yes, even to technical practices.
                      >
                      > In fact, I heard *more* talk about technical practices this year than in
                      > previous years, probably spurred on by Jeff Sutherland's reports of his
                      > experiences with "Type C" Scrums, and how they require a lot attention
                      > to good, continuous testing, integration, builds and release practices.
                      >
                      > Scrum and XP will always be "competitors" in the sense that each is a
                      > specific collection of practices and strategies as a starting point.
                      > But each is also intended to be an adaptive process, and XP practices
                      > often fit well with Scrum practices, and vice versa. Scrum is less
                      > inclusive and prescriptive in its practices, specifically engineering
                      > practices, than XP, but I don't think that implies they are not intended
                      > to be part of Scrum (or an implementation of Scrum).
                      >
                      > I think project management is a hot topic in the entire agile community
                      > right now, as agile continues to expand to address more areas of
                      > development and the development life cycle. So I think we see a lot of
                      > project management-related postings on the list, but I'm not seeing that
                      > as some sort of shift in emphasis in Scrum or a specialization on just
                      > that aspect of development. At least not with the practitioners I meet.
                      >
                      > Regards,
                      > Paul
                      > -----
                      > Paul Hodgetts -- CEO, Coach, Trainer, Consultant
                      > Agile Logic -- www.agilelogic.com
                      > Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP Complete
                      > solutions for adopting agile processes, Scrum and XP.
                      >
                      >
                      >
                      >
                      > To Post a message, send it to: scrumdevelopment@e...
                      > To Unsubscribe, send a blank message to:
                      > scrumdevelopment-unsubscribe@e...
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      > The information contained in this e-mail is confidential and/or
                      proprietary
                      > to Capital One and/or its affiliates. The information transmitted
                      herewith
                      > is intended only for use by the individual or entity to which it is
                      > addressed. If the reader of this message is not the intended
                      recipient,
                      > you are hereby notified that any review, retransmission, dissemination,
                      > distribution, copying or other use of, or taking of any action in
                      reliance
                      > upon this information is strictly prohibited. If you have received this
                      > communication in error, please contact the sender and delete the
                      material
                      > from your computer.
                      >
                    • Ron Jeffries
                      ... Why is this important to you? Ron Jeffries www.XProgramming.com Yesterday s code should be as good as we could make it yesterday. The fact that we know
                      Message 10 of 26 , Dec 1, 2005
                      • 0 Attachment
                        On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:

                        > I will keep repeating this until the day I die.

                        > They are *not* XP engineering practices.

                        Why is this important to you?

                        Ron Jeffries
                        www.XProgramming.com
                        Yesterday's code should be as good as we could make it yesterday.
                        The fact that we know more today, and are more capable today,
                        is good news about today, not bad news about yesterday.
                      • Jef L Newsom
                        I was wondering the same thing. Is there a concern that the brand diminishes the value somehow? The simple fact is that they *are* XP engineering practices,
                        Message 11 of 26 , Dec 1, 2005
                        • 0 Attachment
                          I was wondering the same thing. Is there a concern that the brand
                          diminishes the value somehow? The simple fact is that they *are* XP
                          engineering practices, since XP brands them as such, "The engineering
                          practices that compose XP." And they *are* just engineering practices,
                          too. I personally don't care what they're called -- they're good tools
                          to have in your box.

                          Jef

                          JOEY: ... Go to China. Eat Chinese food.
                          CHANDLER: Course there, they just call it "food."


                          -----Original Message-----
                          From: scrumdevelopment@yahoogroups.com
                          [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                          Sent: Thursday, December 01, 2005 11:36 AM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] Re: (unknown)

                          On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:

                          > I will keep repeating this until the day I die.

                          > They are *not* XP engineering practices.

                          Why is this important to you?

                          Ron Jeffries
                          www.XProgramming.com
                          Yesterday's code should be as good as we could make it yesterday.
                          The fact that we know more today, and are more capable today,
                          is good news about today, not bad news about yesterday.



                          To Post a message, send it to: scrumdevelopment@...
                          To Unsubscribe, send a blank message to:
                          scrumdevelopment-unsubscribe@...
                          Yahoo! Groups Links
                        • Tobias Mayer
                          I care. Because doing XP is a big turn off to many people; often, exactly because of all the hype. But unit testing, or adopting test driven development,
                          Message 12 of 26 , Dec 1, 2005
                          • 0 Attachment
                            I care.  Because "doing XP" is a big turn off to many people; often, exactly because of all the hype.  But unit testing, or adopting test driven development, or automating the build process, or improving one's refactoring practices (etc.) well, those things usually make sense to people - and they are willing to do them - adopting XP a slice at a time, as it were.  So yes, it is important for developers to know that these practices are older than XP, that they preceded the branding.  That way they can be discussed on their own merits.  Don't throw away history for the sake of marketing.
                            Tobias (not a brand fan)
                             

                            Jef L Newsom <jef@...> wrote:
                            I was wondering the same thing. Is there a concern that the brand
                            diminishes the value somehow? The simple fact is that they *are* XP
                            engineering practices, since XP brands them as such, "The engineering
                            practices that compose XP." And they *are* just engineering practices,
                            too. I personally don't care what they're called -- they're good tools
                            to have in your box.

                            Jef

                            JOEY: ... Go to China. Eat Chinese food.
                            CHANDLER: Course there, they just call it "food."


                            -----Original Message-----
                            From: scrumdevelopment@yahoogroups.com
                            [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                            Sent: Thursday, December 01, 2005 11:36 AM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] Re: (unknown)

                            On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:

                            > I will keep repeating this until the day I die.

                            >   They are *not* XP engineering practices.

                            Why is this important to you?

                            Ron Jeffries
                            www.XProgramming.com
                            Yesterday's code should be as good as we could make it yesterday.
                            The fact that we know more today, and are more capable today,
                            is good news about today, not bad news about yesterday.



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






                          • woynam
                            Because in many organizations, if you mention the word XP , you ll have the door shut in your face. If you talk about utilizing proven engineering practices,
                            Message 13 of 26 , Dec 1, 2005
                            • 0 Attachment
                              Because in many organizations, if you mention the word "XP", you'll
                              have the door shut in your face.

                              If you talk about utilizing proven engineering practices, possibly
                              adopted piecemeal when necessary, you may be allowed to continue talking.

                              Mark

                              --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                              <ronjeffries@X...> wrote:
                              >
                              > On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:
                              >
                              > > I will keep repeating this until the day I die.
                              >
                              > > They are *not* XP engineering practices.
                              >
                              > Why is this important to you?
                              >
                              > Ron Jeffries
                              > www.XProgramming.com
                              > Yesterday's code should be as good as we could make it yesterday.
                              > The fact that we know more today, and are more capable today,
                              > is good news about today, not bad news about yesterday.
                              >
                            • Stephen J. Bobick
                              ... Maybe because they associate XP with catastrophic destruction and ashes (but no Phoenix). I wonder where they would get such an idea from? ;-) -- S
                              Message 14 of 26 , Dec 1, 2005
                              • 0 Attachment
                                >From: woynam <woyna@...>
                                >Because in many organizations, if you mention the word "XP", you'll
                                >have the door shut in your face.

                                Maybe because they associate "XP" with "catastrophic" destruction and "ashes" (but no Phoenix).

                                I wonder where they would get such an idea from?

                                ;-)

                                -- S
                              • Jef L Newsom
                                It s dysfunctional all the way down in some organizations. Refactoring == No forethought Pair Programming == Half-productive || Incompetent when solo
                                Message 15 of 26 , Dec 1, 2005
                                • 0 Attachment
                                  It's dysfunctional all the way down in some organizations.

                                  Refactoring == No forethought
                                  Pair Programming == Half-productive || Incompetent when solo
                                  Collective Ownership == No individual accountability
                                  Test-driven design == cowboy code slinger
                                  ...

                                  Either way, it's a lot of work.


                                  -----Original Message-----
                                  From: scrumdevelopment@yahoogroups.com
                                  [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of woynam
                                  Sent: Thursday, December 01, 2005 2:24 PM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: [scrumdevelopment] Re: (unknown)


                                  Because in many organizations, if you mention the word "XP", you'll
                                  have the door shut in your face.

                                  If you talk about utilizing proven engineering practices, possibly
                                  adopted piecemeal when necessary, you may be allowed to continue
                                  talking.

                                  Mark

                                  --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                  <ronjeffries@X...> wrote:
                                  >
                                  > On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:
                                  >
                                  > > I will keep repeating this until the day I die.
                                  >
                                  > > They are *not* XP engineering practices.
                                  >
                                  > Why is this important to you?
                                  >
                                  > Ron Jeffries
                                  > www.XProgramming.com
                                  > Yesterday's code should be as good as we could make it yesterday.
                                  > The fact that we know more today, and are more capable today,
                                  > is good news about today, not bad news about yesterday.
                                  >







                                  To Post a message, send it to: scrumdevelopment@...
                                  To Unsubscribe, send a blank message to:
                                  scrumdevelopment-unsubscribe@...
                                  Yahoo! Groups Links
                                • Ron Jeffries
                                  ... I don t know, because Tobias, who introduced the term, has just come out against XP, while I, who actually do support XP, suggested that the term wasn t
                                  Message 16 of 26 , Dec 1, 2005
                                  • 0 Attachment
                                    On Thursday, December 1, 2005, at 3:30:43 PM, Stephen J. Bobick wrote:

                                    >>From: woynam <woyna@...>
                                    >>Because in many organizations, if you mention the word "XP", you'll
                                    >>have the door shut in your face.

                                    > Maybe because they associate "XP" with "catastrophic" destruction and "ashes" (but no Phoenix).

                                    > I wonder where they would get such an idea from?

                                    I don't know, because Tobias, who introduced the term, has just
                                    come out against XP, while I, who actually do support XP, suggested
                                    that the term wasn't ideal for most listeners.

                                    Most peculiar, Mama.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Hope is not a strategy. -- Michael Henos
                                  • Tobias Mayer
                                    Embrace paradox. T. Ron Jeffries wrote: ... I don t know, because Tobias, who introduced the term, has just come out against XP,
                                    Message 17 of 26 , Dec 1, 2005
                                    • 0 Attachment
                                      Embrace paradox.
                                      T.

                                      Ron Jeffries <ronjeffries@...> wrote:
                                      On Thursday, December 1, 2005, at 3:30:43 PM, Stephen J. Bobick wrote:

                                      >>From: woynam <woyna@...>
                                      >>Because in many organizations, if you mention the word "XP", you'll
                                      >>have the door shut in your face.

                                      > Maybe because they associate "XP" with "catastrophic" destruction and "ashes" (but no Phoenix).

                                      > I wonder where they would get such an idea from?

                                      I don't know, because Tobias, who introduced the term, has just
                                      come out against XP, while I, who actually do support XP, suggested
                                      that the term wasn't ideal for most listeners.

                                      Most peculiar, Mama.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      Hope is not a strategy. -- Michael Henos


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



                                    • Ron Jeffries
                                      ... Look, two ducks! Ron Jeffries www.XProgramming.com Thousands of years ago, the first man discovered how to make fire. He was probably burned at the stake
                                      Message 18 of 26 , Dec 1, 2005
                                      • 0 Attachment
                                        On Thursday, December 1, 2005, at 6:06:02 PM, Tobias Mayer wrote:

                                        > Embrace paradox.

                                        Look, two ducks!

                                        Ron Jeffries
                                        www.XProgramming.com
                                        Thousands of years ago, the first man discovered how to make fire.
                                        He was probably burned at the stake he had taught his brothers to
                                        light - Howard Roark (The Fountainhead, Ayn Rand)
                                      • kipkruide
                                        ... wrote: Solution seems simple then does it not, don t use the term xp, after all it is the results that count. Though in my peculiar world of humour it
                                        Message 19 of 26 , Dec 2, 2005
                                        • 0 Attachment
                                          --- In scrumdevelopment@yahoogroups.com, Tobias Mayer <tobyanon@y...>
                                          wrote:

                                          Solution seems simple then does it not, don't use the term xp, after
                                          all it is the results that count.

                                          Though in my peculiar world of humour it would be fun to tell the
                                          execs they've been doing xp for the last year, just to see the look on
                                          their faces.

                                          >
                                          > I care. Because "doing XP" is a big turn off to many people; often,
                                          exactly because of all the hype. But unit testing, or adopting test
                                          driven development, or automating the build process, or improving
                                          one's refactoring practices (etc.) well, those things usually make
                                          sense to people - and they are willing to do them - adopting XP a
                                          slice at a time, as it were. So yes, it is important for developers
                                          to know that these practices are older than XP, that they preceded the
                                          branding. That way they can be discussed on their own merits. Don't
                                          throw away history for the sake of marketing.
                                          > Tobias (not a brand fan)
                                          >
                                          >
                                          > Jef L Newsom <jef@i...> wrote:
                                          > I was wondering the same thing. Is there a concern that the brand
                                          > diminishes the value somehow? The simple fact is that they *are* XP
                                          > engineering practices, since XP brands them as such, "The engineering
                                          > practices that compose XP." And they *are* just engineering practices,
                                          > too. I personally don't care what they're called -- they're good tools
                                          > to have in your box.
                                          >
                                          > Jef
                                          >
                                          > JOEY: ... Go to China. Eat Chinese food.
                                          > CHANDLER: Course there, they just call it "food."
                                          >
                                          >
                                          > -----Original Message-----
                                          > From: scrumdevelopment@yahoogroups.com
                                          > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                                          > Sent: Thursday, December 01, 2005 11:36 AM
                                          > To: scrumdevelopment@yahoogroups.com
                                          > Subject: Re: [scrumdevelopment] Re: (unknown)
                                          >
                                          > On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:
                                          >
                                          > > I will keep repeating this until the day I die.
                                          >
                                          > > They are *not* XP engineering practices.
                                          >
                                          > Why is this important to you?
                                          >
                                          > Ron Jeffries
                                          > www.XProgramming.com
                                          > Yesterday's code should be as good as we could make it yesterday.
                                          > The fact that we know more today, and are more capable today,
                                          > is good news about today, not bad news about yesterday.
                                          >
                                          >
                                          >
                                          > To Post a message, send it to: scrumdevelopment@e...
                                          > To Unsubscribe, send a blank message to:
                                          > scrumdevelopment-unsubscribe@e...
                                          > Yahoo! Groups Links
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          > To Post a message, send it to: scrumdevelopment@e...
                                          > To Unsubscribe, send a blank message to:
                                          scrumdevelopment-unsubscribe@e...
                                          >
                                          >
                                          >
                                          > SPONSORED LINKS
                                          > Scrum
                                          >
                                          > ---------------------------------
                                          > YAHOO! GROUPS LINKS
                                          >
                                          >
                                          > Visit your group "scrumdevelopment" on the web.
                                          >
                                          > To unsubscribe from this group, send an email to:
                                          > scrumdevelopment-unsubscribe@yahoogroups.com
                                          >
                                          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                                          Service.
                                          >
                                          >
                                          > ---------------------------------
                                          >
                                        • Steven Gordon
                                          I like to use the term agile software development. It avoids both the turn offs and brand name issues. It also affords a little more freedom to adapt to the
                                          Message 20 of 26 , Dec 2, 2005
                                          • 0 Attachment
                                            I like to use the term agile software development.
                                             
                                            It avoids both the turn offs and brand name issues.  It also affords a little more freedom to adapt to the specific project and cultural context.
                                             
                                            I still acknowledging borrowing whatever makes sense in any paricular situation from XP, Scrum, Lean, RAD, MDA, etc. (even if they borrowed it from something else).

                                             
                                            On 12/2/05, kipkruide <nlv14041@...> wrote:
                                            --- In scrumdevelopment@yahoogroups.com, Tobias Mayer < tobyanon@y...>
                                            wrote:

                                            Solution seems simple then does it not, don't use the term xp, after
                                            all it is the results that count.

                                            Though in my peculiar world of humour it would be fun to tell the
                                            execs they've been doing xp for the last year, just to see the look on
                                            their faces.

                                            >
                                            > I care.  Because "doing XP" is a big turn off to many people; often,
                                            exactly because of all the hype.  But unit testing, or adopting test
                                            driven development, or automating the build process, or improving
                                            one's refactoring practices (etc.) well, those things usually make
                                            sense to people - and they are willing to do them - adopting XP a
                                            slice at a time, as it were.  So yes, it is important for developers
                                            to know that these practices are older than XP, that they preceded the
                                            branding.  That way they can be discussed on their own merits.  Don't
                                            throw away history for the sake of marketing.
                                            > Tobias (not a brand fan)
                                            >
                                            >
                                            > Jef L Newsom <jef@i...> wrote:
                                            > I was wondering the same thing. Is there a concern that the brand
                                            > diminishes the value somehow? The simple fact is that they *are* XP
                                            > engineering practices, since XP brands them as such, "The engineering
                                            > practices that compose XP." And they *are* just engineering practices,
                                            > too. I personally don't care what they're called -- they're good tools
                                            > to have in your box.
                                            >
                                            > Jef
                                            >
                                            > JOEY: ... Go to China. Eat Chinese food.
                                            > CHANDLER: Course there, they just call it "food."
                                            >
                                            >
                                            > -----Original Message-----
                                            > From: scrumdevelopment@yahoogroups.com
                                            > [mailto:scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                                            > Sent: Thursday, December 01, 2005 11:36 AM
                                            > To: scrumdevelopment@yahoogroups.com
                                            > Subject: Re: [scrumdevelopment] Re: (unknown)
                                            >
                                            > On Thursday, December 1, 2005, at 10:34:06 AM, woynam wrote:
                                            >
                                            > > I will keep repeating this until the day I die.
                                            >
                                            > >   They are *not* XP engineering practices.
                                            >
                                            > Why is this important to you?
                                            >
                                            > Ron Jeffries
                                            > www.XProgramming.com
                                            > Yesterday's code should be as good as we could make it yesterday.
                                            > The fact that we know more today, and are more capable today,
                                            > is good news about today, not bad news about yesterday.

                                          • Ilja Preuss
                                            ... To me, a practice being an XP practice just means that it is part of what XP teams do. It doesn t mean that the practice didn t exist before XP. What it
                                            Message 21 of 26 , Dec 2, 2005
                                            • 0 Attachment
                                              scrumdevelopment@yahoogroups.com wrote:
                                              > I care. Because "doing XP" is a big turn off to many people; often,
                                              > exactly because of all the hype. But unit testing, or adopting test
                                              > driven development, or automating the build process, or improving
                                              > one's refactoring practices (etc.) well, those things usually make
                                              > sense to people - and they are willing to do them - adopting XP a
                                              > slice at a time, as it were. So yes, it is important for developers
                                              > to know that these practices are older than XP, that they preceded
                                              > the branding. That way they can be discussed on their own merits.
                                              > Don't throw away history for the sake of marketing. Tobias (not a
                                              > brand fan)

                                              To me, a practice being an XP practice just means that it is part of what XP
                                              teams do. It doesn't mean that the practice didn't exist before XP.

                                              What it might well mean is that the practice was far less well known before
                                              it became part of the "XP brand", that it therefore gets connected to XP by
                                              many people. Frankly, I'm not sure that a mostly unknown practice is less
                                              hard to propagate than a hyped practice.

                                              With XP, people don't like to try Pair Programming because it's part of the
                                              "XP hype". I'd wager that without XP the same people wouldn't want to try it
                                              because they'd never have heart about someone doing it at all. I'd even
                                              wager that in many cases the *real* reason for the rejection of the practice
                                              is something else. Blaming XP might just hold you from addressing the real
                                              causes.

                                              Cheers, Ilja
                                            • Tobias Mayer
                                              ... A good point, and possibly true in many cases. However, the introduction of we should try pair-proramming because it is one of the 12 XP practices and we
                                              Message 22 of 26 , Dec 2, 2005
                                              • 0 Attachment
                                                Ilja wrote:
                                                > With XP, people don't like to try Pair Programming because it's part of the "XP hype". I'd wager that without XP the same people wouldn't want to try it because they'd never have heart about someone doing it at all. I'd even wager that in many cases the *real* reason for the rejection of the practice is something else. Blaming XP might just hold you from addressing the real causes.
                                                 
                                                A good point, and possibly true in many cases.  However, the introduction of "we should try pair-proramming because it is one of the 12 XP practices and we should be doing XP" (or words to that effect), is probably less useful than an aproach like: "let's remove these cubicle walls so we can communicate more effectively".
                                                 
                                                In my experience, a group of good developers in a shared workspace, will pair program, maybe not 8-hours a day, but enough of the time for it to be beneficial.  It is a natural way to work providing (and this is the key thing) that the culture around them supports - no, encourages risk and failure.  I believe a lot of the resistance to PP is pride, which of course stems from fear.  The fear is that you'll see I don't know something.  I'll be exposed.  My guard will be down, my bonus will be affected...
                                                 
                                                Creating a culture where failure is not only tolerated but celebrated is a better starting point, to my mind, than saying "let's do XP now".
                                                 
                                                Tobias


                                                Ilja Preuss <preuss@...> wrote:
                                                scrumdevelopment@yahoogroups.com wrote:
                                                > I care.  Because "doing XP" is a big turn off to many people; often,
                                                > exactly because of all the hype.  But unit testing, or adopting test
                                                > driven development, or automating the build process, or improving
                                                > one's refactoring practices (etc.) well, those things usually make
                                                > sense to people - and they are willing to do them - adopting XP a
                                                > slice at a time, as it were.  So yes, it is important for developers
                                                > to know that these practices are older than XP, that they preceded
                                                > the branding.  That way they can be discussed on their own merits.
                                                > Don't throw away history for the sake of marketing. Tobias (not a
                                                > brand fan)       

                                                To me, a practice being an XP practice just means that it is part of what XP
                                                teams do. It doesn't mean that the practice didn't exist before XP.

                                                What it might well mean is that the practice was far less well known before
                                                it became part of the "XP brand", that it therefore gets connected to XP by
                                                many people. Frankly, I'm not sure that a mostly unknown practice is less
                                                hard to propagate than a hyped practice.

                                                With XP, people don't like to try Pair Programming because it's part of the
                                                "XP hype". I'd wager that without XP the same people wouldn't want to try it
                                                because they'd never have heart about someone doing it at all. I'd even
                                                wager that in many cases the *real* reason for the rejection of the practice
                                                is something else. Blaming XP might just hold you from addressing the real
                                                causes.

                                                Cheers, Ilja


                                              • Greg Akins
                                                ... In my experience, a group of good developers in a shared workspace, will pair program, maybe not 8-hours a day, but enough of the time for it to be
                                                Message 23 of 26 , Dec 3, 2005
                                                • 0 Attachment


                                                  Tobias Mayer <tobyanon@...> wrote:
                                                  Ilja wrote:
                                                  >
                                                  In my experience, a group of good developers in a shared workspace, will pair program, maybe not 8-hours a day, but enough of the time for it to be beneficial.  It is a natural way to work providing (and this is the key thing) that the culture around them supports - no, encourages risk and failure.  I believe a lot of the resistance to PP is pride, which of course stems from fear.  The fear is that you'll see I don't know something.  I'll be exposed.  My guard will be down, my bonus will be affected...
                                                   
                                                  I would love to pair more... But have never been luck enough to be in a shop where anyone else is interested.  However, I find that if I'm just willing to ask other developers to help me work through certain tasks, they're always willing to sit with me for fairly long periods of time. 

                                                  My experience with that convinces me more that pair programming is a great direction.  Because in every case, I and the other programmer worked through issues more efficiently that either of us would have done individually.

                                                  Speaking to your point about fear and pride.  I think that removing the "pair" stigma, and working with developers that don't have "difficult" egos, combined with open offices and lots of communications makes pairing a natural progression for good programmers even if they don't realize they're doing it.
                                                • Ilja Preuss
                                                  ... Well, yes, of course. I just don t see how calling Pair Programming an XP practice could hold anyone from doing exactly that... Confused, Ilja
                                                  Message 24 of 26 , Dec 5, 2005
                                                  • 0 Attachment
                                                    > A good point, and possibly true in many cases. However, the
                                                    > introduction of "we should try pair-proramming because it is one of
                                                    > the 12 XP practices and we should be doing XP" (or words to that
                                                    > effect), is probably less useful than an aproach like: "let's remove
                                                    > these cubicle walls so we can communicate more effectively".

                                                    Well, yes, of course. I just don't see how calling Pair Programming an "XP
                                                    practice" could hold anyone from doing exactly that...

                                                    Confused, Ilja
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.