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

Re: [XP] Misunderstanding and re-writing the manifesto

Expand Messages
  • Steve Berczuk
    ... What always fascinated me about this dynamic is why people feel a need to call what they are doing agile. Why not instead say I read something about
    Message 1 of 13 , Sep 7, 2013
      On Wed, Aug 28, 2013 at 12:22 PM, Kay <tranzpupy@...> wrote:
      > Since I've been a member of this list since 2002 – I've seen and heard a lot of "lies" and misunderstandings about what XP (and "Agile" IS. I just overheard a webinar where the speaker implied that the manifesto said a'tools and processes were NOT important-- the speaker said "WE (the contracting company) think tools and processes are *VERY* important" AAAGGGGHHHHH! They ALSO said "we Will still be doing requirements, but we will CALL them "user stories" OMG "Agile" is truly dead….
      > I plan to cry a lot tonight.


      What always fascinated me about this dynamic is why people feel a need
      to call what they are doing "agile." Why not instead say " I read
      something about Agile, I don't want to do that, but maybe I'll borrow
      some ideas.." Borrowing some ideas won't really work well as the
      practices interact... but at least it is honest...

      The other day I was on the T (which is the name we Boston area
      residents use for "the Subway" :) ) and I over heard 2 people talking
      about "how 'Steve' [another steve, not me] is getting all agile on
      us..." and "how agile says <something agile doesn't actually say>" and
      "how that just /can't/ work for our situation."
      The confidence with which the person said the last bit is probably
      the core problem.

      Steve
      --
      Steve Berczuk | steve.berczuk@... | http://www.berczuk.com
      Twitter: @sberczuk
      ADN: @spb
      SCM Patterns: www.scmpatterns.com
    • Larry Brunelle
      ... When I see such posts, I m reminded of the one-time currency of TQM and Deming methods. These ideas worked fabulously well for Japanese manufacturing
      Message 2 of 13 , Sep 7, 2013
        Steve Berczuk wrote:> On Wed, Aug 28, 2013 at 12:22 PM, Kay <tranzpupy@...> wrote:
        >> Since I've been a member of this list since 2002 – I've seen and heard a lot of "lies" and misunderstandings about what XP (and "Agile" IS. I just overheard a webinar where the speaker implied that the manifesto said a'tools and processes were NOT important-- the speaker said "WE (the contracting company) think tools and processes are *VERY* important" AAAGGGGHHHHH! They ALSO said "we Will still be doing requirements, but we will CALL them "user stories" OMG "Agile" is truly dead….
        >> I plan to cry a lot tonight.
        >
        >
        > What always fascinated me about this dynamic is why people feel a need
        > to call what they are doing "agile." Why not instead say " I read
        > something about Agile, I don't want to do that, but maybe I'll borrow
        > some ideas.." Borrowing some ideas won't really work well as the
        > practices interact... but at least it is honest...
        >
        > The other day I was on the T (which is the name we Boston area
        > residents use for "the Subway" :) ) and I over heard 2 people talking
        > about "how 'Steve' [another steve, not me] is getting all agile on
        > us..." and "how agile says <something agile doesn't actually say>" and
        > "how that just /can't/ work for our situation."
        > The confidence with which the person said the last bit is probably
        > the core problem.
        >
        > Steve
        >

        When I see such posts, I'm reminded of the one-time currency
        of TQM and Deming methods. These ideas worked fabulously
        well for Japanese manufacturing concerns, for the simple
        reason they actually paid attention and actually implemented
        the methods "by the book". They believed and followed through.

        American firms, by contrast, rarely paid as close attention,
        and rarely followed throughso faithfully. Indeed, when once
        I signed up for a grad school course in TQM while being
        retreaded at the University of Michigan, I found that the
        instructor taught with an expectation that the structure to
        be found in industry would include something like a "quality
        department" where would perhaps be a head TQM guy to whom
        members of the firm would be responsible for TQM issues.
        This would, it appears to me, be entirely contrary to Deming's
        teaching that the CEO was the head TQM guy, that the change
        had to be believed in at the top and supported from the top.
        (And now Toyota has, what is it? the best selling model in
        the US?)

        "Agile", whichever species, has to be understood, believed in,
        and supported from the top to have the best traction (or even
        any at all) in the organization. What I observe is that it's
        common to believe in something BELIEVED to be "agile", especially
        if there's no requirement for executives to do the homework
        to understand what's meant.

        <Mild rant>
        Corporate America has in many quarters (certainly not all)
        exhibited a belief that "management" is an abstract discipline
        not necessarily requiring actual understanding of the business
        managed. Generally this disease seems to appear in higher-
        level executives who can negotiate one kind or another of
        golden parachute, and may seep down through the ranks. Small-
        business owners generally can't afford this luxury of non-
        understanding: if the business fails, they suffer.

        Of course, sometimes the sailors keep the ship afloat even
        with officers of questionable judgment.
        </Mild rant>
      • marcodorantes
        All these years, learning a lot from communities like this, from authors and practitioners, from my own tries to improve the quality of my software design and
        Message 3 of 13 , Nov 1, 2013

          All these years, learning a lot from communities like this, from authors and practitioners, from my own tries to improve the quality of my software design and programming, and telling others about all this good stuff of software development as a cooperative game, and still there are lots of programmers around who simply do not care enough to not just repeat the buzzwords but to behave like if they properly understood the concepts.

           

          All this make me remember what have happened with other intellectual pursuits in history. For example, very few people around me, even with several academic computing degrees, are able to articulate, in simple terms, the most general justified true beliefs from quantum theory, much less its relationship with the current computing industry. Whereas those justified true beliefs were published almost a century ago! 



          ---In extremeprogramming@yahoogroups.com, <brunelle@...> wrote:

          Steve Berczuk wrote:> On Wed, Aug 28, 2013 at 12:22 PM, Kay <tranzpupy@...> wrote:
          >> Since I've been a member of this list since 2002 – I've seen and heard a lot of "lies" and misunderstandings about what XP (and "Agile" IS. I just overheard a webinar where the speaker implied that the manifesto said a'tools and processes were NOT important-- the speaker said "WE (the contracting company) think tools and processes are *VERY* important" AAAGGGGHHHHH! They ALSO said "we Will still be doing requirements, but we will CALL them "user stories" OMG "Agile" is truly dead….
          >> I plan to cry a lot tonight.
          >
          >
          > What always fascinated me about this dynamic is why people feel a need
          > to call what they are doing "agile." Why not instead say " I read
          > something about Agile, I don't want to do that, but maybe I'll borrow
          > some ideas.." Borrowing some ideas won't really work well as the
          > practices interact... but at least it is honest...
          >
          > The other day I was on the T (which is the name we Boston area
          > residents use for "the Subway" :) ) and I over heard 2 people talking
          > about "how 'Steve' [another steve, not me] is getting all agile on
          > us..." and "how agile says <something agile doesn't actually say>" and
          > "how that just /can't/ work for our situation."
          > The confidence with which the person said the last bit is probably
          > the core problem.
          >
          > Steve
          >

          When I see such posts, I'm reminded of the one-time currency
          of TQM and Deming methods. These ideas worked fabulously
          well for Japanese manufacturing concerns, for the simple
          reason they actually paid attention and actually implemented
          the methods "by the book". They believed and followed through.

          American firms, by contrast, rarely paid as close attention,
          and rarely followed throughso faithfully. Indeed, when once
          I signed up for a grad school course in TQM while being
          retreaded at the University of Michigan, I found that the
          instructor taught with an expectation that the structure to
          be found in industry would include something like a "quality
          department" where would perhaps be a head TQM guy to whom
          members of the firm would be responsible for TQM issues.
          This would, it appears to me, be entirely contrary to Deming's
          teaching that the CEO was the head TQM guy, that the change
          had to be believed in at the top and supported from the top.
          (And now Toyota has, what is it? the best selling model in
          the US?)

          "Agile", whichever species, has to be understood, believed in,
          and supported from the top to have the best traction (or even
          any at all) in the organization. What I observe is that it's
          common to believe in something BELIEVED to be "agile", especially
          if there's no requirement for executives to do the homework
          to understand what's meant.

          <Mild rant>
          Corporate America has in many quarters (certainly not all)
          exhibited a belief that "management" is an abstract discipline
          not necessarily requiring actual understanding of the business
          managed. Generally this disease seems to appear in higher-
          level executives who can negotiate one kind or another of
          golden parachute, and may seep down through the ranks. Small-
          business owners generally can't afford this luxury of non-
          understanding: if the business fails, they suffer.

          Of course, sometimes the sailors keep the ship afloat even
          with officers of questionable judgment.
          </Mild rant>
        • Phlip
          ... Pivotal Labs, in downtown San Francisco, is a lean mean pair-programming machine, using RoR and RSpec test suites that might actually remain fast &
          Message 4 of 13 , Nov 1, 2013
            > I plan to cry a lot tonight.
            >
            > Kay Pentecost

            Pivotal Labs, in downtown San Francisco, is a lean mean
            pair-programming machine, using RoR and RSpec test suites that might
            actually remain fast & efficient. Do they count?
          • Adam Sroka
            I have been a consultant for a long time. There are plenty of good people doing really good things and plenty of people doing mediocre things for a whole lot
            Message 5 of 13 , Nov 1, 2013
              I have been a consultant for a long time. There are plenty of good people doing really good things and plenty of people doing mediocre things for a whole lot of reasons, most understandable, many silly. Cry if you need to, but don't take it personally. Find some small way that you can make the world a better place and do a little bit of that every day. 


              On Fri, Nov 1, 2013 at 12:42 PM, Phlip <phlip2005@...> wrote:
               

              > I plan to cry a lot tonight.
              >
              > Kay Pentecost

              Pivotal Labs, in downtown San Francisco, is a lean mean
              pair-programming machine, using RoR and RSpec test suites that might
              actually remain fast & efficient. Do they count?


            Your message has been successfully submitted and would be delivered to recipients shortly.