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

RE: [scrumdevelopment] (unknown)

Expand Messages
  • Ken Schwaber
    FDD is iterative, incremental but has trouble in most of the other areas. Give me a call tomorrow at 781 862-3224 and I can go over the rating system. Ken ...
    Message 1 of 26 , Jun 27, 2001
    • 0 Attachment
      FDD is iterative, incremental but has trouble in most of the other areas.
      Give me a call tomorrow at 781 862-3224 and I can go over the rating system.
      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/
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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.