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

Re: [XP] Recommendations for on-site TDD training?

Expand Messages
  • Ron Jeffries
    Hello, aalanatlas. On Monday, October 29, 2007, at 9:06:55 PM, you ... TDD isn t a jump. It s just one technique to learn and to begin to learn. I ve had
    Message 1 of 15 , Nov 1, 2007
    • 0 Attachment
      Hello, aalanatlas. On Monday, October 29, 2007, at 9:06:55 PM, you
      wrote:

      > So, I am asking those that have had positive experience with
      > commercially available TDD training to share their recommendations
      > with me, and I'm also asking the group at large whether it is sensible
      > to try to make the leap from Scrum directly to TDD, even one team at a
      > time.

      TDD isn't a jump. It's just one technique to learn and to begin to
      learn. I've had positive experiences teaching TDD with Chet ...
      you'll have to ask someone else whether our victXXXX students
      benefited, but I think they do. :)

      Ron Jeffries
      www.XProgramming.com
      You can observe a lot by watching. --Yogi Berra
    • geoffrey_slinker
      ... How do you view TDD as compared to Scrum? What is the role/purpose of Scrum? What is the role/purpose of TDD? Geoff
      Message 2 of 15 , Nov 1, 2007
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, "aalanatlas" <alanatat@...>
        wrote:
        >
        > Greetings,
        >
        > Our company has seen explosive, grassroots-driven adoption of Scrum
        > over the past three years or so. Now, a lot of teams are showing
        > interest in automated testing and TDD. There is great demand for some
        > TDD training here, and I am the lucky one tasked with finding a source
        > of some good quality on-site TDD training.
        >
        > So, I am asking those that have had positive experience with
        > commercially available TDD training to share their recommendations
        > with me, and I'm also asking the group at large whether it is sensible
        > to try to make the leap from Scrum directly to TDD, even one team at a
        > time.
        >
        > Thanks in advance for your replies.
        >

        How do you view TDD as compared to Scrum?
        What is the role/purpose of Scrum?
        What is the role/purpose of TDD?

        Geoff
      • Gary Brown
        ... Isn t that kinda like asking how do you like playing shortstop compared to the Super Bowl? GB.
        Message 3 of 15 , Nov 1, 2007
        • 0 Attachment
          Quoting geoffrey_slinker <geoffrey_slinker@...>:

          > --- In extremeprogramming@yahoogroups.com, "aalanatlas" <alanatat@...>
          > wrote:
          >>
          >> Greetings,
          >>
          >> Our company has seen explosive, grassroots-driven adoption of Scrum
          >> over the past three years or so. Now, a lot of teams are showing
          >> interest in automated testing and TDD. There is great demand for some
          >> TDD training here, and I am the lucky one tasked with finding a source
          >> of some good quality on-site TDD training.
          >>
          >> So, I am asking those that have had positive experience with
          >> commercially available TDD training to share their recommendations
          >> with me, and I'm also asking the group at large whether it is sensible
          >> to try to make the leap from Scrum directly to TDD, even one team at a
          >> time.
          >>
          >> Thanks in advance for your replies.
          >>
          >
          > How do you view TDD as compared to Scrum?
          > What is the role/purpose of Scrum?
          > What is the role/purpose of TDD?
          >
          > Geoff

          Isn't that kinda like asking how do you like playing shortstop
          compared to the Super Bowl?

          GB.
        • geoffrey_slinker
          ... source ... sensible ... at a ... I asked those questions because you asked how to make the leap from Scrum directly to TDD. To me it was like you were
          Message 4 of 15 , Nov 2, 2007
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, Gary Brown <glbrown@...> wrote:
            >
            > Quoting geoffrey_slinker <geoffrey_slinker@...>:
            >
            > > --- In extremeprogramming@yahoogroups.com, "aalanatlas" <alanatat@>
            > > wrote:
            > >>
            > >> Greetings,
            > >>
            > >> Our company has seen explosive, grassroots-driven adoption of Scrum
            > >> over the past three years or so. Now, a lot of teams are showing
            > >> interest in automated testing and TDD. There is great demand for some
            > >> TDD training here, and I am the lucky one tasked with finding a
            source
            > >> of some good quality on-site TDD training.
            > >>
            > >> So, I am asking those that have had positive experience with
            > >> commercially available TDD training to share their recommendations
            > >> with me, and I'm also asking the group at large whether it is
            sensible
            > >> to try to make the leap from Scrum directly to TDD, even one team
            at a
            > >> time.
            > >>
            > >> Thanks in advance for your replies.
            > >>
            > >
            > > How do you view TDD as compared to Scrum?
            > > What is the role/purpose of Scrum?
            > > What is the role/purpose of TDD?
            > >
            > > Geoff
            >
            > Isn't that kinda like asking how do you like playing shortstop
            > compared to the Super Bowl?
            >

            I asked those questions because you asked how to make the leap from
            Scrum directly to TDD. To me it was like you were saying that there is
            some kind of relationship between Scrum and TDD such that you could
            "leap over" some intermediate steps to go from Scrum to TDD.

            That is why I asked.

            Geoff
          • aalanatlas
            I view Scrum as a project management methodology that makes no demand on engineering practices. Strictly speaking, I could, if I were so inclined, fit lots of
            Message 5 of 15 , Nov 7, 2007
            • 0 Attachment
              I view Scrum as a project management methodology that makes no demand
              on engineering practices. Strictly speaking, I could, if I were so
              inclined, fit lots of tiny waterfall-style projects into a scrum
              framework and make it all work to some degree.

              TDD is, to the best of my understanding, a design and coding practice
              that is more aligned with Extreme Programming.

              It certainly seems to be the case that you get the best mileage by
              combining Scrum and some XP practices (maybe all), but there is value
              in separating Scrum and XP for teaching and adoption purposes.

              In our company, there are a lot of teams that have adopted Scrum. Many
              have adopted the XP practices of continuous integration and automated
              test to some degree, and there are some teams that want to take steps
              further towards learning and using XP engineering practices. That's
              where this inquiry came from.

              That's kind of my mental model. Did that answer the question?

              alan


              --- In extremeprogramming@yahoogroups.com, "geoffrey_slinker"
              <geoffrey_slinker@...> wrote:
              >
              > --- In extremeprogramming@yahoogroups.com, "aalanatlas" <alanatat@>
              > wrote:
              > >
              > > Greetings,
              > >
              > > Our company has seen explosive, grassroots-driven adoption of Scrum
              > > over the past three years or so. Now, a lot of teams are showing
              > > interest in automated testing and TDD. There is great demand for some
              > > TDD training here, and I am the lucky one tasked with finding a source
              > > of some good quality on-site TDD training.
              > >
              > > So, I am asking those that have had positive experience with
              > > commercially available TDD training to share their recommendations
              > > with me, and I'm also asking the group at large whether it is sensible
              > > to try to make the leap from Scrum directly to TDD, even one team at a
              > > time.
              > >
              > > Thanks in advance for your replies.
              > >
              >
              > How do you view TDD as compared to Scrum?
              > What is the role/purpose of Scrum?
              > What is the role/purpose of TDD?
              >
              > Geoff
              >
            • Steven Gordon
              Where are you located and what language(s) are you using?
              Message 6 of 15 , Nov 7, 2007
              • 0 Attachment
                Where are you located and what language(s) are you using?

                On Nov 7, 2007 1:48 PM, aalanatlas <alanatat@...> wrote:
                >
                >
                >
                >
                >
                >
                > I view Scrum as a project management methodology that makes no demand
                > on engineering practices. Strictly speaking, I could, if I were so
                > inclined, fit lots of tiny waterfall-style projects into a scrum
                > framework and make it all work to some degree.
                >
                > TDD is, to the best of my understanding, a design and coding practice
                > that is more aligned with Extreme Programming.
                >
                > It certainly seems to be the case that you get the best mileage by
                > combining Scrum and some XP practices (maybe all), but there is value
                > in separating Scrum and XP for teaching and adoption purposes.
                >
                > In our company, there are a lot of teams that have adopted Scrum. Many
                > have adopted the XP practices of continuous integration and automated
                > test to some degree, and there are some teams that want to take steps
                > further towards learning and using XP engineering practices. That's
                > where this inquiry came from.
                >
                > That's kind of my mental model. Did that answer the question?
                >
                > alan
                >
                > --- In extremeprogramming@yahoogroups.com, "geoffrey_slinker"
                > <geoffrey_slinker@...> wrote:
                > >
                > > --- In extremeprogramming@yahoogroups.com, "aalanatlas" <alanatat@>
                > > wrote:
                > > >
                > > > Greetings,
                > > >
                > > > Our company has seen explosive, grassroots-driven adoption of Scrum
                > > > over the past three years or so. Now, a lot of teams are showing
                > > > interest in automated testing and TDD. There is great demand for some
                > > > TDD training here, and I am the lucky one tasked with finding a source
                > > > of some good quality on-site TDD training.
                > > >
                > > > So, I am asking those that have had positive experience with
                > > > commercially available TDD training to share their recommendations
                > > > with me, and I'm also asking the group at large whether it is sensible
                > > > to try to make the leap from Scrum directly to TDD, even one team at a
                > > > time.
                > > >
                > > > Thanks in advance for your replies.
                > > >
                > >
                > > How do you view TDD as compared to Scrum?
                > > What is the role/purpose of Scrum?
                > > What is the role/purpose of TDD?
                > >
                > > Geoff
                > >
                >
                >
              • J. B. Rainsberger
                ... Alan, you re more likely to get answers from trainers than those-who-have-been-trained. Fair warning. I am such a trainer, and I m told I m pretty good. I
                Message 7 of 15 , Nov 9, 2007
                • 0 Attachment
                  aalanatlas wrote:

                  > So, I am asking those that have had positive experience with
                  > commercially available TDD training to share their recommendations
                  > with me, and I'm also asking the group at large whether it is sensible
                  > to try to make the leap from Scrum directly to TDD, even one team at a
                  > time.

                  Alan, you're more likely to get answers from trainers than
                  those-who-have-been-trained. Fair warning. I am such a trainer, and I'm
                  told I'm pretty good. I could easily a dozen excellent trainers, if
                  you'd like to tell me in private a little more about what you're looking
                  for. Another fair warning: I'll probably try to sell you something.

                  Take care.
                  --
                  J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                  Your guide to software craftsmanship
                  JUnit Recipes: Practical Methods for Programmer Testing
                  2005 Gordon Pask Award for contribution Agile Software Practice
                • Charlie Poole
                  Hi Alan, ... Yes. I fact, I view that as both the strong point of Scrum as well as the point where it sometimes fails. Scrum is a container for project
                  Message 8 of 15 , Nov 9, 2007
                  • 0 Attachment
                    Hi Alan,

                    > I view Scrum as a project management methodology that makes
                    > no demand on engineering practices. Strictly speaking, I
                    > could, if I were so inclined, fit lots of tiny
                    > waterfall-style projects into a scrum framework and make it
                    > all work to some degree.

                    Yes. I fact, I view that as both the strong point of Scrum as
                    well as the point where it sometimes fails. Scrum is a container
                    for project activities and - at least in my view - a very good
                    one. It is automatically calibrated to tell us how full the
                    container is at any one moment and whether the contents are
                    what we intended for the iteration.

                    It tells us nothing about how to fill the container - by design.

                    Some folks here disagree with me, I know, but I think that Scrum
                    can be used to manage mixed (i.e. software plus other stuff)
                    projects better than pure XP. And it turns out that even most
                    software projects are actually mixed.

                    > TDD is, to the best of my understanding, a design and coding
                    > practice that is more aligned with Extreme Programming.

                    I disagree, at least in part. TDD is strongly identified with
                    Extreme Programming for reason of its origins, usage and public
                    image. But it works quite well in many other environments and the
                    last two factors are beginning to change.

                    > It certainly seems to be the case that you get the best
                    > mileage by combining Scrum and some XP practices (maybe all),
                    > but there is value in separating Scrum and XP for teaching
                    > and adoption purposes.

                    Yes. Of course, I would prefer to see folks who start with TDD
                    move on to additional practices from XP, because those practices
                    have value in themselves and also multiply the effect of TDD.
                    But the fact that TDD is useful alone makes it a really good
                    choice as a start when introducing engineering practices
                    incrementally - if that's what you want to do.

                    Charlie

                    > In our company, there are a lot of teams that have adopted
                    > Scrum. Many have adopted the XP practices of continuous
                    > integration and automated test to some degree, and there are
                    > some teams that want to take steps further towards learning
                    > and using XP engineering practices. That's where this inquiry
                    > came from.
                    >
                    > That's kind of my mental model. Did that answer the question?
                    >
                    > alan
                    >
                    >
                    > --- In extremeprogramming@yahoogroups.com, "geoffrey_slinker"
                    > <geoffrey_slinker@...> wrote:
                    > >
                    > > --- In extremeprogramming@yahoogroups.com, "aalanatlas" <alanatat@>
                    > > wrote:
                    > > >
                    > > > Greetings,
                    > > >
                    > > > Our company has seen explosive, grassroots-driven
                    > adoption of Scrum
                    > > > over the past three years or so. Now, a lot of teams are showing
                    > > > interest in automated testing and TDD. There is great demand for
                    > > > some TDD training here, and I am the lucky one tasked
                    > with finding a
                    > > > source of some good quality on-site TDD training.
                    > > >
                    > > > So, I am asking those that have had positive experience with
                    > > > commercially available TDD training to share their
                    > recommendations
                    > > > with me, and I'm also asking the group at large whether it is
                    > > > sensible to try to make the leap from Scrum directly to TDD, even
                    > > > one team at a time.
                    > > >
                    > > > Thanks in advance for your replies.
                    > > >
                    > >
                    > > How do you view TDD as compared to Scrum?
                    > > What is the role/purpose of Scrum?
                    > > What is the role/purpose of TDD?
                    > >
                    > > Geoff
                    > >
                    >
                    >
                    >
                    >
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to:
                    > extremeprogramming-unsubscribe@...
                    >
                    > ad-free courtesy of objectmentor.com
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                  • Steven Gordon
                    ... I slightly disagree with this. One of Scrum s strengths is the practice of iterative reflection. The team should be taking responsibility for listening to
                    Message 9 of 15 , Nov 9, 2007
                    • 0 Attachment
                      On Nov 9, 2007 7:33 AM, Charlie Poole <xp@...> wrote:
                      >
                      > Hi Alan,
                      >
                      ...
                      >
                      > > It certainly seems to be the case that you get the best
                      > > mileage by combining Scrum and some XP practices (maybe all),
                      > > but there is value in separating Scrum and XP for teaching
                      > > and adoption purposes.
                      >
                      > Yes. Of course, I would prefer to see folks who start with TDD
                      > move on to additional practices from XP, because those practices
                      > have value in themselves and also multiply the effect of TDD.
                      > But the fact that TDD is useful alone makes it a really good
                      > choice as a start when introducing engineering practices
                      > incrementally - if that's what you want to do.

                      I slightly disagree with this.

                      One of Scrum's strengths is the practice of iterative reflection. The
                      team should be taking responsibility for listening to external
                      feedback and trying to improve its effectiveness by:
                      - reflecting on what its biggest problems are every iteration,
                      - deciding on one or two process modifications to try to address those
                      problems, and
                      - reflecting on whether those changes actually made things better or not.
                      Imposing TDD (or anything else) on the team undermines the team taking
                      responsibility for itself.

                      Whoever would be in the position to impose TDD should instead listen
                      to what each team thinks it needs to improve its effectiveness, and
                      then possibly suggest (or steer team conversation via insightful
                      questions to) whatever practice would be most helpful for that team at
                      that time. My experience is that TDD comes fairly early in the game,
                      but for some teams/contexts automated acceptance testing is a better
                      first step and for others continuous integration. It is critical for
                      sustained team buy-in that the practice being adopted at each point
                      visibly addresses the problems the team currently notices.

                      Steven Gordon


                      >
                      > Charlie
                      >
                    • Ron Jeffries
                      Hello, Steven. I don t think Charlie said to impose TDD. I think he said choice . R. ... Ron Jeffries www.XProgramming.com In programming, do, or undo.
                      Message 10 of 15 , Nov 9, 2007
                      • 0 Attachment
                        Hello, Steven. I don't think Charlie said to "impose" TDD. I think
                        he said "choice".

                        R.

                        On Friday, November 9, 2007, at 10:23:15 AM, you wrote:

                        >> Yes. Of course, I would prefer to see folks who start with TDD
                        >> move on to additional practices from XP, because those practices
                        >> have value in themselves and also multiply the effect of TDD.
                        >> But the fact that TDD is useful alone makes it a really good
                        >> choice as a start when introducing engineering practices
                        >> incrementally - if that's what you want to do.

                        > I slightly disagree with this.

                        > One of Scrum's strengths is the practice of iterative reflection. The
                        > team should be taking responsibility for listening to external
                        > feedback and trying to improve its effectiveness by:
                        > - reflecting on what its biggest problems are every iteration,
                        > - deciding on one or two process modifications to try to address those
                        > problems, and
                        > - reflecting on whether those changes actually made things better or not.
                        > Imposing TDD (or anything else) on the team undermines the team taking
                        > responsibility for itself.

                        > Whoever would be in the position to impose TDD should instead listen
                        > to what each team thinks it needs to improve its effectiveness, and
                        > then possibly suggest (or steer team conversation via insightful
                        > questions to) whatever practice would be most helpful for that team at
                        > that time. My experience is that TDD comes fairly early in the game,
                        > but for some teams/contexts automated acceptance testing is a better
                        > first step and for others continuous integration. It is critical for
                        > sustained team buy-in that the practice being adopted at each point
                        > visibly addresses the problems the team currently notices.



                        Ron Jeffries
                        www.XProgramming.com
                        In programming, do, or undo. There is always try. --Yoda
                      • Steven Gordon
                        I misinterpretted. What I mean to say in the context of bringing in external training to a team, make sure that the team comes to a consensus that TDD is what
                        Message 11 of 15 , Nov 9, 2007
                        • 0 Attachment
                          I misinterpretted.

                          What I mean to say in the context of bringing in external training to
                          a team, make sure that the team comes to a consensus that TDD is what
                          it wants and needs.

                          On 11/9/07, Ron Jeffries <ronjeffries@...> wrote:
                          >
                          >
                          >
                          >
                          >
                          >
                          > Hello, Steven. I don't think Charlie said to "impose" TDD. I think
                          > he said "choice".
                          >
                          > R.
                          >
                          >
                          > On Friday, November 9, 2007, at 10:23:15 AM, you wrote:
                          >
                          > >> Yes. Of course, I would prefer to see folks who start with TDD
                          > >> move on to additional practices from XP, because those practices
                          > >> have value in themselves and also multiply the effect of TDD.
                          > >> But the fact that TDD is useful alone makes it a really good
                          > >> choice as a start when introducing engineering practices
                          > >> incrementally - if that's what you want to do.
                          >
                          > > I slightly disagree with this.
                          >
                          > > One of Scrum's strengths is the practice of iterative reflection. The
                          > > team should be taking responsibility for listening to external
                          > > feedback and trying to improve its effectiveness by:
                          > > - reflecting on what its biggest problems are every iteration,
                          > > - deciding on one or two process modifications to try to address those
                          > > problems, and
                          > > - reflecting on whether those changes actually made things better or not.
                          > > Imposing TDD (or anything else) on the team undermines the team taking
                          > > responsibility for itself.
                          >
                          > > Whoever would be in the position to impose TDD should instead listen
                          > > to what each team thinks it needs to improve its effectiveness, and
                          > > then possibly suggest (or steer team conversation via insightful
                          > > questions to) whatever practice would be most helpful for that team at
                          > > that time. My experience is that TDD comes fairly early in the game,
                          > > but for some teams/contexts automated acceptance testing is a better
                          > > first step and for others continuous integration. It is critical for
                          > > sustained team buy-in that the practice being adopted at each point
                          > > visibly addresses the problems the team currently notices.
                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > In programming, do, or undo. There is always try. --Yoda
                          >
                          >
                          >
                          >
                        • Charlie Poole
                          Hi Steven, ... I entirely agree. I m curious as to why you think we are in slight disagreement. Charlie
                          Message 12 of 15 , Nov 10, 2007
                          • 0 Attachment
                            Hi Steven,

                            > > Yes. Of course, I would prefer to see folks who start with
                            > TDD move
                            > > on to additional practices from XP, because those practices have
                            > > value in themselves and also multiply the effect of TDD.
                            > > But the fact that TDD is useful alone makes it a really
                            > good choice
                            > > as a start when introducing engineering practices
                            > incrementally - if
                            > > that's what you want to do.
                            >
                            > I slightly disagree with this.
                            >
                            > One of Scrum's strengths is the practice of iterative
                            > reflection. The team should be taking responsibility for
                            > listening to external feedback and trying to improve its
                            > effectiveness by:
                            > - reflecting on what its biggest problems are every iteration,
                            > - deciding on one or two process modifications to try to
                            > address those problems, and
                            > - reflecting on whether those changes actually made things
                            > better or not.
                            > Imposing TDD (or anything else) on the team undermines the
                            > team taking responsibility for itself.
                            >
                            > Whoever would be in the position to impose TDD should instead
                            > listen to what each team thinks it needs to improve its
                            > effectiveness, and then possibly suggest (or steer team
                            > conversation via insightful questions to) whatever practice
                            > would be most helpful for that team at that time. My
                            > experience is that TDD comes fairly early in the game, but
                            > for some teams/contexts automated acceptance testing is a
                            > better first step and for others continuous integration. It
                            > is critical for sustained team buy-in that the practice being
                            > adopted at each point visibly addresses the problems the team
                            > currently notices.

                            I entirely agree. I'm curious as to why you think we are in
                            slight disagreement.

                            Charlie

                            > Steven Gordon
                            >
                            >
                            > >
                            > > Charlie
                            > >
                            >
                            >
                            > To Post a message, send it to: extremeprogramming@...
                            >
                            > To Unsubscribe, send a blank message to:
                            > extremeprogramming-unsubscribe@...
                            >
                            > ad-free courtesy of objectmentor.com
                            > Yahoo! Groups Links
                            >
                            >
                            >
                            >
                          • Steven Gordon
                            Charlie, I now think we are in agreement - I just misinterpretted what you wrote. The quibble I was making was about the context (was it the team choosing TDD
                            Message 13 of 15 , Nov 10, 2007
                            • 0 Attachment
                              Charlie,

                              I now think we are in agreement - I just misinterpretted what you wrote.

                              The quibble I was making was about the context (was it the team
                              choosing TDD or was somebody else choosing it for the team?). I now
                              see that you what you wrote takes no position on that question.

                              My apologies,

                              Steve

                              On Nov 10, 2007 12:08 PM, Charlie Poole <xp@...> wrote:
                              >
                              >
                              >
                              >
                              >
                              >
                              > Hi Steven,
                              >
                              >
                              >
                              > > > Yes. Of course, I would prefer to see folks who start with
                              > > TDD move
                              > > > on to additional practices from XP, because those practices have
                              > > > value in themselves and also multiply the effect of TDD.
                              > > > But the fact that TDD is useful alone makes it a really
                              > > good choice
                              > > > as a start when introducing engineering practices
                              > > incrementally - if
                              > > > that's what you want to do.
                              > >
                              > > I slightly disagree with this.
                              > >
                              > > One of Scrum's strengths is the practice of iterative
                              > > reflection. The team should be taking responsibility for
                              > > listening to external feedback and trying to improve its
                              > > effectiveness by:
                              > > - reflecting on what its biggest problems are every iteration,
                              > > - deciding on one or two process modifications to try to
                              > > address those problems, and
                              > > - reflecting on whether those changes actually made things
                              > > better or not.
                              > > Imposing TDD (or anything else) on the team undermines the
                              > > team taking responsibility for itself.
                              > >
                              > > Whoever would be in the position to impose TDD should instead
                              > > listen to what each team thinks it needs to improve its
                              > > effectiveness, and then possibly suggest (or steer team
                              > > conversation via insightful questions to) whatever practice
                              > > would be most helpful for that team at that time. My
                              > > experience is that TDD comes fairly early in the game, but
                              > > for some teams/contexts automated acceptance testing is a
                              > > better first step and for others continuous integration. It
                              > > is critical for sustained team buy-in that the practice being
                              > > adopted at each point visibly addresses the problems the team
                              > > currently notices.
                              >
                              > I entirely agree. I'm curious as to why you think we are in
                              > slight disagreement.
                              >
                              > Charlie
                              >
                              > > Steven Gordon
                              > >
                              > >
                            • Charlie Poole
                              Hi Steven, ... Only because we re on the XP list and I figure it (mostly) goes without saying. Charlie
                              Message 14 of 15 , Nov 10, 2007
                              • 0 Attachment
                                Hi Steven,

                                > I now think we are in agreement - I just misinterpretted what
                                > you wrote.
                                >
                                > The quibble I was making was about the context (was it the
                                > team choosing TDD or was somebody else choosing it for the
                                > team?). I now see that you what you wrote takes no position
                                > on that question.

                                Only because we're on the XP list and I figure it (mostly)
                                goes without saying.

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