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

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

Expand Messages
  • Gary Brown
    ... Isn t that kinda like asking how do you like playing shortstop compared to the Super Bowl? GB.
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.