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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.