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

Re: zooming, porpoising, and goal level

Expand Messages
  • aacockburn
    ... wrote: AC:
    Message 1 of 23 , May 4, 2005
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
      wrote:
      AC:<<I'll posit a slightly extreme position in this post, mostly for
      the sake of discussion, that if you are finding that people's self
      reported goals are unreliable, then you had a lousy Facilitator and
      the requirements gathering people had wax in their ears.
      The opposite statement of the above is that with good
      facilitation, and if the requirements gathering people are alert,
      there are lots of clues spoken out loud in every meeting that tell
      you what's going on at the clam level --- Mind, I recognize that this
      is doing the clam-up work real-time within the group discussion and
      while driving home, but still I claim the information is on the table.
      >>

      > So just to clarify what the points of disagreement are, you are
      agreeing
      > that the analysis has to be clam-up, just disagreeing on what
      technique is
      > necessary for doing that analysis?

      egad, I don't see how you drew that conclusion! I posited one
      position and its opposite, the latter with two 'if' statements in it.
      How does that get interpreted as agreement that analysis "has to be"
      clam-up?

      Quite the non-opposite. I can't imagine that analysis "has to be"
      clam up (or top-down). I can imagine that clam-level details show
      themselves to be useful.



      > I'd argue in fact that any user-centered
      > design process must be clam-up or it's not UCD. After all, if
      you're not
      > starting with individual users' work, you're not starting with
      users, you're
      > starting with some abstraction.

      I'll let someone else take issue with assertion --- since I'm not a
      UCD person, I don't personally care whether it carries the UCD tag or
      not. I'm only asking whether one gets a good result, and if so, am
      quite fine if all the UCD people in the world break out in hives from
      the manner in which that good result is achieved.

      Jeff's question is essentially, can one get a good result middle-up-
      down-with-some-clam-stuff-showing-up-along-the-way (my way), or
      bottom-up (the UCD way), or both? And does it actually matter which
      path is followed, since it seems both seem sensitive to the quality
      of the person doing the work?

      I'm starting to think the quality of the person trumps the method.
    • aacockburn
      p.s. nice note on the examples, Hugh, thanks ... sawmill, table ... amount of ... Once again it looks like you trimmed too much out of my post and lost the
      Message 2 of 23 , May 4, 2005
      • 0 Attachment
        p.s. nice note on the examples, Hugh, thanks


        --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
        wrote:
        > Very true, but it's possible to take the argument too far. A
        sawmill, table
        > saw, and jigsaw can all injure you but they vary greatly in the
        amount of
        > damage they're likely to do and the speed at which they'll do it.
        >

        Once again it looks like you trimmed too much out of my post and lost
        the context in constructing a response. Here are all three
        paragraphs:
        <<--- In agile-usability@yahoogroups.com, "Anita Salem" <asalem@s...>
        wrote:
        > many facilitators I see are not well versed in interviewing
        > techniques.
        > So my question is, how do we address the reality of underskilled
        > practitioners? Are we overly optimistic that anyone can be a "good"
        > facilitator? Interviewing is a specialized skill and one my
        students have a
        > very difficult time with. I can't remember where I heard it
        exactly (one of
        > the sessions from the "In Use" conference I think ) where it was
        proposed
        > that in order for agile methods to be effective, the team members
        need to be
        > highly skilled and experienced. Can agile methods work effectively
        with
        > underskilled practitioners or are they an elite development
        methodology?
        > Anita

        AC:<<Yes, Larry Constantine likes to advertise that agile methods
        won't
        work with underskilled practitioners, but frankly, no technique works
        with underskilled practitioners. I don't think any of us here would
        assert that UCD produces fine systems with slapdash, undermotivated,
        hasty, untrained practioners --- or that ditto practioners would
        produce good systems when working in a waterfall fashion; or that
        ditto practitioners would produce good systems when working in an
        agile fashion.
        In fact it's pretty much a tautology that weak practioners produce
        weak outcomes, regardless of the process; and any successful project
        builds its success on the competent and experienced people present.
        There is no distinction available here for agile / waterfall / UCD /
        bottom-up / top-down etc.
        >>


        The long form of the deduction, which I was hoping I wouldn't have to
        try to recall and type in (hence the short form phrase "tautology")
        goes like this:

        Larry stands on stage and says, "The trouble with agile methods is
        that you need competent and experienced people to make them work."
        People nod their heads as though they understand, because the human
        brain seems wired to switch to the inverse, which doesn't logically
        follow ... when in fact they should be listening to the converse,
        which does logically follow.

        The assertion is: IF you want an agile project to succeed, THEN you
        must have a (some) competent and experienced person(s) on your team.

        The converse (which follows) is: IF you don't have any competent and
        experienced people on your team, THEN you won't get the agile project
        to succeed.

        This is quite likely true. On the other hand, if you don't have any
        competent and experienced people on your team, then you won't get
        [fill in the blank] method to work either.

        In other words, having a certain number of competent and experienced
        people on the project is a critical success factor for any method,
        and is not tied to agile. Larry is really saying: "The trouble with
        any method of software development is that you need competent and
        experienced people to make them work." --- which while true is pretty
        much a vaccuous statement.

        The trouble comes with people hearing the inverse of his statement,
        which doesn't follow:
        IF you don't use an agile method, THEN you don't need competent and
        experienced people.
        Which neither follows logically, nor is true. But since it
        isn't actually spoken out loud, people don't notice, so they just nod
        their heads and leave the room mumbling, "The problem with agile
        methods is you need competent and experienced people to make them
        work", as though that sentence meant anything.

        There, that is the long form of the argument. So it ends up being a
        tautology that you need skilled people to make things work well.

        The other thing you should notice in the original posting is that I
        was responding to Anita's question, which she asked as a consequence
        to Larry's sentence: "Can agile methods work effectively with
        underskilled practitioners or are they an elite development
        methodology?"

        My response was the short form of that long argument, with the tail
        question, can, indeed, any method work with underskilled
        practitioners?

        The purpose of all this is, in fact, to take the tautology out of the
        question and get the questions back onto useful territory.

        Sorry for the long posting,
        Alistair
      • Hugh Beyer
        ... wrote: AC:
        Message 3 of 23 , May 4, 2005
        • 0 Attachment

           

          --- In agile-usability@yahoogroups.com , "Hugh Beyer" <beyer@i...>
          wrote:
          AC:<<I'll posit a slightly extreme position in this post, mostly for
          the sake of discussion, that if you are finding that people's self
          reported goals are unreliable, then you had a lousy Facilitator and
          the requirements gathering people had wax in their ears.
             The opposite statement of the above is that with good
          facilitation, and if the requirements gathering people are alert,
          there are lots of clues spoken out loud in every meeting that tell
          you what's going on at the clam level --- Mind, I recognize that this
          is doing the clam-up work real-time within the group discussion and
          while driving home, but still I claim the information is on the table.
          >>

          > So just to clarify what the points of disagreement are, you are
          agreeing
          > that the analysis has to be clam-up, just disagreeing on what
          technique is
          > necessary for doing that analysis?

          egad, I don't see how you drew that conclusion! I posited one
          position and its opposite, the latter with two 'if' statements in it.
          How does that get interpreted as agreement that analysis "has to be"
          clam-up?

          Quite the non-opposite. I can't imagine that analysis "has to be"
          clam up (or top-down). I can imagine that clam-level details show
          themselves to be useful.

           

          Sorry. I thought your paragraph starting “The opposite statement…”  was stating your own point of view—that the clam-level details would still be available in a facilitated requirements gathering meeting.

           

          > I'd argue in fact that any user-centered
          > design process must be clam-up or it's not UCD. After all, if
          you're not
          > starting with individual users' work, you're not starting with
          users, you're
          > starting with some abstraction.

          I'll let someone else take issue with assertion --- since I'm not a
          UCD person, I don't personally care whether it carries the UCD tag or
          not. I'm only asking whether one gets a good result, and if so, am
          quite fine if all the UCD people in the world break out in hives from
          the manner in which that good result is achieved.

           

          And this isn’t a UCD list, and the “what is UCD” question is flame war bait anyway, so I’m willing to let it pass. This was simply a perspective I hadn’t thought about before.



          Jeff's question is essentially, can one get a good result middle-up-
          down-with-some-clam-stuff-showing-up-along-the-way (my way), or
          bottom-up (the UCD way), or both? And does it actually matter which
          path is followed, since it seems both seem sensitive to the quality
          of the person doing the work?

          I'm starting to think the quality of the person trumps the method.

          Certainly a good person with a poor process will probably produce a better result than a poor person with a good process every time.

           

                      Hugh



        • Jon Kern
          not to dis clams... i think a scallop-based method might be a better approach.... don t they have up to 100 eyes? -- jon ... wrote: AC:
          Message 4 of 23 , May 4, 2005
          • 0 Attachment
            not to dis clams... i think a "scallop-based" method  might be a better approach.... don't they have up to 100 eyes?
            -- jon
            
            


            aacockburn said the following on 5/4/2005 5:05 PM:
            --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
            wrote:
            AC:<<I'll posit a slightly extreme position in this post, mostly for
            the sake of discussion, that if you are finding that people's self
            reported goals are unreliable, then you had a lousy Facilitator and
            the requirements gathering people had wax in their ears.
               The opposite statement of the above is that with good
            facilitation, and if the requirements gathering people are alert,
            there are lots of clues spoken out loud in every meeting that tell
            you what's going on at the clam level --- Mind, I recognize that this
            is doing the clam-up work real-time within the group discussion and
            while driving home, but still I claim the information is on the table.
            >>

            > So just to clarify what the points of disagreement are, you are
            agreeing
            > that the analysis has to be clam-up, just disagreeing on what
            technique is
            > necessary for doing that analysis?

            egad, I don't see how you drew that conclusion! I posited one
            position and its opposite, the latter with two 'if' statements in it.
            How does that get interpreted as agreement that analysis "has to be"
            clam-up?

            Quite the non-opposite. I can't imagine that analysis "has to be"
            clam up (or top-down). I can imagine that clam-level details show
            themselves to be useful.



            > I'd argue in fact that any user-centered
            > design process must be clam-up or it's not UCD. After all, if
            you're not
            > starting with individual users' work, you're not starting with
            users, you're
            > starting with some abstraction.

            I'll let someone else take issue with assertion --- since I'm not a
            UCD person, I don't personally care whether it carries the UCD tag or
            not. I'm only asking whether one gets a good result, and if so, am
            quite fine if all the UCD people in the world break out in hives from
            the manner in which that good result is achieved.

            Jeff's question is essentially, can one get a good result middle-up-
            down-with-some-clam-stuff-showing-up-along-the-way (my way), or
            bottom-up (the UCD way), or both? And does it actually matter which
            path is followed, since it seems both seem sensitive to the quality
            of the person doing the work?

            I'm starting to think the quality of the person trumps the method.






          • Jon Kern
            i think in some sense, agile methods are paired with requiring competent, top-notch people because 1) It is easy to follow a rigorous, multi-step process like
            Message 5 of 23 , May 4, 2005
            • 0 Attachment
              i think in some sense, agile methods are paired with requiring competent, top-notch people because

              1) It is easy to follow a rigorous, multi-step process like an automaton, churning out documents at each step, not worrying if it is helping get to the end goal or not. Hence, Larry Constantine's statement is true:
                  IF you don't use an agile method, THEN you don't
                need competent and experienced people.
              People can hide incompetence behind voluminous process. It is also found in droves in the whole Mgt By Objectives (MBO) bull-crap.

              In these sorts of organizations/teams/processes, it is easy to mistake activity for progress.

              2) It is harder to do agile properly because it takes wisdom and experience to make proper (apparent) guesses about what is "enough" It takes guts to demand frequent, tangible, working results to show application feature progress (or lack thereof).

              Conversely, it is easy to abuse, for example, XP with incompetent execution.

              People, process, tools. Good people are all you need. In a process vacuum, they will invent process. Even if all vendors were vaporized, good people will develop tools.

              -- jon
              
              


              aacockburn said the following on 5/4/2005 5:28 PM:
              p.s. nice note on the examples, Hugh, thanks


              --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
              wrote:
              > Very true, but it's possible to take the argument too far. A
              sawmill, table
              > saw, and jigsaw can all injure you but they vary greatly in the
              amount of
              > damage they're likely to do and the speed at which they'll do it.
              >

              Once again it looks like you trimmed too much out of my post and lost
              the context in constructing a response. Here are all three
              paragraphs:
              <<--- In agile-usability@yahoogroups.com, "Anita Salem" <asalem@s...>
              wrote:
              > many facilitators I see are not well versed in interviewing
              > techniques.
              > So my question is, how do we address the reality of underskilled
              > practitioners? Are we overly optimistic that anyone can be a "good"
              > facilitator? Interviewing is a specialized skill and one my
              students have a
              > very difficult time with. I can't remember where I heard it
              exactly (one of
              > the sessions from the "In Use" conference I think ) where it was
              proposed
              > that in order for agile methods to be effective, the team members
              need to be
              > highly skilled and experienced. Can agile methods work effectively
              with
              > underskilled practitioners or are they an elite development
              methodology?
              > Anita

              AC:<<Yes, Larry Constantine likes to advertise that agile methods
              won't
              work with underskilled practitioners, but frankly, no technique works
              with underskilled practitioners. I don't think any of us here would
              assert that UCD produces fine systems with slapdash, undermotivated,
              hasty, untrained practioners --- or that ditto practioners would
              produce good systems when working in a waterfall fashion; or that
              ditto practitioners would produce good systems when working in an
              agile fashion.
                 In fact it's pretty much a tautology that weak practioners produce
              weak outcomes, regardless of the process; and any successful project
              builds its success on the competent and experienced people present.
              There is no distinction available here for agile / waterfall / UCD /
              bottom-up / top-down etc.
              >>


              The long form of the deduction, which I was hoping I wouldn't have to
              try to recall and type in (hence the short form phrase "tautology")
              goes like this:

              Larry stands on stage and says, "The trouble with agile methods is
              that you need competent and experienced people to make them work."
              People nod their heads as though they understand, because the human
              brain seems wired to switch to the inverse, which doesn't logically
              follow ... when in fact they should be listening to the converse,
              which does logically follow.

              The assertion is: IF you want an agile project to succeed, THEN you
              must have a (some) competent and experienced person(s) on your team.

              The converse (which follows) is: IF you don't have any competent and
              experienced people on your team, THEN you won't get the agile project
              to succeed.

              This is quite likely true. On the other hand, if you don't have any
              competent and experienced people on your team, then you won't get
              [fill in the blank] method to work either.

              In other words, having a certain number of competent and experienced
              people on the project is a critical success factor for any method,
              and is not tied to agile.  Larry is really saying: "The trouble with
              any method of software development is that you need competent and
              experienced people to make them work." --- which while true is pretty
              much a vaccuous statement.

              The trouble comes with people hearing the inverse of his statement,
              which doesn't follow:
              IF you don't use an agile method, THEN you don't need competent and
              experienced people.
              Which neither follows logically, nor is true. But since it
              isn't actually spoken out loud, people don't notice, so they just nod
              their heads and leave the room mumbling, "The problem with agile
              methods is you need competent and experienced people to make them
              work", as though that sentence meant anything.

              There, that is the long form of the argument. So it ends up being a
              tautology that you need skilled people to make things work well.

              The other thing you should notice in the original posting is that I
              was responding to Anita's question, which she asked as a consequence
              to Larry's sentence: "Can agile methods work effectively with
              underskilled practitioners or are they an elite development
              methodology?"

              My response was the short form of that long argument, with the tail
              question, can, indeed, any method work with underskilled
              practitioners?

              The purpose of all this is, in fact, to take the tautology out of the
              question and get the questions back onto useful territory.

              Sorry for the long posting,
              Alistair




            • Ron Jeffries
              ... When talking about optimizing code, some wise person once said If it doesn t have to work, I can make it as fast as you want. The two ideas above remind
              Message 6 of 23 , May 5, 2005
              • 0 Attachment
                On Wednesday, May 4, 2005, at 11:03:39 PM, Jon Kern wrote:

                > i think in some sense, agile methods are paired with requiring competent, top-notch people
                > because

                > 1) It is easy to follow a rigorous, multi-step process like an automaton, churning out
                > documents at each step, not worrying if it is helping get to
                > the end goal or not. Hence, Larry
                > Constantine's statement is true:
                >     IF you don't use an agile method, THEN you don't
                >   need competent and experienced people.
                > People can hide incompetence behind voluminous process. It is
                > also found in droves in the whole
                > Mgt By Objectives (MBO) bull-crap.

                > In these sorts of organizations/teams/processes, it is easy to mistake activity for progress.

                > 2) It is harder to do agile properly because it takes wisdom and experience to make proper
                > (apparent) guesses about what is "enough" It takes guts to
                > demand frequent, tangible, working
                > results to show application feature progress (or lack thereof).

                When talking about optimizing code, some wise person once said "If
                it doesn't have to work, I can make it as fast as you want."

                The two ideas above remind me of that. What Larry Constantine
                /should/ have said is

                if you don't use an agile method
                AND YOU DON'T CARE IF YOU GET THE SOFTWARE
                then you don't need competent and experienced people.

                Heavy processes may hide incompetence, but they do not correct it.
                In the end, with incompetent people, the software won't show up on
                time, on budget, fit for purpose.

                Ron Jeffries
                www.XProgramming.com
                Prediction is very difficult, especially if it's about the future. -- Niels Bohr
              • Jon Kern
                right on! a possible corollary to AND YOU DON T CARE IF YOU GET THE SOFTWARE : Since we re going to fail at building this software anyway, we may as well
                Message 7 of 23 , May 5, 2005
                • 0 Attachment
                  right on!

                  a possible corollary to "AND YOU DON'T CARE IF YOU GET THE SOFTWARE":
                      "Since we're going to fail at building this software anyway,
                      we may as well outsource it and fail more cheaply"

                  -- jon
                  
                  


                  Ron Jeffries said the following on 5/5/2005 5:29 AM:
                  On Wednesday, May 4, 2005, at 11:03:39 PM, Jon Kern wrote:

                  >  i think in some sense, agile methods are paired with requiring competent, top-notch people
                  > because

                  >  1) It is easy to follow a rigorous, multi-step process like an automaton, churning out
                  > documents at each step, not worrying if it is helping get to
                  > the end goal or not. Hence, Larry
                  > Constantine's statement is true:
                  >       IF you don't use an agile method, THEN you don't
                  >    need competent and experienced people.
                  > People can hide incompetence behind voluminous process. It is
                  > also found in droves in the whole
                  > Mgt By Objectives (MBO) bull-crap.

                  >  In these sorts of organizations/teams/processes, it is easy to mistake activity for progress.

                  >  2) It is harder to do agile properly because it takes wisdom and experience to make proper
                  > (apparent) guesses about what is "enough" It takes guts to
                  > demand frequent, tangible, working
                  > results to show application feature progress (or lack thereof).

                  When talking about optimizing code, some wise person once said "If
                  it doesn't have to work, I can make it as fast as you want."

                  The two ideas above remind me of that. What Larry Constantine
                  /should/ have said is

                    if you don't use an agile method
                    AND YOU DON'T CARE IF YOU GET THE SOFTWARE
                    then you don't need competent and experienced people.

                  Heavy processes may hide incompetence, but they do not correct it.
                  In the end, with incompetent people, the software won't show up on
                  time, on budget, fit for purpose.

                  Ron Jeffries
                  www.XProgramming.com
                  Prediction is very difficult, especially if it's about the future. -- Niels Bohr
                • Colette Buscarini Wyman
                  - I certainly would agree with Jon for his words describes truly my experience. Agile can be quite a successful approach when the team is very competent. This
                  Message 8 of 23 , May 5, 2005
                  • 0 Attachment
                    - I certainly would agree with Jon for his words describes truly my experience.  Agile can be quite a successful approach when the team is very competent. This approach would require each member of a team to be creative (thinking outside of the box), experienced and opened/prepared to handle any situation. Additionally, there is another important factor that MUST be present.  It is the ability to be part of the team quickly and establish a strong bond/communication between each member rapidly.  
                    Colette :-)
                    ------------------------------------------------------------------------------------------------------
                    "i think in some sense, agile methods are paired with requiring competent, top-notch people because

                    1) It is easy to follow a rigorous, multi-step process like an automaton, churning out documents at each step, not worrying if it is helping get to the end goal or not. Hence, Larry Constantine's statement is true:
                        IF you don't use an agile method, THEN you don't
                      need competent and experienced people.
                    People can hide incompetence behind voluminous process. It is also found in droves in the whole Mgt By Objectives (MBO) bull-crap.

                    In these sorts of organizations/teams/processes, it is easy to mistake activity for progress.

                    2) It is harder to do agile properly because it takes wisdom and experience to make proper (apparent) guesses about what is "enough" It takes guts to demand frequent, tangible, working results to show application feature progress (or lack thereof).

                    Conversely, it is easy to abuse, for example, XP with incompetent execution.

                    People, process, tools. Good people are all you need. In a process vacuum, they will invent process. Even if all vendors were vaporized, good people will develop tools.

                    -- jon"
                     


                    Do you Yahoo!?
                    Yahoo! Small Business - Try our new resources site!
                  • aacockburn
                    I am really frustrated with Yahoo, because for the second time, yesterday, I wrote a long, exhausting post, and did it online just so that it would
                    Message 9 of 23 , May 5, 2005
                    • 0 Attachment
                      <OT vent> I am really frustrated with Yahoo, because for the second
                      time, yesterday, I wrote a long, exhausting post, and did it online
                      just so that it would get posted promptly, and it got lost. Now I'm
                      afraid to write long detailed postings online here. arghhhhh! </OT
                      vent>

                      The post I wrote goes through the logic showing that according to
                      basic logic, Larry's saying really means: "If you want software to
                      come out, you need competent and experienced people, and that is
                      independent of what method you use." ... which, if he'd really said,
                      (a) wouldn't cast any aspersions on agile, and (b) would immediately
                      shift the conversation to the more meaningful and fruitful topics of
                      how do I tell if someone is that, and how do we hire and retain those
                      people.

                      (Short of the long append: There is a thing called a "cognitive
                      illusion", and the human brain immediately jumps to the inverse of a
                      statement, not the converse. So when Larry says, IF you want to
                      succeed
                      using agile THEN you need C&E people, the brain leaps to the false
                      consequence: IF you want to succeed and don't do agile THEN you don't
                      need C&E people, when it should really leap to: IF you don't have C&E
                      people THEN agile won't give you success (which leads right into
                      Ron's
                      statement below.))

                      So I'll copy this posting into my copy/paste buffer, and try sending
                      it
                      into the bowels of Yahoo.
                      Alistair

                      --- In agile-usability@yahoogroups.com, Ron Jeffries
                      <ronjeffries@X...>
                      wrote:

                      > The two ideas above remind me of that. What Larry Constantine
                      > said is
                      >
                      > if you don't use an agile method
                      > AND YOU DON'T CARE IF YOU GET THE SOFTWARE
                      > then you don't need competent and experienced people.
                      >
                      > Heavy processes may hide incompetence, but they do not correct it.
                    • aacockburn
                      It just dawned on me why I wouldn t have noticed or cared about the first example you gave, Hugh --- I show up to write use cases, and we need to write a use
                      Message 10 of 23 , May 5, 2005
                      • 0 Attachment
                        It just dawned on me why I wouldn't have noticed or cared about the
                        first example you gave, Hugh --- I show up to write use cases, and we
                        need to write a use case for any system function whether it is used
                        hourly or once a blue moon. This is a crucial difference
                        in "requirements gathering" (what exactly should the system do)
                        and "envisioning" and "usability" (how and how much does it improve
                        the life of the user/organization).

                        In envisioning and usability, frequency and the related ROI matter
                        hugely. In writing a functional spec, we just need to know that it
                        gets done ever. Thus, if users tell me this use case is the 60% item,
                        I'll make a note of that for other people on the project to worry
                        about, and collect the use case. If they tell me this use case is
                        just to handle the odd-ball situation, I'll make a note of that for
                        other people on the project to worry about, and collect the use
                        case. My goal is to capture /all/ and not miss one. Your goal is to
                        identify the ROI factor.


                        The second case below is different. That falls into
                        my "capture /all/" bucket, and so I am all ears listening and
                        questioning, looking for all the infrequent, oddball, not-officially-
                        supported pathways. That's where I get a clam-level tipoff... and at
                        that point I head straight for the surface and above, asking them
                        what is on their minds, why they would be doing that --- I don't try
                        to deduce what is on their minds from the clam-level data - I simply
                        ask them. And my experience here (without having any other reference
                        point) is that they DO report reliably in this situation. ...

                        Consider, if you will the second case you report on: "we saw people
                        doing something called "roll transfers"-tossing a stack of wafers
                        from one carrier to another without using the machine that was
                        especially designed for the purpose-in violation of procedure. We
                        might, with good facilitation have discovered that people break the
                        rules this way. We would not, I think, have understood why people
                        risk their jobs (or at least their performance appraisals) to do this
                        kind of transfer when they don't have to. "

                        So I'll offer that the reverse is true of what you just wrote: that
                        using facilitatin it is hard to DETECT that situation - role playing
                        and observation are helpful here - but having detected it, we can
                        UNDERSTAND the 'why' using facilitation.

                        Here's my matching example... we're talking about giving medications
                        in a hospital using a new barcode reader gadget. We're showing some
                        draft use cases to a team that had done a beta test with some hand-
                        held / bar code reader device for a month. We're talking about
                        scanning the meds at the bed side, and one of the nurses says, "Do we
                        have to be at the bedside? I used to carry a bar code of patient in
                        my pocket and scan everything in the prep room..." We all got stuck
                        at that moment, because it was clear that she was circumventing
                        something fundamental in the way that system had been set up (to be
                        done only at the patient bedside). After some hemming and hawing in
                        the room, we asked her, "Why would you be doing that? If we're going
                        to design a new system, it should support what you're trying to do,
                        so what were you trying to do?" And she said, "It's to save face in
                        front of the patient - I don't want to get to the bed and find I have
                        the wrong dose or something." After which, the other nurses agreed to
                        this.

                        What was serendipidous was her mentioning it. What wasn't
                        serendipidous was her being able to say why she was doing it. I don't
                        think we needed weeks of observation and note taking to deduce this;
                        it was enough just to ask her.

                        We have since written a use case called "Optionally pre-check the
                        meds", and are finding it popular among the nursing staff in the
                        various hospitals once they read and are reminded what it is for
                        (that there is no actual med administration going on, it is only
                        for "peace of mind"). And it has triggered in their minds various
                        situations that matter to us about where they might be standing with
                        this that or the other medication needing this that or the other bit
                        of procedure, so that we can write the requirements to support ALL
                        the places and behaviors they will need (however rare), while
                        prohibiting the specific ones the law and the hospital prohibits.

                        Reminder: we were lucky in this, because we got to talk to a team
                        that had used a scanner for a month, so we had their memories to work
                        with. I don't think we would have discovered this 'optionally
                        recheck' use case without those memories. The people who originally
                        designed that scanner system didn't have that luxury.

                        Thus I motivate the need for clam-level details, and that these are
                        hard to come by in facilitated sessions (ergo, the facilitator has to
                        deliberately work out ways to get clam-level stuff to pop out).

                        However, I argue that facilitation works fine for discovering the
                        Why, and that self-reporting is quite reliable here.

                        Alistair




                        --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
                        wrote:
                        > On practically the first project we worked on as a business, the
                        user
                        > population consisted of system managers, who uniformly reported
                        that 60-70%
                        > of their work was focused on diagnosis and troubleshooting of
                        failing
                        > systems. CI field interviews revealed that maybe 10-20% of their
                        work was
                        > diagnosis and troubleshooting. Most of their time was spent on
                        routine
                        > maintenance tasks. We've found this is typical-users can't tell you
                        how they
                        > allot their time really-they put too much emphasis on what is
                        the "real"
                        > job, the interesting, valuable, knowledge work, and overlook the
                        time spent
                        > on "unimportant" parts of the job.
                        >
                        >
                        >
                        > On another project, we were studying chip fabrication. We were told
                        how
                        > rigid all their requirements were for handling the wafers and how
                        carefully
                        > they were followed. But when we observed, we saw people doing
                        something
                        > called "roll transfers"-tossing a stack of wafers from one carrier
                        to
                        > another without using the machine that was especially designed for
                        the
                        > purpose-in violation of procedure. We might, with good facilitation
                        have
                        > discovered that people break the rules this way. We would not, I
                        think, have
                        > understood why people risk their jobs (or at least their performance
                        > appraisals) to do this kind of transfer when they don't have to.
                        >
                        >
                      • aacockburn
                        I read The world is flat (I give it a C-, worth a quick scan), and thought, along these lines, that what we are saying is, We don t know how to manage a
                        Message 11 of 23 , May 5, 2005
                        • 0 Attachment
                          I read "The world is flat" (I give it a C-, worth a quick scan), and
                          thought, along these lines, that what we are saying is, "We don't know
                          how to manage a project over here. Perhaps if we go sufficiently far
                          away, the people over there know how to do it (answer: they don't). And
                          if they don't, then at least the mess is over there compared to over
                          here, and the mess is cheaper."

                          Of course, I'm interested in learning how to manage a project /over
                          here/ (for any 'here')

                          AListair


                          --- In agile-usability@yahoogroups.com, Jon Kern <jonkern@c...> wrote:
                          > a possible corollary to "AND YOU DON'T CARE IF YOU GET THE SOFTWARE":
                          "Since we're going to fail at building this software anyway,
                          we may as well outsource it and fail more cheaply"
                        • Jeff Patton
                          ... show up in ... painter ... then an ... whole ... the role ... giraffe level, ... Oddly, it s metaphors like this one I see used often that suggests moving
                          Message 12 of 23 , May 5, 2005
                          • 0 Attachment
                            --- In agile-usability@yahoogroups.com, "Hugh Beyer" <beyer@i...>
                            wrote:
                            > It's an important distinction, and I'd be surprised if it didn't
                            show up in
                            > some form or other. We talk about developing a design the way a
                            painter
                            > develops an oil painting-rather than working on the hand in detail,
                            then an
                            > eye, then the other hand, then an ear, the painter sketches in the
                            whole
                            > painting in rough-gets all the parts in right relationship to each
                            > other-then goes in and fills in the detail. In our process, this is
                            the role
                            > of visioning-to sketch the overall high-level vision (kite to
                            giraffe level,
                            > depending on the project) which can then be refined in detail.

                            Oddly, it's metaphors like this one I see used often that suggests
                            moving one direction - top down - or more abstract to more detailed.
                            If I leverage the oil painting metaphor, I think I'm hearing that in
                            practice you might do an underpainting, rough things in, then
                            actually zoom to paint an eye, or a hand, then change your mind and
                            zoom back out to an abstract level, and adjuste the underpainting,
                            then zoom back in and change the detailed hand to a foot. Does that
                            make sense? So, I guess that's what I'm asserting - books that
                            describe what people should do tend to imply design works in one
                            direction - but in practice, I'm not so sure.

                            thanks for posting Hugh!

                            -Jeff
                          • Jeff Patton
                            ... further. Master painters will work out the intricate details of a painting in a sketchbook. (XPers call this a spike solution.) Once they have figured
                            Message 13 of 23 , May 5, 2005
                            • 0 Attachment
                              --- In agile-usability@yahoogroups.com, Rob Keefer <rbkeefer@y...>
                              wrote:
                              > I'd like to take Hugh's analogy to the painter a step
                              further. 'Master' painters will work out the intricate details of a
                              painting in a sketchbook. (XPers call this a spike solution.) Once
                              they have figured out the detail, it is then applied to the main
                              composition.
                              >

                              Yeah - that's what I mean. I believe that in practice I see a fair
                              bit of elaboration and playing with details, then zooming back out to
                              abstract.

                              Ironically Hugh gave an example in another post of support people
                              reporting they spend a large percentage of their time on
                              troubleshooting when in actuality his group had observed otherwise.
                              The implication is that people aren't good at self reporting. Is it
                              possible that when we ask designers what they're doing and they give
                              this painting metaphor that they're not self reporting accurately? ;-)

                              Glad you posted that Rob.

                              -Jeff
                            • Jon Kern
                              i always say... if you have convinced yourself that you can t get it done locally, what in the heck are you thinking that 12 time zones away is going to be
                              Message 14 of 23 , May 6, 2005
                              • 0 Attachment
                                i always say...
                                    "if you have convinced yourself that you can't get it done locally, what in the heck are you thinking that 12 time zones away is going to be easier?"
                                go figure...
                                -- jon
                                
                                


                                aacockburn said the following on 5/5/2005 11:38 AM:
                                I read "The world is flat" (I give it a C-, worth a quick scan), and
                                thought, along these lines, that what we are saying is, "We don't know
                                how to manage a project over here. Perhaps if we go sufficiently far
                                away, the people over there know how to do it (answer: they don't). And
                                if they don't, then at least the mess is over there compared to over
                                here, and the mess is cheaper."

                                Of course, I'm interested in learning how to manage a project /over
                                here/ (for any 'here')

                                AListair


                                --- In agile-usability@yahoogroups.com, Jon Kern <jonkern@c...> wrote:
                                > a possible corollary to "AND YOU DON'T CARE IF YOU GET THE SOFTWARE":
                                    "Since we're going to fail at building this software anyway,
                                    we may as well outsource it and fail more cheaply"



                              • aacockburn
                                ... Yep. I ve interviewed and done the ethnographic stuff on developers, and one has to doublecheck most of what they claim. I even assume that when I describe
                                Message 15 of 23 , May 6, 2005
                                • 0 Attachment
                                  --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...>
                                  wrote:
                                  > The implication is that people aren't good at self reporting. Is it
                                  > possible that when we ask designers what they're doing and they give
                                  > this painting metaphor that they're not self reporting accurately? ;-)

                                  Yep. I've interviewed and done the ethnographic stuff on developers,
                                  and one has to doublecheck most of what they claim. I even assume that
                                  when I describe how I do my ethnographic stuff that I'm lying some
                                  unknown percent of the time. Now don't you feel reassured? ;-))
                                • Ron Jeffries
                                  ... I do. I wasn t sure you knew that. :) Ron Jeffries www.XProgramming.com I could be wrong. I frequently am.
                                  Message 16 of 23 , May 6, 2005
                                  • 0 Attachment
                                    On Friday, May 6, 2005, at 7:19:47 PM, aacockburn wrote:

                                    > --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...>
                                    > wrote:
                                    >> The implication is that people aren't good at self reporting. Is it
                                    >> possible that when we ask designers what they're doing and they give
                                    >> this painting metaphor that they're not self reporting accurately? ;-)

                                    > Yep. I've interviewed and done the ethnographic stuff on developers,
                                    > and one has to doublecheck most of what they claim. I even assume that
                                    > when I describe how I do my ethnographic stuff that I'm lying some
                                    > unknown percent of the time. Now don't you feel reassured? ;-))

                                    I do. I wasn't sure you knew that. :)

                                    Ron Jeffries
                                    www.XProgramming.com
                                    I could be wrong. I frequently am.
                                  Your message has been successfully submitted and would be delivered to recipients shortly.