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

zooming, porpoising, and goal level

Expand Messages
  • Jeff Patton
    So, I d wondered in an earlier thread if designers mostly work top down or bottom up, and I think my answer was yes. That is to say, both are important, but
    Message 1 of 23 , Apr 28, 2005
      So, I'd wondered in an earlier thread if designers mostly work top down or
      bottom up, and I think my answer was "yes." That is to say, both are
      important, but at different times for different reasons.

      This idea of goal level, or abstraction level, and the comparison of goals
      at a high level to the smaller goals at another level seems pretty critical
      to what we're doing. The idea that upper level goals are validated against
      real world observation of the activities people are doing and the context
      they do them also seems critical.

      Anita used the term zooming. I grabbed at the term porpoising - sorta to
      suggest that that like a porpoise, I spend more time below the surface, but
      keep jumping up to look around, but always land back in the water. Given
      that looking up and down across goal/abstraction level is so important, I'm
      curious if anyone knows if an author has called attention to, and named this
      activity? Or, is this all pretty obvious, and terms like zooming are good
      enough to explain to others what we're doing?

      Going back full circle, I thought I had detected that written down
      methodologies /do/ favor one method of thinking over another... but I'm
      hearing from practitioners otherwise. I'm not very well read, but in the
      few books I have read, and the few people I have worked with, I don't recall
      anyone drawing attention to this concept as critical. Is it too obvious, or
      did I overlook the message when I heard it?

      I'd love to hear feedback and comments on this.

      Thanks,

      -Jeff

      -----------
      Jeff Patton
      ThoughtWorks
      www.abstractics.com/papers
      Agile usability discussion group:
      http://groups.yahoo.com/group/agile-usability/

      XP 2005 (Sheffield, UK) Agile User Experience Tutorial:
      http://www.xp2005.org

      UPA (Montreal, Quebec) Agile-UCD Tutorial:
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
      tivity.php?id=179
      Agile-Usability Workshop:
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
      tivity.php?id=156

      Agile 2005 (Denver, CO) Agile User Experience Tutorial, Agile Code Metrics
      Tutorial: http://www.agile2005.org/

      "There is nothing that saps one's confidence as the knowing how to do a
      thing."
      --Mark Twain
    • William Wake
      ... A reference I ve carried around for a long time: Designing the Design Process: Exploiting Opportunistic Thoughts , by Raymonde Guindon. Human-Computer
      Message 2 of 23 , Apr 28, 2005
        On 4/28/05, Jeff Patton <jpatton@...> wrote:
        > So, I'd wondered in an earlier thread if designers mostly work top down or
        > bottom up, and I think my answer was "yes." That is to say, both are
        > important, but at different times for different reasons.

        > Anita used the term zooming. I grabbed at the term porpoising - sorta to
        > suggest that that like a porpoise, I spend more time below the surface, but
        > keep jumping up to look around, but always land back in the water. Given
        > that looking up and down across goal/abstraction level is so important, I'm
        > curious if anyone knows if an author has called attention to, and named this
        > activity? Or, is this all pretty obvious, and terms like zooming are good
        > enough to explain to others what we're doing?

        A reference I've carried around for a long time: "Designing the Design
        Process: Exploiting Opportunistic Thoughts", by Raymonde Guindon.
        Human-Computer Interaction, 1990, V5, pp. 305-344.

        A phrase in my notes is "opportunistic design decomposition". The
        article has a nice picture showing attention going back and forth
        between high- and low-level concerns.

        It was based on analysis of a relatively small set of design sessions
        (software design, not user interface design), but I've taken it as a
        characteristic of design in general, not just of software. (Even
        watching some of the Lego "Serious Games" stuff, in the physical
        domain - sometimes people are working from an overall vision, other
        times they're playing with various ways parts can connect while they
        look for inspiration.)

        --
        Bill Wake William.Wake@... www.xp123.com
      • Brian Marick
        ... I had the impression that was received wisdom these days. Here s a bit from an article Mike Cohn wrote in the February Better Software: In 1990, Raymonde
        Message 3 of 23 , Apr 28, 2005
          On Apr 28, 2005, at 9:15 AM, Jeff Patton wrote:
          > Anita used the term zooming. I grabbed at the term porpoising - sorta
          > to
          > suggest that that like a porpoise, I spend more time below the
          > surface, but
          > keep jumping up to look around, but always land back in the water.
          > Given
          > that looking up and down across goal/abstraction level is so
          > important, I'm
          > curious if anyone knows if an author has called attention to, and
          > named this
          > activity? Or, is this all pretty obvious, and terms like zooming are
          > good
          > enough to explain to others what we're doing?

          I had the impression that was received wisdom these days. Here's a bit
          from an article Mike Cohn wrote in the February Better Software:

          "In 1990, Raymonde Guindon confirmed this by studying a group of
          designers to whom she posed a problem. She happened to study elevator
          designers but the implications are equally relevant for software
          developers. Guindon paid particular attention to whether the designers
          were thinking top-down or bottom-up at any moment. She created charts
          similar to the ones shown in Figure 1. The light bulbs indicate where a
          designer had an epiphany or breakthrough in his or her thinking. As you
          can see from Figure 1, designers (and programmers) move freely between
          top-down and bottom-up thinking."

          (Figure 1 shows a very jagged graph, with light bulbs occurring at all
          levels. The draft I'm quoting from doesn't have the references. I'll
          look for them sometime after I get out of this airport.)

          -----
          Brian Marick, independent consultant
          Mostly on agile methods with a testing slant
          www.exampler.com, www.testing.com/cgi-bin/blog
          Book in progress: www.exampler.com/book
        • nemrac_z
          Hello, I also like the idea of design as a problem structuring activity, which works well with opportunistic design. We have numerous design problems that
          Message 4 of 23 , Apr 29, 2005
            Hello,

            I also like the idea of design as a problem structuring activity,
            which works well with opportunistic design. We have numerous design
            problems that fall on a continuum of structure. Decisions that we
            make about these problems (which vary in structure) "can lead to
            subsequent decisions at various levels of abstraction". And I connect
            the word abstraction with structure (if thats not too big a leap).

            Much of that (including the quote) is taken from Guindon's Designing
            the Design Process, as well as from Simon (1973) "The structure of
            ill structured problems"; Artificial Intelligence, 4, 14-180.

            What doesn't seem to be continuously emphasized is the idea that
            small/low level/well-structured decisions probably impact big/high
            level/not-as-well-structured decisions. Not just the other
            way around. Cause to me, thats a significant portion of opportunistic
            design.

            Carmen



            --- In agile-usability@yahoogroups.com, Brian Marick <marick@t...>
            wrote:
            >
            > On Apr 28, 2005, at 9:15 AM, Jeff Patton wrote:
            > > Anita used the term zooming. I grabbed at the term porpoising -
            sorta
            > > to
            > > suggest that that like a porpoise, I spend more time below the
            > > surface, but
            > > keep jumping up to look around, but always land back in the
            water.
            > > Given
            > > that looking up and down across goal/abstraction level is so
            > > important, I'm
            > > curious if anyone knows if an author has called attention to, and
            > > named this
            > > activity? Or, is this all pretty obvious, and terms like zooming
            are
            > > good
            > > enough to explain to others what we're doing?
            >
            > I had the impression that was received wisdom these days. Here's a
            bit
            > from an article Mike Cohn wrote in the February Better Software:
            >
            > "In 1990, Raymonde Guindon confirmed this by studying a group of
            > designers to whom she posed a problem. She happened to study
            elevator
            > designers but the implications are equally relevant for software
            > developers. Guindon paid particular attention to whether the
            designers
            > were thinking top-down or bottom-up at any moment. She created
            charts
            > similar to the ones shown in Figure 1. The light bulbs indicate
            where a
            > designer had an epiphany or breakthrough in his or her thinking. As
            you
            > can see from Figure 1, designers (and programmers) move freely
            between
            > top-down and bottom-up thinking."
            >
            > (Figure 1 shows a very jagged graph, with light bulbs occurring at
            all
            > levels. The draft I'm quoting from doesn't have the references.
            I'll
            > look for them sometime after I get out of this airport.)
            >
            > -----
            > Brian Marick, independent consultant
            > Mostly on agile methods with a testing slant
            > www.exampler.com, www.testing.com/cgi-bin/blog
            > Book in progress: www.exampler.com/book
          • Kay Burnett
            Hi-- your title line caught my eye as I try desperately to cope with weeks of unread messages. I know the phenomena of which you speak -- I call it
            Message 5 of 23 , May 3, 2005
              Hi--
              your title line caught my eye as I try desperately to cope with weeks of unread messages.
               
              I know the phenomena of which you speak -- I call it deconstructing & reconstructing -- and its like breathing -- once you've done one you follow it with the other, and so on, and so on...until you have something you like.
               
              I'm vasillating on whether it is a method or just a way of practicing a method of analysis and synthesis. Basically, in analysis you break things down into their granular parts and look at the parts and in synthesis you build things back adding, tweaking, removing parts and assessing the thing being built.
               
              I hear the germs of this kind of behavior in porpoising and zooming...
               
              Kay Burnett
              Information Architect

              Jeff Patton <jpatton@...> wrote:
              So, I'd wondered in an earlier thread if designers mostly work top down or
              bottom up, and I think my answer was "yes."  That is to say, both are
              important, but at different times for different reasons. 

              This idea of goal level, or abstraction level, and the comparison of goals
              at a high level to the smaller goals at another level seems pretty critical
              to what we're doing.  The idea that upper level goals are validated against
              real world observation of the activities people are doing and the context
              they do them also seems critical. 

              Anita used the term zooming.  I grabbed at the term porpoising - sorta to
              suggest that that like a porpoise, I spend more time below the surface, but
              keep jumping up to look around, but always land back in the water.  Given
              that looking up and down across goal/abstraction level is so important, I'm
              curious if anyone knows if an author has called attention to, and named this
              activity?  Or, is this all pretty obvious, and terms like zooming are good
              enough to explain to others what we're doing?

              Going back full circle, I thought I had detected that written down
              methodologies /do/ favor one method of thinking over another... but I'm
              hearing from practitioners otherwise.  I'm not very well read, but in the
              few books I have read, and the few people I have worked with, I don't recall
              anyone drawing attention to this concept as critical.  Is it too obvious, or
              did I overlook the message when I heard it?

              I'd love to hear feedback and comments on this.

              Thanks,

              -Jeff 

              -----------
              Jeff Patton
              ThoughtWorks
              www.abstractics.com/papers
              Agile usability discussion group:
              http://groups.yahoo.com/group/agile-usability/

              XP 2005 (Sheffield, UK) Agile User Experience Tutorial:
              http://www.xp2005.org

              UPA (Montreal, Quebec) Agile-UCD Tutorial:
              http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
              tivity.php?id=179
              Agile-Usability Workshop:
              http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
              tivity.php?id=156

              Agile 2005 (Denver, CO) Agile User Experience Tutorial, Agile Code Metrics
              Tutorial: http://www.agile2005.org/

              "There is nothing that saps one's confidence as the knowing how to do a
              thing."
              --Mark Twain





              Yahoo! Groups Links

              __________________________________________________
              Do You Yahoo!?
              Tired of spam? Yahoo! Mail has the best spam protection around
              http://mail.yahoo.com

            • Hugh Beyer
              Jeff Patton: This idea of goal level, or abstraction level, and the comparison of goals at a high level to the smaller goals at another level seems pretty
              Message 6 of 23 , May 3, 2005

                Jeff Patton: "This idea of goal level, or abstraction level, and the comparison of goals
                at a high level to the smaller goals at another level seems pretty critical
                to what we're doing.  The idea that upper level goals are validated against
                real world observation of the activities people are doing and the context
                they do them also seems critical [ . . . ] I'm not very well read, but in the
                few books I have read, and the few people I have worked with, I don't recall
                anyone drawing attention to this concept as critical.  Is it too obvious, or
                did I overlook the message when I heard it?”

                 

                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.

                 

                Alistair Cockburn: “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? 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.

                 

                Alistair Cockburn: “Perhaps you can post a couple of the most interesting surprises you've
                uncovered in the clam-up analyses you've run?  Of course, what Jeff
                and I discovered is that lots of things look obvious after they've been
                named. Our analysis should cover exactly what bits of discussion
                amongst the analysts triggered the discovery of those items.”

                 

                You ask a fair question… on the one hand every project reveals such surprises, on the other most of it belongs to our clients. Others have offered good answers to this, but here’s two quick examples off the top of my head.

                 

                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.

                 

                Alistair Cockburn: “In fact it's pretty much a tautology that weak practitioners 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.”

                 

                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.

                 

                I’m currently working with a client who spent two months traveling around the world spending days with over 80 users. I guarantee you that even an untrained designer or even (horror of horrors) developer would, after such an experience, design a much more suitable system than one who had only conducted focus groups. In the same way a rapid-iteration agile process will make it much harder to develop the wrong system without knowing it.

                 

                            Hugh

                 

                Hugh R. Beyer, CTO
                InContext
                Ph: 603 966-7188
                Email: beyer@...

                 

              • Rob Keefer
                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
                Message 7 of 23 , May 3, 2005
                  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.
                   
                  I wonder if this is what is going on when we look at the clam level. Working out details with particular users helps find solutions to particular problems that can then be placed in a larger context.
                   

                  Hugh Beyer <beyer@...> wrote:

                  Jeff Patton: "This idea of goal level, or abstraction level, and the comparison of goals
                  at a high level to the smaller goals at another level seems pretty critical
                  to what we're doing.  The idea that upper level goals are validated against
                  real world observation of the activities people are doing and the context
                  they do them also seems critical [ . . . ] I'm not very well read, but in the
                  few books I have read, and the few people I have worked with, I don't recall
                  anyone drawing attention to this concept as critical.  Is it too obvious, or
                  did I overlook the message when I heard it?�

                   

                  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.

                   

                  Alistair Cockburn: �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? 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.

                   

                • aacockburn
                  ... wrote: AC:
                  Message 8 of 23 , May 4, 2005
                    --- 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 9 of 23 , May 4, 2005
                      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 10 of 23 , May 4, 2005

                         

                        --- 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 11 of 23 , May 4, 2005
                          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 12 of 23 , May 4, 2005
                            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 13 of 23 , May 5, 2005
                              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 14 of 23 , May 5, 2005
                                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 15 of 23 , May 5, 2005
                                  - 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 16 of 23 , May 5, 2005
                                    <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 17 of 23 , May 5, 2005
                                      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 18 of 23 , May 5, 2005
                                        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 19 of 23 , May 5, 2005
                                          --- 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 20 of 23 , May 5, 2005
                                            --- 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 21 of 23 , May 6, 2005
                                              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 22 of 23 , May 6, 2005
                                                --- 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 23 of 23 , May 6, 2005
                                                  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.