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

Re: [agile-usability] Re: elite methods

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.