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

1166Re: [agile-usability] Re: elite methods

Expand Messages
  • Jon Kern
    May 4 9:03 PM
    • 0 Attachment
      i think in some sense, agile methods are paired with requiring competent, top-notch people because

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

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

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

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

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

      -- jon
      
      


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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

      Sorry for the long posting,
      Alistair




    • Show all 23 messages in this topic