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

Recommendations for on-site TDD training?

Expand Messages
  • aalanatlas
    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
    Message 1 of 15 , Oct 29, 2007
    • 0 Attachment
      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.

      Alan
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.