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

RE: [scrumdevelopment] Comments on Silver Bullets

Expand Messages
  • Monique L. Attinger
    Ken -- I think this article is a timely reality check . While I m not sure where you are looking to publish this, I suspect that there are multiple
    Message 1 of 14 , Jan 16, 2004
      Ken -- I think this article is a timely 'reality check'. While I'm not sure where you are looking to 'publish' this, I suspect that there are multiple audiences who could benefit: 1) non-IT management who think that we can do more and more with less and less until we are making everything out of nothing, and 2) IT professionals who have bought into the myth that there is some kind of way to build software which takes away the difficulty of working with other people and who think everything would be fine if only they didn't have to deal with 'end losers'.
       
      Monique Attinger
      -----Original Message-----
      From: Ken Schwaber [mailto:ken.schwaber@...]
      Sent: January 16, 2004 10:57 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Comments on Silver Bullets

      I'm looking for comments on the following "article."
      Ken

      Silver Bullets

      I don't know if other industries fall prey to the silver bullet myth as hard
      as systems development. The belief that there will be some magical
      incantation, tool, or facility that will kill the difficulty of software
      development has haunted our industry as long as I've been developing
      software, and I remember the 60's. In some ways the belief in the silver
      bullet was good; it fueled the growth of whole tool industries - remember
      Computer Aided Software Engineering tools from Index Technology,
      Knowledgeware, and a host of other companies? Remember models that were
      supposed to generate code that could be maintained from the model? Remember
      heavyweight methodologies?

      A test for the presence of a silver bullet is, "does using this somehow make
      the practice of building software for me and those who work with me
      substantially easier in a way that I don't fully understand?" If the answer
      to this is "yes" and this thing costs money and is being sold by a company,
      inspect it thoroughly before buying and implementing it.

      I'm not against magic or simplification. Our jobs of building quality
      software are hard enough that I believe that we can be forgiven for looking
      for ways to simplify them. We can even be forgiven for spending lots of time
      and money acquiring and trying to use silver bullets. In the process, we
      usually learn something useful, like how to graphically represent our ideas
      methodically and rigorously. What we won't be forgiven for are both the
      degree to which these silver bullets have reduced our ability to produce
      quality software on time and with required capabilities, and the degree to
      which they've made it so that we speak separate languages from our
      customers. I once even taught a course in data modeling to a group of
      actuaries at an insurance company so that they could understand their
      systems.

      Agile processes are sometimes though of as silver bullets. "All I have to do
      is implement Scrum throughout my organization and things will be better" is
      becoming a mantra, following closely on the heels of "all I have to do is
      implement XP and things will be better." This statement is usually made by
      senior IT or software engineering management after one or several projects
      is miraculously turned around and becomes vividly successful after XP and/or
      Scrum is applied. The problem is that the success of the few is difficult to
      replicate in the many. The reason is the shortage of people who know what
      they are doing.

      The idea behind most silver bullets is that almost anyone can successfully
      build systems, as needed, using the silver bullet. Agile processes come in
      with a different tenet: software development is difficult work and here is a
      framework and set of practices within which to engage and manage teams in
      this difficult work. No attempt is made to say that the work is easy or can
      be done by junior, indifferent, or incompetent employees. Instead, agile
      processes simply make the impact of unskilled professionals very apparent
      very quickly. Skilled professionals generate quality systems using agile
      processes. Unskilled professionals produce terrible systems using agile
      processes. What agile processes bring to this game is that the bad work of
      the unskilled professionals becomes quickly apparent and must be dealt with;
      it won't go away and won't become invisible. Many methodologies keep
      unskilled work hidden until the end of the project, and some even keep the
      results hidden until someone attempts to sustain, maintain, or enhance it.
      Agile processes show the bad quality every day and at the end of every
      iteration.

      Agile processes are hard work. If everything that isn't going well is put in
      management's face every day and at the end of every iteration, life isn't
      very pleasant. It isn't that all of these problems weren't always present;
      it's just that now they are out in plain sight and pointed out to everyone
      very frequently. Part of my work helping people implement agile processes is
      getting them through the despair they initially feel when they see all the
      problems. I call these problems the good news and the bad news: the good
      news is that you can now begin methodically fixing these problems; the bad
      news is that you know that they need to be fixed (and so does everyone
      else).

      Agile processes keep the bad news visible until it is fixed. If developers
      aren't testing their code, this is evident at least every iteration, and
      often every day. If developers aren't checking in and building their code
      frequently, this becomes visible every day. These problems stay visible
      until engineering practices are implemented to fix them. Management is on
      the hook to get them fixed as well as to devise strategies to remedy the
      problems until they are fixed.

      Agile processes ruin perfectly good management jobs, where managers sit in
      corner offices reading reports and presuming good progress until the project
      fails. Agile processes stick the bad news in the face of managers daily; the
      "plausible deniability" offered by most silver bullets is totally removed.
      The good news is that you can build great software predictably with agile
      processes. The bad news is that it is really hard.



      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




      Yahoo! Groups Links

    • Chak
      Software is full of tradeoffs , and many times we have to choose our poison. So, yes, people need to be told that there are no silver bullets, and will never
      Message 2 of 14 , Jan 16, 2004
        Software is full of tradeoffs , and many times we have
        to choose our poison. So, yes, people need to be told
        that there are no silver bullets, and will never be.

        Chak.

        --- "Monique L. Attinger"
        <monique@...> wrote:
        > Ken -- I think this article is a timely 'reality
        > check'. While I'm not sure
        > where you are looking to 'publish' this, I suspect
        > that there are multiple
        > audiences who could benefit: 1) non-IT management
        > who think that we can do
        > more and more with less and less until we are making
        > everything out of
        > nothing, and 2) IT professionals who have bought
        > into the myth that there is
        > some kind of way to build software which takes away
        > the difficulty of
        > working with other people and who think everything
        > would be fine if only
        > they didn't have to deal with 'end losers'.
        >
        > Monique Attinger
        > -----Original Message-----
        > From: Ken Schwaber
        > [mailto:ken.schwaber@...]
        > Sent: January 16, 2004 10:57 AM
        > To: scrumdevelopment@yahoogroups.com
        > Subject: [scrumdevelopment] Comments on Silver
        > Bullets
        >
        >
        > I'm looking for comments on the following
        > "article."
        > Ken
        >
        > Silver Bullets
        >
        > I don't know if other industries fall prey to the
        > silver bullet myth as
        > hard
        > as systems development. The belief that there will
        > be some magical
        > incantation, tool, or facility that will kill the
        > difficulty of software
        > development has haunted our industry as long as
        > I've been developing
        > software, and I remember the 60's. In some ways
        > the belief in the silver
        > bullet was good; it fueled the growth of whole
        > tool industries - remember
        > Computer Aided Software Engineering tools from
        > Index Technology,
        > Knowledgeware, and a host of other companies?
        > Remember models that were
        > supposed to generate code that could be maintained
        > from the model?
        > Remember
        > heavyweight methodologies?
        >
        > A test for the presence of a silver bullet is,
        > "does using this somehow
        > make
        > the practice of building software for me and those
        > who work with me
        > substantially easier in a way that I don't fully
        > understand?" If the
        > answer
        > to this is "yes" and this thing costs money and is
        > being sold by a
        > company,
        > inspect it thoroughly before buying and
        > implementing it.
        >
        > I'm not against magic or simplification. Our jobs
        > of building quality
        > software are hard enough that I believe that we
        > can be forgiven for
        > looking
        > for ways to simplify them. We can even be forgiven
        > for spending lots of
        > time
        > and money acquiring and trying to use silver
        > bullets. In the process, we
        > usually learn something useful, like how to
        > graphically represent our
        > ideas
        > methodically and rigorously. What we won't be
        > forgiven for are both the
        > degree to which these silver bullets have reduced
        > our ability to produce
        > quality software on time and with required
        > capabilities, and the degree to
        > which they've made it so that we speak separate
        > languages from our
        > customers. I once even taught a course in data
        > modeling to a group of
        > actuaries at an insurance company so that they
        > could understand their
        > systems.
        >
        > Agile processes are sometimes though of as silver
        > bullets. "All I have to
        > do
        > is implement Scrum throughout my organization and
        > things will be better"
        > is
        > becoming a mantra, following closely on the heels
        > of "all I have to do is
        > implement XP and things will be better." This
        > statement is usually made by
        > senior IT or software engineering management after
        > one or several projects
        > is miraculously turned around and becomes vividly
        > successful after XP
        > and/or
        > Scrum is applied. The problem is that the success
        > of the few is difficult
        > to
        > replicate in the many. The reason is the shortage
        > of people who know what
        > they are doing.
        >
        > The idea behind most silver bullets is that almost
        > anyone can successfully
        > build systems, as needed, using the silver bullet.
        > Agile processes come in
        > with a different tenet: software development is
        > difficult work and here is
        > a
        > framework and set of practices within which to
        > engage and manage teams in
        > this difficult work. No attempt is made to say
        > that the work is easy or
        > can
        > be done by junior, indifferent, or incompetent
        > employees. Instead, agile
        > processes simply make the impact of unskilled
        > professionals very apparent
        > very quickly. Skilled professionals generate
        > quality systems using agile
        > processes. Unskilled professionals produce
        > terrible systems using agile
        > processes. What agile processes bring to this game
        > is that the bad work of
        > the unskilled professionals becomes quickly
        > apparent and must be dealt
        > with;
        > it won't go away and won't become invisible. Many
        > methodologies keep
        > unskilled work hidden until the end of the
        > project, and some even keep the
        > results hidden until someone attempts to sustain,
        > maintain, or enhance it.
        > Agile processes show the bad quality every day and
        > at the end of every
        > iteration.
        >
        > Agile processes are hard work. If everything that
        > isn't going well is put
        > in
        > management's face every day and at the end of
        > every iteration, life isn't
        > very pleasant. It isn't that all of these problems
        > weren't always present;
        > it's just that now they are out in plain sight and
        > pointed out to everyone
        > very frequently. Part of my work helping people
        > implement agile processes
        > is
        > getting them through the despair they initially
        > feel when they see all the
        > problems. I call these problems the good news and
        > the bad news: the good
        > news is that you can now begin methodically fixing
        > these problems; the bad
        > news is that you know that they need to be fixed
        > (and so does everyone
        > else).
        >
        > Agile processes keep the bad news visible until it
        > is fixed. If developers
        > aren't testing their code, this is evident at
        > least every iteration, and
        > often every day. If developers aren't checking in
        > and building their code
        > frequently, this becomes visible every day. These
        > problems stay visible
        > until engineering practices are implemented to fix
        > them. Management is on
        > the hook to get them fixed as well as to devise
        > strategies to remedy the
        > problems until they are fixed.
        >
        > Agile processes ruin perfectly good management
        > jobs, where managers sit in
        > corner offices reading reports and presuming good
        > progress until the
        > project
        > fails. Agile processes stick the bad news in the
        > face of managers daily;
        > the
        > "plausible deniability" offered by most silver
        > bullets is totally removed.
        > The good news is that you can build great software
        > predictably with agile
        > processes. The bad news is that it is really hard.
        >
        === message truncated ===


        __________________________________
        Do you Yahoo!?
        Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
        http://hotjobs.sweepstakes.yahoo.com/signingbonus
      • John Redfield
        I enjoyed the article, it s refreshing to view it doesn t work right from the developers point. The second paragraph seems a little stand alone , maybe a
        Message 3 of 14 , Jan 16, 2004

          I enjoyed the article, it’s refreshing to view “it doesn’t work right” from the developers point.

           

          The second paragraph seems a little “stand alone”, maybe a little more content to help it flow/transition from your opening paragraph?

           

          Nice work.

           


          From: Ken Schwaber [mailto:ken.schwaber@...]
          Sent: Friday, January 16, 2004 10:57 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Comments on Silver Bullets

           

          I'm looking for comments on the following "article."
          Ken

          Silver Bullets

          I don't know if other industries fall prey to the silver bullet myth as hard
          as systems development. The belief that there will be some magical
          incantation, tool, or facility that will kill the difficulty of software
          development has haunted our industry as long as I've been developing
          software, and I remember the 60's. In some ways the belief in the silver
          bullet was good; it fueled the growth of whole tool industries - remember
          Computer Aided Software Engineering tools from Index Technology,
          Knowledgeware, and a host of other companies? Remember models that were
          supposed to generate code that could be maintained from the model? Remember
          heavyweight methodologies?

          A test for the presence of a silver bullet is, "does using this somehow make
          the practice of building software for me and those who work with me
          substantially easier in a way that I don't fully understand?" If the answer
          to this is "yes" and this thing costs money and is being sold by a company,
          inspect it thoroughly before buying and implementing it.

          I'm not against magic or simplification. Our jobs of building quality
          software are hard enough that I believe that we can be forgiven for looking
          for ways to simplify them. We can even be forgiven for spending lots of time
          and money acquiring and trying to use silver bullets. In the process, we
          usually learn something useful, like how to graphically represent our ideas
          methodically and rigorously. What we won't be forgiven for are both the
          degree to which these silver bullets have reduced our ability to produce
          quality software on time and with required capabilities, and the degree to
          which they've made it so that we speak separate languages from our
          customers. I once even taught a course in data modeling to a group of
          actuaries at an insurance company so that they could understand their
          systems.

          Agile processes are sometimes though of as silver bullets. "All I have to do
          is implement Scrum throughout my organization and things will be better" is
          becoming a mantra, following closely on the heels of "all I have to do is
          implement XP and things will be better." This statement is usually made by
          senior IT or software engineering management after one or several projects
          is miraculously turned around and becomes vividly successful after XP and/or
          Scrum is applied. The problem is that the success of the few is difficult to
          replicate in the many. The reason is the shortage of people who know what
          they are doing.

          The idea behind most silver bullets is that almost anyone can successfully
          build systems, as needed, using the silver bullet. Agile processes come in
          with a different tenet: software development is difficult work and here is a
          framework and set of practices within which to engage and manage teams in
          this difficult work. No attempt is made to say that the work is easy or can
          be done by junior, indifferent, or incompetent employees. Instead, agile
          processes simply make the impact of unskilled professionals very apparent
          very quickly. Skilled professionals generate quality systems using agile
          processes. Unskilled professionals produce terrible systems using agile
          processes. What agile processes bring to this game is that the bad work of
          the unskilled professionals becomes quickly apparent and must be dealt with;
          it won't go away and won't become invisible. Many methodologies keep
          unskilled work hidden until the end of the project, and some even keep the
          results hidden until someone attempts to sustain, maintain, or enhance it.
          Agile processes show the bad quality every day and at the end of every
          iteration.

          Agile processes are hard work. If everything that isn't going well is put in
          management's face every day and at the end of every iteration, life isn't
          very pleasant. It isn't that all of these problems weren't always present;
          it's just that now they are out in plain sight and pointed out to everyone
          very frequently. Part of my work helping people implement agile processes is
          getting them through the despair they initially feel when they see all the
          problems. I call these problems the good news and the bad news: the good
          news is that you can now begin methodically fixing these problems; the bad
          news is that you know that they need to be fixed (and so does everyone
          else).

          Agile processes keep the bad news visible until it is fixed. If developers
          aren't testing their code, this is evident at least every iteration, and
          often every day. If developers aren't checking in and building their code
          frequently, this becomes visible every day. These problems stay visible
          until engineering practices are implemented to fix them. Management is on
          the hook to get them fixed as well as to devise strategies to remedy the
          problems until they are fixed.

          Agile processes ruin perfectly good management jobs, where managers sit in
          corner offices reading reports and presuming good progress until the project
          fails. Agile processes stick the bad news in the face of managers daily; the
          "plausible deniability" offered by most silver bullets is totally removed.
          The good news is that you can build great software predictably with agile
          processes. The bad news is that it is really hard.



          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



          Yahoo! Groups Links

        • Edmund Schweppe
          ... [ ... ] ... I had to think a minute about this paragraph; the phrase silver bullet usually makes me think of Fred Brooks and his essay No Silver
          Message 4 of 14 , Jan 16, 2004
            Ken Schwaber wrote:

            > I'm looking for comments on the following "article."

            [ ... ]

            > A test for the presence of a silver bullet is, "does using this somehow make
            > the practice of building software for me and those who work with me
            > substantially easier in a way that I don't fully understand?" If the answer
            > to this is "yes" and this thing costs money and is being sold by a company,
            > inspect it thoroughly before buying and implementing it.

            I had to think a minute about this paragraph; the phrase "silver bullet"
            usually makes me think of Fred Brooks and his essay "No Silver Bullet".
            Here, I guess you're saying that "silver bullets" are the things people
            *think* will magically fix everything.

            Apart from that, though, I like it. What's the target audience?

            --
            Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
            The opinions expressed herein are at best coincidentally related to
            those of any past, present or future employer.
          • Brad Grant
            I echo Monique s comments. Moreover, IT mgmt that realize a successful agile project and wonder why we can t always function like this. Or even
            Message 5 of 14 , Jan 16, 2004
              I echo Monique's comments.

              Moreover, IT mgmt that realize a successful agile project and wonder
              why we can't always function like this.
              Or even development-staff tailcoaters who fail to understand the
              discipline and dedication undertaken to achieve a quality iteration.

              Brad

              --- In scrumdevelopment@yahoogroups.com, "Monique L. Attinger"
              <monique@a...> wrote:
              > Ken -- I think this article is a timely 'reality check'. While I'm
              not sure
              > where you are looking to 'publish' this, I suspect that there are
              multiple
              > audiences who could benefit: 1) non-IT management who think that
              we can do
              > more and more with less and less until we are making everything
              out of
              > nothing, and 2) IT professionals who have bought into the myth
              that there is
              > some kind of way to build software which takes away the difficulty
              of
              > working with other people and who think everything would be fine
              if only
              > they didn't have to deal with 'end losers'.
              >
              > Monique Attinger
              > -----Original Message-----
              > From: Ken Schwaber [mailto:ken.schwaber@v...]
              > Sent: January 16, 2004 10:57 AM
              > To: scrumdevelopment@yahoogroups.com
              > Subject: [scrumdevelopment] Comments on Silver Bullets
              >
              >
              > I'm looking for comments on the following "article."
              > Ken
              >
              > Silver Bullets
              >
              > I don't know if other industries fall prey to the silver bullet
              myth as
              > hard
              > as systems development. The belief that there will be some
              magical
              > incantation, tool, or facility that will kill the difficulty of
              software
              > development has haunted our industry as long as I've been
              developing
              > software, and I remember the 60's. In some ways the belief in
              the silver
              > bullet was good; it fueled the growth of whole tool industries -
              remember
              > Computer Aided Software Engineering tools from Index Technology,
              > Knowledgeware, and a host of other companies? Remember models
              that were
              > supposed to generate code that could be maintained from the
              model?
              > Remember
              > heavyweight methodologies?
              >
              > A test for the presence of a silver bullet is, "does using this
              somehow
              > make
              > the practice of building software for me and those who work with
              me
              > substantially easier in a way that I don't fully understand?" If
              the
              > answer
              > to this is "yes" and this thing costs money and is being sold by
              a
              > company,
              > inspect it thoroughly before buying and implementing it.
              >
              > I'm not against magic or simplification. Our jobs of building
              quality
              > software are hard enough that I believe that we can be forgiven
              for
              > looking
              > for ways to simplify them. We can even be forgiven for spending
              lots of
              > time
              > and money acquiring and trying to use silver bullets. In the
              process, we
              > usually learn something useful, like how to graphically
              represent our
              > ideas
              > methodically and rigorously. What we won't be forgiven for are
              both the
              > degree to which these silver bullets have reduced our ability to
              produce
              > quality software on time and with required capabilities, and the
              degree to
              > which they've made it so that we speak separate languages from
              our
              > customers. I once even taught a course in data modeling to a
              group of
              > actuaries at an insurance company so that they could understand
              their
              > systems.
              >
              > Agile processes are sometimes though of as silver bullets. "All
              I have to
              > do
              > is implement Scrum throughout my organization and things will be
              better"
              > is
              > becoming a mantra, following closely on the heels of "all I have
              to do is
              > implement XP and things will be better." This statement is
              usually made by
              > senior IT or software engineering management after one or
              several projects
              > is miraculously turned around and becomes vividly successful
              after XP
              > and/or
              > Scrum is applied. The problem is that the success of the few is
              difficult
              > to
              > replicate in the many. The reason is the shortage of people who
              know what
              > they are doing.
              >
              > The idea behind most silver bullets is that almost anyone can
              successfully
              > build systems, as needed, using the silver bullet. Agile
              processes come in
              > with a different tenet: software development is difficult work
              and here is
              > a
              > framework and set of practices within which to engage and manage
              teams in
              > this difficult work. No attempt is made to say that the work is
              easy or
              > can
              > be done by junior, indifferent, or incompetent employees.
              Instead, agile
              > processes simply make the impact of unskilled professionals very
              apparent
              > very quickly. Skilled professionals generate quality systems
              using agile
              > processes. Unskilled professionals produce terrible systems
              using agile
              > processes. What agile processes bring to this game is that the
              bad work of
              > the unskilled professionals becomes quickly apparent and must be
              dealt
              > with;
              > it won't go away and won't become invisible. Many methodologies
              keep
              > unskilled work hidden until the end of the project, and some
              even keep the
              > results hidden until someone attempts to sustain, maintain, or
              enhance it.
              > Agile processes show the bad quality every day and at the end of
              every
              > iteration.
              >
              > Agile processes are hard work. If everything that isn't going
              well is put
              > in
              > management's face every day and at the end of every iteration,
              life isn't
              > very pleasant. It isn't that all of these problems weren't
              always present;
              > it's just that now they are out in plain sight and pointed out
              to everyone
              > very frequently. Part of my work helping people implement agile
              processes
              > is
              > getting them through the despair they initially feel when they
              see all the
              > problems. I call these problems the good news and the bad news:
              the good
              > news is that you can now begin methodically fixing these
              problems; the bad
              > news is that you know that they need to be fixed (and so does
              everyone
              > else).
              >
              > Agile processes keep the bad news visible until it is fixed. If
              developers
              > aren't testing their code, this is evident at least every
              iteration, and
              > often every day. If developers aren't checking in and building
              their code
              > frequently, this becomes visible every day. These problems stay
              visible
              > until engineering practices are implemented to fix them.
              Management is on
              > the hook to get them fixed as well as to devise strategies to
              remedy the
              > problems until they are fixed.
              >
              > Agile processes ruin perfectly good management jobs, where
              managers sit in
              > corner offices reading reports and presuming good progress until
              the
              > project
              > fails. Agile processes stick the bad news in the face of
              managers daily;
              > the
              > "plausible deniability" offered by most silver bullets is
              totally removed.
              > The good news is that you can build great software predictably
              with agile
              > processes. The bad news is that it is really hard.
              >
              >
              >
              > To Post a message, send it to: scrumdevelopment@e...
              > To Unsubscribe, send a blank message to:
              > scrumdevelopment-unsubscribe@e...
              >
              >
              >
              > -------------------------------------------------------------------
              ---------
              > --
              > Yahoo! Groups Links
              >
              > a.. To visit your group on the web, go to:
              > http://groups.yahoo.com/group/scrumdevelopment/
              >
              > b.. To unsubscribe from this group, send an email to:
              > scrumdevelopment-unsubscribe@yahoogroups.com
              >
              > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
              of Service.
            • Nancy Van Schooenderwoert
              ... About the 2nd paragraph - At the end of it, I was hoping for an example. It got me thinking that source code control tools make life substantially easier,
              Message 6 of 14 , Jan 18, 2004
                On Fri, 2004-01-16 at 10:57, Ken Schwaber wrote:
                > I'm looking for comments on the following "article."
                > Ken

                About the 2nd paragraph - At the end of it, I was hoping for an
                example. It got me thinking that source code control tools make life
                substantially easier, and I DO completely understand what they do - so
                that's not a silver bullet. I'll say that tools purporting to generate &
                maintain code directly from UML diagrams are a silver bullet because I
                don't fully understand how they can do it, and I haven't seen one fully
                prove itself.

                The fourth paragraph points out the shortage of people who know what
                they are doing. Reading this as a manager I'd want to know more about
                how I can tell who does know what they're doing. I suppose that's a
                different article. Just the same, it's a great spot to have a pointer to
                info on that topic.

                Fifth paragraph - You may wish to tie this insight ( agile processes
                simply make the impact of unskilled professionals very apparent very
                quickly ) to the "don't shoot the messenger" classic advice. The old
                fashioned thing was to yell at the messenger. Now the way is to set up
                that plausible deniability - blame a tool, blame an outsourcer, etc.
                I'll bet every manager on earth will say they never "shoot the
                messenger", but they have a million ways to duck the message or get the
                messenger to go away. It amounts to the same thing: refusing to accept
                reality. Agile will never work in a place where success = failure +
                someone to blame. There has to be a genuine commitment to succeed in the
                Agile manager. You make that point very nicely in the last paragraph.

                I really like this article - it's excellent.

                -njv
                -----------------------------------------------------------------------
                Nancy Van Schooenderwoert XP Embedded Company nancyv@...
                http://www.xp-embedded.com
                -----------------------------------------------------------------------
              • fredb001
                Great article. Thank you! ... I remember reading that the first programming language in the late 40 s was thought to signify the end of the need for
                Message 7 of 14 , Jan 19, 2004
                  Great article. Thank you!

                  > The belief that there will be some magical
                  > incantation, tool, or facility that will kill the difficulty of >
                  > software development has haunted our industry as long as I've been
                  > developing software, and I remember the 60's.

                  I remember reading that the first programming language in the late
                  40's was thought to signify the end of the need for programmers.

                  > Remember heavyweight methodologies?

                  All too well. All too painfully. I'm afraid heavyweight
                  methodologies' legacy is an aversion to any methodology at all. Not
                  that this aversion wasn't present to begin with. But I'd say
                  heavyweight methodologies reinforced it dramatically at every level
                  in the organization: the programmers didn't like using them and
                  management didn't like the drop in productivity.

                  > Agile processes are sometimes thought of as silver bullets.

                  Being a silver bullet does seem to be the chief criticism leveled at
                  agile processes -- at least the opening volley. "Look at the new
                  cure-all fad they're trying to foist on us." (The middle of these
                  arguments is usually "It's just commonsense" and end with "Of
                  course, we were doing it this way all along.")

                  > The reason is the shortage of people who know what they are doing.

                  Truer words were never spoken. Also, I think things would be more
                  hopeful if a lot more people know, as Phil Armour might put it, that
                  they don't know what they are doing.

                  In particular, I hope the last four paragraphs get the widest
                  circulation possible. Maybe we could all pitch in for a spot during
                  the Super Bowl?

                  Fred
                • Bishop, Murray
                  Sorry for the lateness of this reply, and thanks for the article, which I liked. ... Maybe say and I ve been doing that since the 60 s , after all - if you
                  Message 8 of 14 , Jan 20, 2004
                    Sorry for the lateness of this reply, and thanks for the article, which I
                    liked.

                    > I don't know if other industries fall prey to the silver bullet myth as
                    > hard
                    > as systems development. The belief that there will be some magical
                    > incantation, tool, or facility that will kill the difficulty of software
                    > development has haunted our industry as long as I've been developing
                    > software, and I remember the 60's.

                    Maybe say "and I've been doing that since the 60's", after all - if you
                    remember the 60's, you weren't there. 8-)

                    Best Regards,
                    Murray
                  • Ken Schwaber
                    I think we might get Coors to include us. Ken ... From: fredb001 [mailto:fredb001@comcast.net] Sent: Monday, January 19, 2004 10:17 PM To:
                    Message 9 of 14 , Jan 21, 2004
                      I think we might get Coors to include us.
                      Ken

                      -----Original Message-----
                      From: fredb001 [mailto:fredb001@...]
                      Sent: Monday, January 19, 2004 10:17 PM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: [scrumdevelopment] Re: Comments on Silver Bullets


                      Great article. Thank you!

                      > The belief that there will be some magical
                      > incantation, tool, or facility that will kill the difficulty of >
                      > software development has haunted our industry as long as I've been
                      > developing software, and I remember the 60's.

                      I remember reading that the first programming language in the late
                      40's was thought to signify the end of the need for programmers.

                      > Remember heavyweight methodologies?

                      All too well. All too painfully. I'm afraid heavyweight
                      methodologies' legacy is an aversion to any methodology at all. Not
                      that this aversion wasn't present to begin with. But I'd say
                      heavyweight methodologies reinforced it dramatically at every level
                      in the organization: the programmers didn't like using them and
                      management didn't like the drop in productivity.

                      > Agile processes are sometimes thought of as silver bullets.

                      Being a silver bullet does seem to be the chief criticism leveled at
                      agile processes -- at least the opening volley. "Look at the new
                      cure-all fad they're trying to foist on us." (The middle of these
                      arguments is usually "It's just commonsense" and end with "Of
                      course, we were doing it this way all along.")

                      > The reason is the shortage of people who know what they are doing.

                      Truer words were never spoken. Also, I think things would be more
                      hopeful if a lot more people know, as Phil Armour might put it, that
                      they don't know what they are doing.

                      In particular, I hope the last four paragraphs get the widest
                      circulation possible. Maybe we could all pitch in for a spot during
                      the Super Bowl?

                      Fred



                      To Post a message, send it to: scrumdevelopment@...
                      To Unsubscribe, send a blank message to:
                      scrumdevelopment-unsubscribe@...

                      Yahoo! Groups Links

                      To visit your group on the web, go to:
                      http://groups.yahoo.com/group/scrumdevelopment/

                      To unsubscribe from this group, send an email to:
                      scrumdevelopment-unsubscribe@yahoogroups.com

                      Your use of Yahoo! Groups is subject to:
                      http://docs.yahoo.com/info/terms/
                    Your message has been successfully submitted and would be delivered to recipients shortly.