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

Newbie question about inspecting and adapting

Expand Messages
  • danoluye
    Hello everyone. I ve just discovered this group and XP (and Agile) after having read a long blog post about team performance. In that post the author mention
    Message 1 of 12 , May 14, 2006
      Hello everyone. I've just discovered this group and XP (and Agile)
      after having read a long blog post about team performance. In that
      post the author mention Agile at the very end and after a few google
      search here I am :)

      My question is simple: in that post
      http://brainscrum.wordpress.com/2006/05/13/team-performance-and-assumptions/

      the author writes that "to date we have changed the duration of the
      iterations, the way we pair (2 or 3 times), the story lifecycle, the
      way we do the planning game, how different people interact and even
      the way we move the stories on the cardwall (plus many more details).
      We are now going to change the day and the way we do the showcase
      before the planning".

      Is this normal? From the quick research I did so far it seems that XP
      and Agile is based on applying, inspecting and adapting but does it
      work? I mean isn't it too much of a burden for the team to go through
      not only the actual day to day work of developing a software but also
      to continuously inspect the process itself and try new things?

      Thanks in advance to all those of you who will waste their time
      answering :)

      - Dan
    • Ron Jeffries
      ... The bottom line is that if we want to be better at what we do, we need to pay attention to what happens, observe what seems not to be quite right, and try
      Message 2 of 12 , May 14, 2006
        On Sunday, May 14, 2006, at 6:20:12 AM, danoluye wrote:

        > Is this normal? From the quick research I did so far it seems that XP
        > and Agile is based on applying, inspecting and adapting but does it
        > work? I mean isn't it too much of a burden for the team to go through
        > not only the actual day to day work of developing a software but also
        > to continuously inspect the process itself and try new things?

        The bottom line is that if we want to be better at what we do, we
        need to pay attention to what happens, observe what seems not to be
        quite right, and try different things. When we play a sport, we
        experiment with holding the racquet or cue differently; when we play
        music we adjust the key or the tempo; when we write we try saying
        "we" instead of "you" to see if it works better.

        All improvement is about observing and responding to what we
        observe. It doesn't have to take much time, and it usually pays off
        quite soon. But Agile or not, to get better we have to pay attention
        and adjust.

        Does that help?

        Ron Jeffries
        www.XProgramming.com
        Agility might be said to be about encountering
        all the problems so early and so often that the
        effort to fix them is less than the pain of enduring them.
      • D. AndrĂ© Dhondt
        ... It would be a burden to skip the software process improvement tasks. Every Wednesday (the start of our iteration), we have a few hours to reflect, discuss
        Message 3 of 12 , May 14, 2006
          >
          > >isn't it too much of a burden for the team to go through
          > not only the actual day to day work of developing a software but also
          > to continuously inspect the process itself and try new things?


          It would be a burden to skip the software process improvement tasks. Every
          Wednesday (the start of our iteration), we have a few hours to reflect,
          discuss weekly "extra-curricular" readings, industry updates, etc. It's a
          great break from the work that directly impacts the business--it helps us
          regroup and be ready to give 100% again for the upcoming iteration.


          [Non-text portions of this message have been removed]
        • Tim King
          ... I agree with what Ron said. It is not a burden at all. In fact, it is less than a burden. Because as the team tries things and discovers what works and
          Message 4 of 12 , May 14, 2006
            danoluye wrote:

            >... Agile is based on applying, inspecting and adapting but does it
            >work? I mean isn't it too much of a burden for the team to go through
            >not only the actual day to day work of developing a software but also
            >to continuously inspect the process itself and try new things?
            >
            >
            I agree with what Ron said. It is not a burden at all. In fact, it is
            less than a burden. Because as the team tries things and discovers what
            works and what doesn't, it gets better at what it does, and the work
            seems easier. It's much more of a burden to do the same thing day after
            day without improving. Being comfortable in the here and now is what
            amateurs do, not professionals. And an amateur would find a finely tuned
            team overwhelming. But becoming a professional means being more
            introspective, engaging more with the work, and stretching yourself. You
            end up doing things that you once thought were impossible for you.

            So, if a developer's time is completely taken up with cranking out code,
            then yes, it will be too much for him to reflect on the process and
            improve. And you will have a bunch of perpetual amateurs in your team. I
            tell my kids that they need to sleep, because asleep is when you grow.
            The same is true of people. In the slack is when you grow, when you get
            better. Or to put it another way, if you want your team to be
            professional, you need to give them time to reflect, and you need to
            give them time to manage the process. You will get software coded in the
            first few days or weeks, but you'll end up with more than you had before.

            -TimK

            --
            J. Timothy King's Blog http://www.jtse.com/blog/
            software development, leadership, and entrepreneurship
            be the story http://bethestory.com/
            celebrating stories and those who tell them
          • Bill Caputo
            ... Without waxing too philosophical, I would say that its normal for all software projects, Agile /XP practioners simply try to make it part of the process. I
            Message 5 of 12 , May 14, 2006
              On 5/14/06, danoluye <skills102@...> wrote:

              > Is this normal? From the quick research I did so far it seems that XP
              > and Agile is based on applying, inspecting and adapting but does it
              > work? I mean isn't it too much of a burden for the team to go through
              > not only the actual day to day work of developing a software but also
              > to continuously inspect the process itself and try new things?

              Without waxing too philosophical, I would say that its normal for all
              software projects, Agile /XP practioners simply try to make it part of
              the process.

              I have said for a long time now
              (http://www.williamcaputo.com/archives/000002.html) that the primary
              (perhaps only) true difference between Agile/XP approaches and more
              traditional ones is that we *expect* to change the code, the
              requirements, the scope, and our process (so we study techniques that
              help us do that) whereas in most project cultures its viewed as some
              sort of failure if one does these things. It would be a failure too --
              if it were actually rare to have to change these them, but from all
              evidence change is normal -- resisting it, pretending it doesn't
              exist, trying to follow a plan regardles, that's the unusual behavior.

              > Thanks in advance to all those of you who will waste their time
              > answering :)

              Well it may well be a waste of time, but seeing as how that's what we
              do here, just as well waste it answering your post as someone else's.
              :-P

              Best,
              Bill
            • Doug Swartz
              ... In short: No. Certainly, there is a mindset involved in wanting to get better and being willing to change the way we work to try to get better at what we
              Message 6 of 12 , May 14, 2006
                Sunday, May 14, 2006, 5:20:12 AM, danoluye wrote:

                > Is this normal? From the quick research I did so far it seems that XP
                > and Agile is based on applying, inspecting and adapting but does it
                > work? I mean isn't it too much of a burden for the team to go through
                > not only the actual day to day work of developing a software but also
                > to continuously inspect the process itself and try new things?

                In short: No.

                Certainly, there is a mindset involved in wanting to get
                better and being willing to change the way we work to
                try to get better at what we do. Generally, however, I haven't
                found inspecting the process and trying new things to be a
                burden. I've found it to be a great joy.

                When does inspection happen? Well, of course it happens
                at an iteration retrospective. But, that's just one
                formal point for it. It also happens when two team members are
                talking over lunch. It happens during the mid-morning break
                when several people on the team take the half mile walk around
                the parking lot. It happens every time somebody on the team
                says, "Hey, you know I think we should ...."

                When does process change happen? Of course, we always choose
                one or two things to focus on for the next iteration during
                the retrospective. But it also happens when two or three
                people decide during their morning walk to make a chart on the
                wall of "who paired with who" . It happens when Bob brings up
                the idea he and Mary talked about during lunch yesterday at
                the morning meeting, and the team decides to "give it a try".
                It happens in little process changes all the time, and bigger
                process changes after more discussion.

                What lets process change happen is making the team responsible
                for their own actions and results. It can happen naturally
                when everyone realizes it's OK to make a change that doesn't
                work. We often set a time-frame for trying the change: "Let's
                try it for a few days.", or "We'll do that for two iterations,
                to see if it works.".


                --

                Doug Swartz
                daswartz@...
              • William Pietri
                ... As others point out, it isn t a burden; it s a joy that pays for itself. As they say, if you think education is expensive, you should try ignorance.
                Message 7 of 12 , May 14, 2006
                  danoluye wrote:
                  > I mean isn't it too much of a burden for the team to go through
                  > not only the actual day to day work of developing a software but also
                  > to continuously inspect the process itself and try new things?
                  >

                  As others point out, it isn't a burden; it's a joy that pays for itself.
                  As they say, if you think education is expensive, you should try ignorance.

                  William
                • Ilja Preuss
                  Besides the things that have already been written in this thread (and whith which I agree), it reminds me of an experiment I read about somewhere. A big
                  Message 8 of 12 , May 15, 2006
                    Besides the things that have already been written in this thread (and whith
                    which I agree), it reminds me of an experiment I read about somewhere.

                    A big company (I think it was IBM, but I could be wrong) tried different
                    lightening conditions to find out which one was optimal for their workers.
                    To their great surprise, the found that every time they changed the
                    lightening, performance of the workers improved for a while, even if they
                    switched back to an earlier configuration.

                    To me this is another datapoint that suggests that change itself generally
                    isn't a burden, but can in fact be a motivator.

                    Cheers, Ilja
                  • Ron Jeffries
                    ... This is called the Hawthorne Effect and relates to a study done by some Harvard business school people. The top few Google links:
                    Message 9 of 12 , May 15, 2006
                      On Monday, May 15, 2006, at 5:00:20 AM, Ilja Preuss wrote:

                      > A big company (I think it was IBM, but I could be wrong) tried different
                      > lightening conditions to find out which one was optimal for their workers.
                      > To their great surprise, the found that every time they changed the
                      > lightening, performance of the workers improved for a while, even if they
                      > switched back to an earlier configuration.

                      This is called the "Hawthorne Effect" and relates to a study done by
                      some Harvard business school people. The top few Google links:

                      http://www.nwlink.com/~donclark/hrd/history/hawthorne.html
                      http://en.wikipedia.org/wiki/Hawthorne_effect
                      http://www.psy.gla.ac.uk/~steve/hawth.html

                      Ron Jeffries
                      www.XProgramming.com
                      Assume that anything you didn't like was the funny stuff.
                      -- Jim Shore
                    • danoluye
                      Thanks to everyone. The idea of regularly improving is not new to me I found just strange (in a good sense) so fast, so often, so deep. I mean: the way they
                      Message 10 of 12 , May 15, 2006
                        Thanks to everyone. The idea of regularly improving is not new to me I
                        found just strange (in a good sense) so fast, so often, so deep. I
                        mean: the way they move the card on the cardwall!!

                        I have a lot of stuff to read now. Rhanks again!

                        - Dan
                      • Ilja Preuss
                        ... Ah, right. Thanks for refreshing my memory! :) Cheers, Ilja
                        Message 11 of 12 , May 15, 2006
                          extremeprogramming@yahoogroups.com wrote:
                          > On Monday, May 15, 2006, at 5:00:20 AM, Ilja Preuss wrote:
                          >
                          >> A big company (I think it was IBM, but I could be wrong) tried
                          >> different lightening conditions to find out which one was optimal for
                          >> their workers. To their great surprise, the found that every time
                          >> they changed the lightening, performance of the workers improved for
                          >> a while, even if they switched back to an earlier configuration.
                          >
                          > This is called the "Hawthorne Effect" and relates to a study
                          > done by some Harvard business school people. The top few Google links:

                          Ah, right. Thanks for refreshing my memory! :)

                          Cheers, Ilja
                        • yahoogroups@jhrothjr.com
                          The Hawthorne effect. Experiment at AT&T s manufacturing arm. For a long time it was _the_ poster child for the effect you re quoting, but has been debunked in
                          Message 12 of 12 , May 15, 2006
                            The Hawthorne effect. Experiment at AT&T's manufacturing
                            arm. For a long time it was _the_ poster child for the effect
                            you're quoting, but has been debunked in the last few years.
                            Saying it had serious methodological errors is glossing over the
                            point that there _wasn't_ a methodology. Also it wasn't a
                            return to baseline - there were lots of continuous changes
                            that account for the improvements - such as improved
                            lighting.

                            John Roth


                            ----- Original Message -----
                            From: "Ilja Preuss" <preuss.at.disy.net@...>
                            To: "extremeprogramming@yahoogroups.com"
                            <extremeprogramming.at.yahoogroups.com@...>
                            Sent: Monday, May 15, 2006 3:00 AM
                            Subject: RE: [XP] Newbie question about inspecting and adapting


                            > Besides the things that have already been written in this thread (and
                            > whith
                            > which I agree), it reminds me of an experiment I read about somewhere.
                            >
                            > A big company (I think it was IBM, but I could be wrong) tried different
                            > lightening conditions to find out which one was optimal for their workers.
                            > To their great surprise, the found that every time they changed the
                            > lightening, performance of the workers improved for a while, even if they
                            > switched back to an earlier configuration.
                            >
                            > To me this is another datapoint that suggests that change itself generally
                            > isn't a burden, but can in fact be a motivator.
                            >
                            > Cheers, Ilja
                            >
                            >
                            >
                            > 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
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.