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

Are you getting faster?

Expand Messages
  • Adrian Howard
    A brief e-mail exchange this morning has brought a question to mind. Do you find yourself continuing to do more with less time as you work with the XP
    Message 1 of 12 , Feb 26, 2007
      A brief e-mail exchange this morning has brought a question to mind.

      Do you find yourself continuing to do more with less time as you work
      with the XP practices?

      I think that one of the reasons that I'm able to deliver on stories
      with smaller time scales now than I could five years ago is that I've
      got faster at delivering, by using TDD, simple design, etc.

      I seemed to have a (purely self observed - no hard data) big jump in
      productivity around 2001/2 when TDD finally "clicked", but since then
      I still feel like I'm getting "faster" over the last few years as
      I've... erm... practised the practices more, and learned new ways of
      applying them.

      Thinking on it now I find this slightly curious. I expect to get
      better at doing things, but not necessarily faster. Am I imagining it
      (entirely possible)?

      Do other people feel this way? For folk that have been doing XP/agile
      longer than I have still find that you're seeing significant speed
      improvements - or does it plateau?

      Curiously,

      Adrian
    • Phlip
      ... I feel slower. I spend less time productively debugging, and more time going as slow as I can, doing aimless cleanups and improvements. My bosses get to
      Message 2 of 12 , Feb 26, 2007
        Adrian Howard wrote:

        > Do you find yourself continuing to do more with less time as you work
        > with the XP practices?

        I feel slower. I spend less time "productively" debugging, and more
        time going as slow as I can, doing aimless cleanups and improvements.

        My bosses get to behave as if we are going faster. A new, short list
        of features, every week.

        --
        Phlip
        http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
      • Desilets, Alain
        ... Like Phlip, I find I do less in terms of buggy and possibly useless number of lines of code . But I do more in the sense of buf-free and useful lines
        Message 3 of 12 , Feb 26, 2007
          > Adrian Howard wrote:
          >
          > > Do you find yourself continuing to do more with less time
          > as you work
          > > with the XP practices?
          >
          > I feel slower. I spend less time "productively" debugging,
          > and more time going as slow as I can, doing aimless cleanups
          > and improvements.
          >
          > My bosses get to behave as if we are going faster. A new,
          > short list of features, every week.
          >
          > --
          > Phlip
          > http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
          >

          Like Phlip, I find I do "less" in terms of "buggy and possibly useless number of lines of code".

          But I do more in the sense of "buf-free and useful lines of code".

          You'll notice that there are two dimensions to this: bugginess, and usefulness. TDD helps me mostly with the bugginess issue (although it does help with the usefulness bit also). But StartWithTheSimplestThingThatCouldPossiblyWork is what helps me most on the usefulness side, and I find that this has a higher impact than TDD.

          Note that I am a complete zealot about TDD also. But it feels to me like TheSimplestThing principle has resulted in a non-linear quantum leap in my productivity, whereas TDD seems to "only" have had a linear impact.


          ----
          Alain Désilets, MASc
          Agent de recherches/Research Officer
          Institut de technologie de l'information du CNRC /
          NRC Institute for Information Technology

          alain.desilets@...
          Tél/Tel (613) 990-2813
          Facsimile/télécopieur: (613) 952-7151

          Conseil national de recherches Canada, M50, 1200 chemin Montréal,
          Ottawa (Ontario) K1A 0R6
          National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
          K1A 0R6

          Gouvernement du Canada | Government of Canada
        • Adrian Mowat
          Hi, In my experience you can only go as fast as the organisation allows you to and whether you like it or not, Agile teams don t always have control over
          Message 4 of 12 , Feb 26, 2007
            Hi,

            In my experience you can only go as fast as the organisation allows you to
            and whether you like it or not, Agile teams don't always have control over
            everything they would like to. For example, a cumbersome config management
            policy or an indecisive product owner will always slow you down no matter
            how quickly you can churn out features.

            I would agree though that the rate of improvement will slow down as you get
            the big things like TDD sorted out.

            However, the key question in my mind is this: how fast is "fast enough"? Is
            it acceptable to reach a point where the software development teams are
            moving fast enough to satisfy and exceed market demand with perfect
            quality then concentrate on other things like scalability and broadening
            technical skills that might help future-proof the organisation against
            changes in the market?

            Adrian




            On 26/02/07, Adrian Howard <adrianh@...> wrote:
            >
            > A brief e-mail exchange this morning has brought a question to mind.
            >
            > Do you find yourself continuing to do more with less time as you work
            > with the XP practices?
            >
            > I think that one of the reasons that I'm able to deliver on stories
            > with smaller time scales now than I could five years ago is that I've
            > got faster at delivering, by using TDD, simple design, etc.
            >
            > I seemed to have a (purely self observed - no hard data) big jump in
            > productivity around 2001/2 when TDD finally "clicked", but since then
            > I still feel like I'm getting "faster" over the last few years as
            > I've... erm... practised the practices more, and learned new ways of
            > applying them.
            >
            > Thinking on it now I find this slightly curious. I expect to get
            > better at doing things, but not necessarily faster. Am I imagining it
            > (entirely possible)?
            >
            > Do other people feel this way? For folk that have been doing XP/agile
            > longer than I have still find that you're seeing significant speed
            > improvements - or does it plateau?
            >
            > Curiously,
            >
            > Adrian
            >
            >


            [Non-text portions of this message have been removed]
          • Eric Lefevre
            ... Err... it will never be fast enough? Just look at Toyota and the like: in 3/4 of a century, they never stopped enhancing their R & D and manufacturing
            Message 5 of 12 , Feb 26, 2007
              > However, the key question in my mind is this: how fast is "fast enough"?

              Err... it will never be fast enough? Just look at Toyota and the like: in
              3/4 of a century, they never stopped enhancing their R & D and manufacturing
              processes. Why would it be different for programming?

              On 26/02/07, Adrian Mowat <mowat27@...> wrote:
              >
              > Hi,
              >
              > In my experience you can only go as fast as the organisation allows you to
              > and whether you like it or not, Agile teams don't always have control over
              > everything they would like to. For example, a cumbersome config management
              > policy or an indecisive product owner will always slow you down no matter
              > how quickly you can churn out features.
              >
              > I would agree though that the rate of improvement will slow down as you
              > get
              > the big things like TDD sorted out.
              >
              > However, the key question in my mind is this: how fast is "fast enough"?
              > Is
              > it acceptable to reach a point where the software development teams are
              > moving fast enough to satisfy and exceed market demand with perfect
              > quality then concentrate on other things like scalability and broadening
              > technical skills that might help future-proof the organisation against
              > changes in the market?
              >
              > Adrian
              >
              >


              [Non-text portions of this message have been removed]
            • Ian Collins
              ... It s hard to tell as the technology has changed as well as the process. One thing I do see is how much I slow down if stop following the practices. I have
              Message 6 of 12 , Feb 26, 2007
                Adrian Howard wrote:

                >A brief e-mail exchange this morning has brought a question to mind.
                >
                >Do you find yourself continuing to do more with less time as you work
                >with the XP practices?
                >
                >
                >
                It's hard to tell as the technology has changed as well as the process.
                One thing I do see is how much I slow down if stop following the practices.

                I have also noticed a discrepancy in the expected work rate between XP
                and 'traditional' teams. When working with the latter (I still use XP
                for my bits), I find I can deliver the expected work in fewer hours,
                which suites me.

                Ian
              • Adrian Mowat
                Hi, A fair point well made - but my question is subtly different. I will attempt to re-phrase... Do conditions exist where it is acceptable for a team to take
                Message 7 of 12 , Feb 26, 2007
                  Hi,

                  A fair point well made - but my question is subtly different. I will
                  attempt to re-phrase...

                  Do conditions exist where it is acceptable for a team to take the foot off
                  the gas for a while (perhaps a couple of iterations) and spend the time
                  previously allocated to "getting faster" on other activities that might
                  benefit the team/organisation in the longer term?

                  Or maybe we just roll everything into the same 'process improvement' bucket
                  and don't make a distinction?

                  Adrian


                  On 26/02/07, Eric Lefevre <eric@...> wrote:
                  >
                  > > However, the key question in my mind is this: how fast is "fast
                  > enough"?
                  >
                  > Err... it will never be fast enough? Just look at Toyota and the like: in
                  > 3/4 of a century, they never stopped enhancing their R & D and
                  > manufacturing
                  > processes. Why would it be different for programming?
                  >
                  > On 26/02/07, Adrian Mowat <mowat27@...<mowat27%40googlemail.com>>
                  > wrote:
                  > >
                  > > Hi,
                  > >
                  > > In my experience you can only go as fast as the organisation allows you
                  > to
                  > > and whether you like it or not, Agile teams don't always have control
                  > over
                  > > everything they would like to. For example, a cumbersome config
                  > management
                  > > policy or an indecisive product owner will always slow you down no
                  > matter
                  > > how quickly you can churn out features.
                  > >
                  > > I would agree though that the rate of improvement will slow down as you
                  > > get
                  > > the big things like TDD sorted out.
                  > >
                  > > However, the key question in my mind is this: how fast is "fast enough"?
                  > > Is
                  > > it acceptable to reach a point where the software development teams are
                  > > moving fast enough to satisfy and exceed market demand with perfect
                  > > quality then concentrate on other things like scalability and broadening
                  > > technical skills that might help future-proof the organisation against
                  > > changes in the market?
                  > >
                  > > Adrian
                  > >
                  > >
                  >
                  > [Non-text portions of this message have been removed]
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Gary Brown
                  ... I don t know what the other activities might be, but is there any way to do them incrementally in small steps, as part of delivering value to your
                  Message 8 of 12 , Feb 26, 2007
                    Quoting Adrian Mowat <mowat27@...>:

                    > Hi,
                    >
                    > A fair point well made - but my question is subtly different. I will
                    > attempt to re-phrase...
                    >
                    > Do conditions exist where it is acceptable for a team to take the foot off
                    > the gas for a while (perhaps a couple of iterations) and spend the time
                    > previously allocated to "getting faster" on other activities that might
                    > benefit the team/organisation in the longer term?
                    >
                    > Or maybe we just roll everything into the same 'process improvement' bucket
                    > and don't make a distinction?
                    >
                    > Adrian

                    I don't know what the other activities might be, but is there any way
                    to do them incrementally in small steps, as part of delivering value
                    to your Customer?

                    GB.
                  • John Roth
                    From: Eric Lefevre To: Sent: Monday, February 26, 2007 2:08 PM Subject: Re: [XP] Are you getting
                    Message 9 of 12 , Feb 26, 2007
                      From: "Eric Lefevre" <eric@...>
                      To: <extremeprogramming@yahoogroups.com>
                      Sent: Monday, February 26, 2007 2:08 PM
                      Subject: Re: [XP] Are you getting faster?


                      >> However, the key question in my mind is this: how fast is "fast enough"?
                      >
                      > Err... it will never be fast enough? Just look at Toyota and the like: in
                      > 3/4 of a century, they never stopped enhancing their R & D and
                      > manufacturing
                      > processes. Why would it be different for programming?

                      Sooner or later you have to stop and ask whether making
                      further progress on that particular goal is worth while, or
                      whether some other goal is now more important.

                      John Roth
                    • Daniel Wildt
                      For those activities I suggest you to work with Spike tests, in order to increase your productivity and your development process. HYPERLINK
                      Message 10 of 12 , Feb 26, 2007
                        For those activities I suggest you to work with Spike tests, in order to increase your productivity and your development process.
                        HYPERLINK "http://c2.com/xp/SpikeSolution.html"http://c2.com/xp/SpikeSolution.html
                        HYPERLINK "http://www.extremeprogramming.org/rules/spike.html"http://www.extremeprogramming.org/rules/spike.html

                        You can work with your customers to schedule these inside your planning activities.

                        But as always, you need to delivery quality software at the end of the iteration.
                        The customer does not care if you are doing tests with tool A or B, the customer wants the software to be delivered.

                        Att,
                        Daniel Wildt






                        _____

                        De: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] Em nome de Gary Brown
                        Enviada em: segunda-feira, 26 de fevereiro de 2007 19:58
                        Para: extremeprogramming@yahoogroups.com
                        Assunto: Re: [XP] Are you getting faster?



                        Quoting Adrian Mowat <HYPERLINK "mailto:mowat27%40googlemail.com"mowat27@googlemail.-com>:

                        > Hi,
                        >
                        > A fair point well made - but my question is subtly different. I will
                        > attempt to re-phrase...
                        >
                        > Do conditions exist where it is acceptable for a team to take the foot off
                        > the gas for a while (perhaps a couple of iterations) and spend the time
                        > previously allocated to "getting faster" on other activities that might
                        > benefit the team/organisation in the longer term?
                        >
                        > Or maybe we just roll everything into the same 'process improvement' bucket
                        > and don't make a distinction?
                        >
                        > Adrian

                        I don't know what the other activities might be, but is there any way
                        to do them incrementally in small steps, as part of delivering value
                        to your Customer?

                        GB.






                        --
                        No virus found in this incoming message.
                        Checked by AVG Free Edition.
                        Version: 7.5.446 / Virus Database: 268.18.4/703 - Release Date: 26/02/2007 14:56



                        --
                        No virus found in this outgoing message.
                        Checked by AVG Free Edition.
                        Version: 7.5.446 / Virus Database: 268.18.4/703 - Release Date: 26/02/2007 14:56



                        [Non-text portions of this message have been removed]
                      • Adam Sroka
                        ... Me too! I spend less time spinning my wheels. As a result I can deliver more value and spend more time ensuring the quality of the code I produce. But, I
                        Message 11 of 12 , Feb 26, 2007
                          On 2/26/07, Phlip <phlip2005@...> wrote:
                          > Adrian Howard wrote:
                          >
                          > > Do you find yourself continuing to do more with less time as you work
                          > > with the XP practices?
                          >
                          > I feel slower. I spend less time "productively" debugging, and more
                          > time going as slow as I can, doing aimless cleanups and improvements.
                          >
                          > My bosses get to behave as if we are going faster. A new, short list
                          > of features, every week.
                          >

                          Me too!

                          I spend less time spinning my wheels. As a result I can deliver more
                          value and spend more time ensuring the quality of the code I produce.
                          But, I am never in a rush to meet some arbitrary deployment deadline
                          or fix some unknown bug that I haplessly deployed into production. At
                          night I sleep.
                        • gutzofter
                          Here is your 2cents... Its about cohesion and orthogonality. The developer with Agile is more productive because of the reduction of noise and hysteresis
                          Message 12 of 12 , Mar 1, 2007
                            Here is your 2cents...

                            Its about cohesion and orthogonality. The developer with Agile is more
                            productive because of the reduction of noise and hysteresis (changing
                            requirements) in the system. The developed software is more cohesive
                            between the developer and the environment. I see this as mainly a
                            decoupling of the tools from the environment and vice versus. By
                            tools, I also include practices and processes (Agile). The environment
                            would include technologies (this includes programming languages). The
                            next revolution I see coming is the separation of coupling between the
                            developer and the tools.

                            --- In extremeprogramming@yahoogroups.com, Adrian Howard <adrianh@...>
                            wrote:
                            >
                            > A brief e-mail exchange this morning has brought a question to mind.
                            >
                            > Do you find yourself continuing to do more with less time as you work
                            > with the XP practices?
                            >
                            > I think that one of the reasons that I'm able to deliver on stories
                            > with smaller time scales now than I could five years ago is that I've
                            > got faster at delivering, by using TDD, simple design, etc.
                            >
                            > I seemed to have a (purely self observed - no hard data) big jump in
                            > productivity around 2001/2 when TDD finally "clicked", but since then
                            > I still feel like I'm getting "faster" over the last few years as
                            > I've... erm... practised the practices more, and learned new ways of
                            > applying them.
                            >
                            > Thinking on it now I find this slightly curious. I expect to get
                            > better at doing things, but not necessarily faster. Am I imagining it
                            > (entirely possible)?
                            >
                            > Do other people feel this way? For folk that have been doing XP/agile
                            > longer than I have still find that you're seeing significant speed
                            > improvements - or does it plateau?
                            >
                            > Curiously,
                            >
                            > Adrian
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.