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

FW: [XP] Re: Stop crippling agile, back to basics

Expand Messages
  • Marvin D. Toll
    Ron, You caught me at an emotional moment. We just completed Day1 of our weeklong Java Application Development (for experienced JEE and Struts folks) class in
    Message 1 of 65 , Jun 21, 2010
      Ron,

      You caught me at an emotional moment. We just completed Day1 of our
      weeklong Java Application Development (for experienced JEE and Struts folks)
      class in North America. It is our final pilot of the hands-on material
      before a v. 1.0 release

      It already looks like 3 of the 12 participants will not be able to complete
      the course because of inadequate skills. We end the first blisteringly
      face-paced day with a simple unit test for an exception (we are an
      Incontainer Test Shop so use JUnit v. 3 with Cactus).

      A fourth individual (who can complete the work) was loudly passionate while
      arguing that two distinct individuals should be involved (not a pair)... one
      to independently write the JUnit test and the other to independently write
      the code.

      So the bottom line? We have tremendous turn-over in India (as you mentioned
      in your post) AND commodity players in North America, some of whom are very
      strong-willed.

      So the principle that:

      The best architectures, requirements, and designs
      emerge from self-organizing teams.

      ... seems like a page from someone elses playbook. My perception is that
      the 'Agile Manifesto' was not optimized for today's 'commodity' players.

      For example, in the Detroit area when one company recently began their
      'Enterprise Agile Transformation' they hired some of the best folks around
      town. They did not even attempt 'Agile' without upgrading their skillset.

      Thus the basis for my desire to collaborate on a 'Manifesto' focused on
      'players' of average skill in a commodity-based world of transient
      (preferably low-cost) labor. If someone has a stable team that can produce
      "the best architectures and designs" on their own great. However, for those
      of us that live in another place some guidance in the form of 'principles'
      might be appreciated.

      _Marvin

      -----Original Message-----
      From: Ron Jeffries [mailto:ronjeffriesacm@...] On Behalf Of Ron
      Jeffries
      Sent: Monday, June 21, 2010 10:37 AM
      To: extremeprogramming@yahoogroups.com
      Subject: Re: [XP] Re: Stop crippling agile, back to basics

      It is at least true that results depend on the quality of players...

      But there surely are interesting corners in the space. Our friend
      Marvin Toll is working up a process to be used when most of your
      software is done by very short term remote contractors. Chet and I
      mostly say "Don't do that", which is the best advice we have but not
      likely to be acted upon. So Marvin is working up a framework which
      is very simple, and which everyone must use, so that at least
      software looks "the same", so that the future very short term remote
      contractors have a shot at maintaining the software written by the
      past very short term remote contractors.

      Now, I would not want to call this approach "Agile". It is, of
      course adaptive in some sense, and it may be the best idea available
      to Marvin. So I'd call it a good idea, and feel that calling it
      "Agile" is one more step on the road to everything anyone does being
      appropriate Agile.

      So here is a case where maybe the "better" thing to do would be not
      to use very short term remote contractors, but the "best available"
      thing to do is to draw a card from the Classical Methods deck and
      build a framework. It is certainly an example of what you, Scott,
      are talking about, where the more formal approach offers a technique
      addressing the [abysmally low] quality of the players.

      Yes. And will this be a function of the "quality" of the
      practitioner? (Answer: Surely yes.)

      My focus, like many of us here, is on the middle- to high-end of the
      developer population, the group who are pretty good and want to be
      better. Marvin's focus on a different part of the population may
      well result in a different set of strategies.

      Now I think that many of us who have been at the core of Agile are
      focused on that high-quality kind of craftsmanship in development. I
      do think that the Agile techniques reach pretty far down into the
      development quality barrel, because they are easily learned by
      anyone of even moderate competence who wants to learn. Whether they
      reach all the way down, no one knows. And if your people, like
      Marvin's, may not be around a few months from now, then maybe it
      really doesn't pay to invest in them.

      I think that's probably a sin. But it might be good business.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Logic is overrated as a system of thought.
    • Ron Jeffries
      ... Sure ... Ron Jeffries www.XProgramming.com www.xprogramming.com/blog The fact that we know more today, and are more capable today, is good news about
      Message 65 of 65 , Jul 23, 2010
        Hello, Jeff. On Friday, July 23, 2010, at 7:52:49 AM, you wrote:

        >> Yes. I only have one major issue with your cards, which is that I
        >> didn't think of it and do it first. That wouldn't be so bad if you
        >> were screwing them up but unfortunately they're great.

        > Drat. Sorry about that. Many thanks, though.

        > That would be a great inclusion on a card to be included in the deck
        > ("Four out of Five Experts Agree", or something like that), if you're
        > willing to offer up the quote.

        Sure ...

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        The fact that we know more today, and are more capable today,
        is good news about today, not bad news about yesterday.
      Your message has been successfully submitted and would be delivered to recipients shortly.