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

Code ownership

Expand Messages
  • Chak
    Hello, I am exposed to XP s code ownership concept, am assuming that SCRUM shares that concept (does it?), and am presenting this query :- Take this leaf out
    Message 1 of 14 , Jan 14, 2004
    • 0 Attachment
      Hello,

      I am exposed to XP's code ownership concept, am
      assuming that SCRUM shares that concept (does it?),
      and am presenting this query :-

      Take this leaf out of a project i
      was in. We had 2 approaches to a particular problem -
      one using a 'grunt' approach, which however gave us a
      light-weight solution, with some acceptable
      constraints (this was my approach). The other
      approach
      was more mainstream and a 'heavy-weight' solution -
      (more apparent benefits and more risks)(this was the
      other team member's suggested approach). I had
      convinced the Project manager of my approach, and we
      had proceeded fairly far into the project. Along came
      a new guy with brand new ideas on how this problem
      ought to have been approached, and convinced the
      Project Manager that his approach would suit customer
      needs better . It ultimately boiled down to a
      discussion of (their)feature-set versus
      (my)out-of-the-box, and my approach lost out, among a
      lot of emotional cross-currents (which i think Edward
      Yourdon describes as 'Project politics' in his
      'DeathMarch' book). The entire code base was re-coded
      using the new approach , despite me 'defending' my
      case to the Project Manager (who is not a very
      technical person), and the new kid in town.

      I had to leave the project in shame (i was a
      contractor whose contract period had come to an end),
      with the feeling of being so near yet so far.

      So what would be the 'SCRUM' approach
      and thinking be in this case ?

      Thanks.

      Chak.


      __________________________________
      Do you Yahoo!?
      Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
      http://hotjobs.sweepstakes.yahoo.com/signingbonus
    • Mike Cohn
      It s unclear over what time period this happened so the Scrum answer could vary a bit based on that but here s an answer, or at least parts of an answer. The
      Message 2 of 14 , Jan 14, 2004
      • 0 Attachment
        It's unclear over what time period this happened so the Scrum answer could
        vary a bit based on that but here's an answer, or at least parts of an
        answer.

        The Project Manager wouldn't be involved in making the technical decision,
        which it sounds like this was. The team would have made that decision.

        Once a sprint starts you don't really change it. So, if everyone had agreed
        on an approach that implied certain technical or functional constraints that
        decision would hold for the one-month duration of the sprint. If you get two
        weeks into the sprint and there's a lot of concern that the decision is
        wrong, the business would have the option of aborting the sprint in which
        case all the work of the sprint would be thrown away. Things would be rolled
        back to where they were at the end of the prior sprint. Most commonly,
        though, in that situation the company will choose to finish the half-done
        sprint. At the start of the next sprint the new decision is to start over
        with the different approach or continue with the partially implemented one.
        The partially implemented one has the advantage in that case, obviously.

        I don't know how different the approaches were and whether this is possible
        BUT: the best thing in that situation would have been to defer as long as
        possible the decision that committed you to one route or the other. In that
        way you could have had more information and understanding of the domain and
        the risk of the decision would have been reduced by delaying it. For more on
        that approach see the Poppendiecks' wonderful book on Lean Software
        Development.

        --Mike

        -----Original Message-----
        From: Chak [mailto:r_chakra@...]
        Sent: Wednesday, January 14, 2004 8:38 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Code ownership

        Hello,

        I am exposed to XP's code ownership concept, am
        assuming that SCRUM shares that concept (does it?),
        and am presenting this query :-

        Take this leaf out of a project i
        was in. We had 2 approaches to a particular problem -
        one using a 'grunt' approach, which however gave us a
        light-weight solution, with some acceptable
        constraints (this was my approach). The other
        approach
        was more mainstream and a 'heavy-weight' solution -
        (more apparent benefits and more risks)(this was the
        other team member's suggested approach). I had
        convinced the Project manager of my approach, and we
        had proceeded fairly far into the project. Along came
        a new guy with brand new ideas on how this problem
        ought to have been approached, and convinced the
        Project Manager that his approach would suit customer
        needs better . It ultimately boiled down to a
        discussion of (their)feature-set versus
        (my)out-of-the-box, and my approach lost out, among a
        lot of emotional cross-currents (which i think Edward
        Yourdon describes as 'Project politics' in his
        'DeathMarch' book). The entire code base was re-coded
        using the new approach , despite me 'defending' my
        case to the Project Manager (who is not a very
        technical person), and the new kid in town.

        I had to leave the project in shame (i was a
        contractor whose contract period had come to an end),
        with the feeling of being so near yet so far.

        So what would be the 'SCRUM' approach
        and thinking be in this case ?

        Thanks.

        Chak.


        __________________________________
        Do you Yahoo!?
        Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
        http://hotjobs.sweepstakes.yahoo.com/signingbonus

        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/
      • Michael D. Ivey
        ... Since Scrum is a set of management practices, and not engineering practices, Collective Code Ownership isn t a formal part of Scrum. Theoretically, you
        Message 3 of 14 , Jan 14, 2004
        • 0 Attachment
          On Wed, Jan 14, 2004 at 07:37:40AM -0800, Chak wrote:
          > I am exposed to XP's code ownership concept, am assuming that SCRUM
          > shares that concept (does it?), and am presenting this query

          Since Scrum is a set of management practices, and not engineering
          practices, "Collective Code Ownership" isn't a formal part of Scrum.
          Theoretically, you could do Scrum in a very "my code!" type of
          environment, but it would be just as unpleasant as doing any other
          process in that environment.

          > Take this leaf out of a project i was in. We had 2 approaches to a
          > particular problem - one using a 'grunt' approach, which however gave
          > us a light-weight solution, with some acceptable constraints (this was
          > my approach). The other approach was more mainstream and a
          > 'heavy-weight' solution - (more apparent benefits and more risks)(this
          > was the other team member's suggested approach). I had convinced the
          > Project manager of my approach, and we had proceeded fairly far into
          > the project. Along came a new guy with brand new ideas on how this
          > problem ought to have been approached, and convinced the Project
          > Manager that his approach would suit customer needs better . It
          > ultimately boiled down to a discussion of (their)feature-set versus
          > (my)out-of-the-box, and my approach lost out, among a lot of emotional
          > cross-currents (which i think Edward Yourdon describes as 'Project
          > politics' in his 'DeathMarch' book). The entire code base was re-coded
          > using the new approach , despite me 'defending' my case to the Project
          > Manager (who is not a very technical person), and the new kid in town.

          The main thing you would have seen in Scrum is that the team, that is
          all the people who were doing the work, would have decided how to solve
          the problem, instead of appealing to the manager. If the team couldn't
          solve it, the ScrumMaster might make a decision for them, or steer them
          towards the simpler solution, or take other approaches. It's hard to
          say what exactly would have happened, since I wasn't there.

          The two points about Scrum to take away from this:
          - Scrum wouldn't solve your problem for you...the team would still have
          had to make a decision in some way
          - More importantly, the team would make the decision, not a manager

          I hope that helps you get an idea!

          - Michael

          --
          Michael D. Ivey, Senior Partner | mdi@...
          Ivey & Brown, Inc. | http://www.iveyandbrown.com
          Process and Technology Consulting | (866) 235-7764
        • Ken Schwaber
          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
          Message 4 of 14 , Jan 16, 2004
          • 0 Attachment
            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.
          • Mike Cohn
            Ken-- This looks really good to me. I d only point out that the fourth paragraph starts out with Agile processes are sometimes though of as silver bullets
            Message 5 of 14 , Jan 16, 2004
            • 0 Attachment
              Ken--
              This looks really good to me. I'd only point out that the fourth paragraph
              starts out with "Agile processes are sometimes though of as silver bullets"
              but you want THOUGHT instead of THOUGH.

              I think the reason our search for silver bullets fails, as Brooks predicted,
              is because our tools and ways of working aren't yet developed to the point
              where we'd even know what to do with a silver bullet. Think of a stone-age
              caveman who is suddenly given a bullet. It's not going to make his life any
              easier. As we've previously progressed from the stone age to the bronze age
              to the iron age we need similar progressions in how we think about how we
              build software. If pushed I'd suspect we started with the Spaghetti Age
              moved to the Methodology Age (80s and 90s) and are now entering the Agile
              Age. I'm sure it won't be the last.

              --Mike

              -----Original Message-----
              From: Ken Schwaber [mailto:ken.schwaber@...]
              Sent: Friday, January 16, 2004 8: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

              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/
            • 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 6 of 14 , Jan 16, 2004
              • 0 Attachment
                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 7 of 14 , Jan 16, 2004
                • 0 Attachment
                  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 8 of 14 , Jan 16, 2004
                  • 0 Attachment

                    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 9 of 14 , Jan 16, 2004
                    • 0 Attachment
                      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 10 of 14 , Jan 16, 2004
                      • 0 Attachment
                        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 11 of 14 , Jan 18, 2004
                        • 0 Attachment
                          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 12 of 14 , Jan 19, 2004
                          • 0 Attachment
                            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 13 of 14 , Jan 20, 2004
                            • 0 Attachment
                              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 14 of 14 , Jan 21, 2004
                              • 0 Attachment
                                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.