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

RE: Agile Software Development Revolution

Expand Messages
  • Mike Beedle
    (I know most of the people subscribed to this list belong to the Extreme Programming mailing list, but just in case some of you missed this posting at the
    Message 1 of 17 , Jul 8, 2002
    View Source
    • 0 Attachment
      (I know most of the people subscribed to this list belong to
      the Extreme Programming mailing list, but just in case some
      of you missed this posting at the Extreme mailing list.....
      here it is. My apologies included if you have received multiple
      copies of this message.)

      Dear agileers,

      It troubles me that the _fundamental differences_ between
      traditional and agile processes are not highlighted,
      either by, we, the creators and supporters of the Agile movement,
      or by traditional software development figure-heads.

      Because if we don't highlight the differences of why Agile
      Software Development processes we run the danger of hearing
      and, worse, accepting that:

      there is nothing really all that new with
      Agile Software Development processes

      This will relinquish Agile Software Development as "one"
      of many other compatible worldviews, and soon Agility will be
      muddled into oblivion.

      Don't take me wrong, I admire and respect the contributions
      of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
      Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
      desperate effort to make sense of Agility, we will find
      that many important concepts are forgotten if we try to equate them
      with their traditional software development counterparts. And that
      misconceptions and misunderstandings will be created like:

      The CMM is compatible with agile processes, or
      XP can be an instance of RUP

      In my opinion, there are radical and fundamental _differences_
      that make Agile Software Development Processes and Traditional Software
      Development Processes two very different ways of developing software
      from the perspective of the nature of their underlying processes:

      Traditional Software Development Processes advocate and
      eventually prescribe a _defined_ and _repeatable software
      engineering process, as well as many other _defined_ and
      _repeatable_ processes that correspond to different
      "process areas". And they are based on the erroneous belief,
      in my opinion, that software can be "manufactured".

      But,

      Agile Software Development Processes, on the other hand,
      use inspection/adaptation feedback cycles that "generate"
      a process by people that self-organize based on the
      application of a set of practices, or patterns really,
      that in an Alexandrian way lead to the emergence of
      an organization and a process. This is stated directly
      in the Agile Principles:

      "The best architectures, requirements, and designs
      emerge from self-organizing teams."
      http://www.agilemanifesto.org/principles.html

      Therefore Agile Software Development Process more
      closely resembles a New Product development process
      like the one described in:

      [NonakaTakeuchi] Takeuchi H. and Nonaka I., The New New Product
      Development Game, Harvard Business Review (January 1986),
      pp. 137-146, 1986.

      In my opinion, this is an important, radical and fundamental
      _difference_, that subtly changes the underlying assumptions
      of why and how things work in a software development process.

      How does this difference affects the people that work on an
      Agile Software Development Process?

      It is this feature of Agility that brings out these essential
      characteristics in an Agile Software Development Process:


      1) Greater Liberty and Freedom

      People in an Agile Software project feel more liberated
      because they feel _free_ to do whatever it takes
      to achieve their goal:

      talk to the customer, think, imagine, code, test, refactor,

      in any order, as many times as they need/want, and as often as
      they need to.


      2) Required Learning, Knowledge Creation and Knowledge Sharing

      People in an Agile Software project are constantly learning,
      and sharing knowledge because by definition Agility is
      based on continuous short feedback cycles of:

      inspection --> adaptation

      where we learn from the customers, from other team members,
      from practitioners in the field, and even from ourselves
      on a daily basis.


      3) A More Enjoyable and Humane Work Environment

      People in an Agile Software project participate in a more
      human "fun-like" way because the more human and intellectual
      activities of research, understanding, imagination,
      creativity, cooperation and sharing are encouraged and required;
      as opposed to being considered just "another station in
      a production line".


      4) A Hyper-productive Cooperative Work Mode

      People in an Agile Software project work in teams that
      exhibit a mode of cooperation that leads to hyper-productivity --
      the dynamic pull-system way that Nonaka and Takeuchi describe in the
      Knowledge Creating Company as the "hypertext" organization.

      This mode of cooperation, taps into the collective
      intelligence and collective knowledge and memory stored
      in the distributed mind of the team and the organization
      as a whole.


      5) The Quality of Life

      Agile Software projects work under the assumption and
      expectation that "emergent" behavior is the only way to
      confront uncertainty. Agile Software projects openly
      accept that it is impossible to:

      outline what tasks are going to be needed
      to complete a software project up-front, and

      get all the requirements up-front, and/or
      design an architecture up-front.

      Rather, the plan, the requirements and the architecture
      of the project, gradually emerge, by constant feedback cycles,
      research and creativity, and constant interaction among
      the participants of the project and the customer.

      This is what gives Agile Software Development teams
      the distinctive feature of "ordered chaos" that
      Life itself uses to accomplish its miraculous chores.

      And therefore, this is what literally makes teams
      more "alive", because teams more closely resemble
      living systems like ant or bee colonies,
      brains, or rugby/soccer/football teams.

      etc.

      For these reasons, which are not all, I hereby declare the
      beginning of a new era in software development, and I therefore
      proclaim officially that the creation of the Agile Manifesto:

      http://www.agilemanifesto.org/

      and its principles:

      http://www.agilemanifesto.org/principles.html

      mark unequivocally the beginning of the:

      Agile Software Development Revolution

      which was created, sponsored and supported by all of
      you brave souls that dared the world by practicing and
      advocating a _new_ Agile way, that makes software development
      different, more productive, more humane and therefore
      clearly better, in my opinion.

      Don't find yourself muddled out by figure-heads ... stay Agile!

      - Mike

      http://www.agilescrum.com
      http://www.xbreed.net
    • Ken Schwaber
      Mike, I congratulate your focus. We are in danger of this being thought and whittled to death. Like the movie, Death by a Thousand Blows. I had a similar
      Message 2 of 17 , Jul 8, 2002
      View Source
      • 0 Attachment
        Mike,
        I congratulate your focus. We are in danger of this being thought and
        whittled to death. Like the movie, "Death by a Thousand Blows." I had a
        similar feeling at XP2002, which caused my to get up in a rather testy mood
        and give the attached speech to the attendees.
        Ken

        -----Original Message-----
        From: Mike Beedle [mailto:beedlem@...]
        Sent: Monday, July 08, 2002 7:16 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] RE: Agile Software Development Revolution



        (I know most of the people subscribed to this list belong to
        the Extreme Programming mailing list, but just in case some
        of you missed this posting at the Extreme mailing list.....
        here it is. My apologies included if you have received multiple
        copies of this message.)

        Dear agileers,

        It troubles me that the _fundamental differences_ between
        traditional and agile processes are not highlighted,
        either by, we, the creators and supporters of the Agile movement,
        or by traditional software development figure-heads.

        Because if we don't highlight the differences of why Agile
        Software Development processes we run the danger of hearing
        and, worse, accepting that:

        there is nothing really all that new with
        Agile Software Development processes

        This will relinquish Agile Software Development as "one"
        of many other compatible worldviews, and soon Agility will be
        muddled into oblivion.

        Don't take me wrong, I admire and respect the contributions
        of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
        Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
        desperate effort to make sense of Agility, we will find
        that many important concepts are forgotten if we try to equate them
        with their traditional software development counterparts. And that
        misconceptions and misunderstandings will be created like:

        The CMM is compatible with agile processes, or
        XP can be an instance of RUP

        In my opinion, there are radical and fundamental _differences_
        that make Agile Software Development Processes and Traditional Software
        Development Processes two very different ways of developing software
        from the perspective of the nature of their underlying processes:

        Traditional Software Development Processes advocate and
        eventually prescribe a _defined_ and _repeatable software
        engineering process, as well as many other _defined_ and
        _repeatable_ processes that correspond to different
        "process areas". And they are based on the erroneous belief,
        in my opinion, that software can be "manufactured".

        But,

        Agile Software Development Processes, on the other hand,
        use inspection/adaptation feedback cycles that "generate"
        a process by people that self-organize based on the
        application of a set of practices, or patterns really,
        that in an Alexandrian way lead to the emergence of
        an organization and a process. This is stated directly
        in the Agile Principles:

        "The best architectures, requirements, and designs
        emerge from self-organizing teams."
        http://www.agilemanifesto.org/principles.html

        Therefore Agile Software Development Process more
        closely resembles a New Product development process
        like the one described in:

        [NonakaTakeuchi] Takeuchi H. and Nonaka I., The New New Product
        Development Game, Harvard Business Review (January 1986),
        pp. 137-146, 1986.

        In my opinion, this is an important, radical and fundamental
        _difference_, that subtly changes the underlying assumptions
        of why and how things work in a software development process.

        How does this difference affects the people that work on an
        Agile Software Development Process?

        It is this feature of Agility that brings out these essential
        characteristics in an Agile Software Development Process:


        1) Greater Liberty and Freedom

        People in an Agile Software project feel more liberated
        because they feel _free_ to do whatever it takes
        to achieve their goal:

        talk to the customer, think, imagine, code, test, refactor,

        in any order, as many times as they need/want, and as often as
        they need to.


        2) Required Learning, Knowledge Creation and Knowledge Sharing

        People in an Agile Software project are constantly learning,
        and sharing knowledge because by definition Agility is
        based on continuous short feedback cycles of:

        inspection --> adaptation

        where we learn from the customers, from other team members,
        from practitioners in the field, and even from ourselves
        on a daily basis.


        3) A More Enjoyable and Humane Work Environment

        People in an Agile Software project participate in a more
        human "fun-like" way because the more human and intellectual
        activities of research, understanding, imagination,
        creativity, cooperation and sharing are encouraged and required;
        as opposed to being considered just "another station in
        a production line".


        4) A Hyper-productive Cooperative Work Mode

        People in an Agile Software project work in teams that
        exhibit a mode of cooperation that leads to hyper-productivity --
        the dynamic pull-system way that Nonaka and Takeuchi describe in the
        Knowledge Creating Company as the "hypertext" organization.

        This mode of cooperation, taps into the collective
        intelligence and collective knowledge and memory stored
        in the distributed mind of the team and the organization
        as a whole.


        5) The Quality of Life

        Agile Software projects work under the assumption and
        expectation that "emergent" behavior is the only way to
        confront uncertainty. Agile Software projects openly
        accept that it is impossible to:

        outline what tasks are going to be needed
        to complete a software project up-front, and

        get all the requirements up-front, and/or
        design an architecture up-front.

        Rather, the plan, the requirements and the architecture
        of the project, gradually emerge, by constant feedback cycles,
        research and creativity, and constant interaction among
        the participants of the project and the customer.

        This is what gives Agile Software Development teams
        the distinctive feature of "ordered chaos" that
        Life itself uses to accomplish its miraculous chores.

        And therefore, this is what literally makes teams
        more "alive", because teams more closely resemble
        living systems like ant or bee colonies,
        brains, or rugby/soccer/football teams.

        etc.

        For these reasons, which are not all, I hereby declare the
        beginning of a new era in software development, and I therefore
        proclaim officially that the creation of the Agile Manifesto:

        http://www.agilemanifesto.org/

        and its principles:

        http://www.agilemanifesto.org/principles.html

        mark unequivocally the beginning of the:

        Agile Software Development Revolution

        which was created, sponsored and supported by all of
        you brave souls that dared the world by practicing and
        advocating a _new_ Agile way, that makes software development
        different, more productive, more humane and therefore
        clearly better, in my opinion.

        Don't find yourself muddled out by figure-heads ... stay Agile!

        - Mike

        http://www.agilescrum.com
        http://www.xbreed.net


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

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Mike Beedle
        Ken: What a joy to read your XP 2002 speech. I wish I would have been there. It is certainly inspiring, provocative and gets the point across: Agile is
        Message 3 of 17 , Jul 8, 2002
        View Source
        • 0 Attachment
          Ken:

          What a joy to read your XP 2002 speech. I wish I would have been there.
          It is certainly inspiring, provocative and gets the point across:

          Agile is certainly different and revolutionary

          and your speech explains why -- that's important. (I beg you to
          offer your Speech as a download from your website, and to publish it,
          or a variation of it, in Software Development magazine, or a
          similar widely read publication.)

          You should find interesting that what provoked me to write my note to
          Extreme Programming, was a similar feeling of dissatisfaction with the
          several discussions I was holding and hearing at the time at
          the list that orbited around 1) comparing agile processes with
          traditional processes, 2) exploratory metaphors to explain
          agile processes, and 3) about techniques from other domains to improve
          and explain agile processes.

          All of these discussions are interesting and productive but somehow
          managed to leave out what I consider they _key differences_
          of agility.

          Superficially, everything that glitters can be confused with
          precious stones. But we get to know as we understand more,
          that there is a difference between zirconias and diamonds i.e.
          between the "real" thing and something that superficially '
          looks like it.

          At times, I often feel that's were we are as a community --
          there is not enough understanding as to why agile is a diamond.

          Clearly statements like:

          XP can be an instance of RUP

          ignore the latent, seldom-unspoken but _fundamental_
          nature of agile processes,

          - Mike



          -----Original Message-----
          From: Ken Schwaber [mailto:ken.schwaber@...]
          Sent: Monday, July 08, 2002 7:55 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution


          Mike,
          I congratulate your focus. We are in danger of this being thought and
          whittled to death. Like the movie, "Death by a Thousand Blows." I had a
          similar feeling at XP2002, which caused my to get up in a rather testy mood
          and give the attached speech to the attendees.
          Ken

          -----Original Message-----
          From: Mike Beedle [mailto:beedlem@...]
          Sent: Monday, July 08, 2002 7:16 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] RE: Agile Software Development Revolution



          (I know most of the people subscribed to this list belong to
          the Extreme Programming mailing list, but just in case some
          of you missed this posting at the Extreme mailing list.....
          here it is. My apologies included if you have received multiple
          copies of this message.)

          Dear agileers,

          It troubles me that the _fundamental differences_ between
          traditional and agile processes are not highlighted,
          either by, we, the creators and supporters of the Agile movement,
          or by traditional software development figure-heads.

          Because if we don't highlight the differences of why Agile
          Software Development processes we run the danger of hearing
          and, worse, accepting that:

          there is nothing really all that new with
          Agile Software Development processes

          This will relinquish Agile Software Development as "one"
          of many other compatible worldviews, and soon Agility will be
          muddled into oblivion.

          Don't take me wrong, I admire and respect the contributions
          of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
          Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
          desperate effort to make sense of Agility, we will find
          that many important concepts are forgotten if we try to equate them
          with their traditional software development counterparts. And that
          misconceptions and misunderstandings will be created like:

          The CMM is compatible with agile processes, or
          XP can be an instance of RUP

          In my opinion, there are radical and fundamental _differences_
          that make Agile Software Development Processes and Traditional Software
          Development Processes two very different ways of developing software
          from the perspective of the nature of their underlying processes:

          Traditional Software Development Processes advocate and
          eventually prescribe a _defined_ and _repeatable software
          engineering process, as well as many other _defined_ and
          _repeatable_ processes that correspond to different
          "process areas". And they are based on the erroneous belief,
          in my opinion, that software can be "manufactured".

          But,

          Agile Software Development Processes, on the other hand,
          use inspection/adaptation feedback cycles that "generate"
          a process by people that self-organize based on the
          application of a set of practices, or patterns really,
          that in an Alexandrian way lead to the emergence of
          an organization and a process. This is stated directly
          in the Agile Principles:

          "The best architectures, requirements, and designs
          emerge from self-organizing teams."
          http://www.agilemanifesto.org/principles.html

          Therefore Agile Software Development Process more
          closely resembles a New Product development process
          like the one described in:

          [NonakaTakeuchi] Takeuchi H. and Nonaka I., The New New Product
          Development Game, Harvard Business Review (January 1986),
          pp. 137-146, 1986.

          In my opinion, this is an important, radical and fundamental
          _difference_, that subtly changes the underlying assumptions
          of why and how things work in a software development process.

          How does this difference affects the people that work on an
          Agile Software Development Process?

          It is this feature of Agility that brings out these essential
          characteristics in an Agile Software Development Process:


          1) Greater Liberty and Freedom

          People in an Agile Software project feel more liberated
          because they feel _free_ to do whatever it takes
          to achieve their goal:

          talk to the customer, think, imagine, code, test, refactor,

          in any order, as many times as they need/want, and as often as
          they need to.


          2) Required Learning, Knowledge Creation and Knowledge Sharing

          People in an Agile Software project are constantly learning,
          and sharing knowledge because by definition Agility is
          based on continuous short feedback cycles of:

          inspection --> adaptation

          where we learn from the customers, from other team members,
          from practitioners in the field, and even from ourselves
          on a daily basis.


          3) A More Enjoyable and Humane Work Environment

          People in an Agile Software project participate in a more
          human "fun-like" way because the more human and intellectual
          activities of research, understanding, imagination,
          creativity, cooperation and sharing are encouraged and required;
          as opposed to being considered just "another station in
          a production line".


          4) A Hyper-productive Cooperative Work Mode

          People in an Agile Software project work in teams that
          exhibit a mode of cooperation that leads to hyper-productivity --
          the dynamic pull-system way that Nonaka and Takeuchi describe in the
          Knowledge Creating Company as the "hypertext" organization.

          This mode of cooperation, taps into the collective
          intelligence and collective knowledge and memory stored
          in the distributed mind of the team and the organization
          as a whole.


          5) The Quality of Life

          Agile Software projects work under the assumption and
          expectation that "emergent" behavior is the only way to
          confront uncertainty. Agile Software projects openly
          accept that it is impossible to:

          outline what tasks are going to be needed
          to complete a software project up-front, and

          get all the requirements up-front, and/or
          design an architecture up-front.

          Rather, the plan, the requirements and the architecture
          of the project, gradually emerge, by constant feedback cycles,
          research and creativity, and constant interaction among
          the participants of the project and the customer.

          This is what gives Agile Software Development teams
          the distinctive feature of "ordered chaos" that
          Life itself uses to accomplish its miraculous chores.

          And therefore, this is what literally makes teams
          more "alive", because teams more closely resemble
          living systems like ant or bee colonies,
          brains, or rugby/soccer/football teams.

          etc.

          For these reasons, which are not all, I hereby declare the
          beginning of a new era in software development, and I therefore
          proclaim officially that the creation of the Agile Manifesto:

          http://www.agilemanifesto.org/

          and its principles:

          http://www.agilemanifesto.org/principles.html

          mark unequivocally the beginning of the:

          Agile Software Development Revolution

          which was created, sponsored and supported by all of
          you brave souls that dared the world by practicing and
          advocating a _new_ Agile way, that makes software development
          different, more productive, more humane and therefore
          clearly better, in my opinion.

          Don't find yourself muddled out by figure-heads ... stay Agile!

          - Mike

          http://www.agilescrum.com
          http://www.xbreed.net


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

          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



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

          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        • Mike Cohn
          A huge problem results from software developers (and certainly development managers) having been trained over the past 20 years or so to want to write down a
          Message 4 of 17 , Jul 8, 2002
          View Source
          • 0 Attachment

            A huge problem results from software developers (and certainly development managers) having been trained over the past 20 years or so to want to write down a list of meta-tasks that must be performed on every project. With agile processes there just isn’t as much to write down—we see this in the size of Ken’s and Mike’s wonderful Scrum book and in the XP series. There are probably fewer words in all those books than in The Unified Software Development Process book. And even at that each of the XP books after the first two added very little. RUP does take 500 dense pages to describe, though.

             

            In organizations filled with people who have been trained to write down their methodologies they look to write down the steps of an agile process—and on the surface that doesn’t seem so evil but it just completely misses the point. I envision organizations with Gantt charts with items like:

             

            Task 3: Have team self-organize, 3 days

            Task 4: Allow requirements to emerge, 5 days

             

            I remember when I first read the Rational article on how RUP could really be XP (http://www.rational.com/media/products/rup/tp183.pdf). I thought it was a joke at first. First, how could any “unified process” be agile? Agile processes have to be ones that adapt to the organizations using them. RUP will always feel like RUP even with some activities removed. The thing that really scared about RUP = XP was that Bob Martin seemed to be endorsing it with his dX process: http://www.objectmentor.com/resources/articles/RUPvsXP.pdf. At least with his paper I couldn’t be sure if he was truly endorsing that as a way to proceed or if he’d written the paper as a thought experiment to see if it really was possible “ to do XP within RUP.”

             

            I remember almost two years ago joking with Ward Cunningham that I was going to come out with an “Extreme Management” methodology which would be centered around the belief that “pair managing” was appropriate and that I would assign two managers to sit at the keyboard with each programmer. Now of course there is something called “Extreme Project Management” from Rob Thomsett (http://www.cutter.com/freestuff/epmr0102.html). I go back and forth on whether this is agile or not—the article appears to be pro-agile (except for odd comments like (XPM Rule 2: The less the project manager knows about the technical issues of the project, the better, which completely scares me!) but his book seems far less so (admittedly I’ve not yet finished reading it).

             

            We’ve also got things like Feature-Driven Development from Togethersoft that appear (to me at least) to be masquerading as agile. I don’t see anything in FDD that is agile—unless you consider delivering software within 4 month sprints agile.

             

            I’ve had the feeling for a few months that while momentum continues in favor of agile methodologies those supplying the momentum are of the “we’re already doing that” variety mentioned in Ken’s XP2002 speech earlier in this thread.

             

            We somehow have to keep at the forefront of the discussion of agile methods that these approaches are revolutionary and that they are not just a different set of tasks to be performed.

             

            --Mike

             

             

            -----Original Message-----
            From: Mike Beedle [mailto:beedlem@...]
            Sent:
            Monday, July 08, 2002 7:38 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

             


            Ken:

            What a joy to read your XP 2002 speech.  I wish I would have been there.
            It is certainly inspiring, provocative and gets the point across:

                   Agile is certainly different and revolutionary

            and your speech explains why -- that's important.  (I beg you to
            offer your Speech as a download from your website, and to publish it,
            or a variation of it, in Software Development magazine, or a
            similar widely read publication.)

            You should find interesting that what provoked me to write my note to
            Extreme Programming, was a similar feeling of dissatisfaction with the
            several discussions I was holding and hearing at the time at
            the list that orbited around 1) comparing agile processes with
            traditional processes, 2)  exploratory metaphors to explain
            agile processes, and 3) about techniques from other domains to improve
            and explain agile processes.

            All of these discussions are interesting and productive but somehow
            managed to leave out what I consider they _key differences_
            of agility.

            Superficially, everything that glitters can be confused with
            precious stones.  But we get to know as we understand more,
            that there is a difference between zirconias and diamonds i.e.
            between the "real" thing and something that superficially '
            looks like it.

            At times, I often feel that's were we are as a community --
            there is not enough understanding as to why agile is a diamond.

            Clearly statements like:

                  XP can be an instance of RUP

            ignore the latent, seldom-unspoken but _fundamental_
            nature of agile processes,

            - Mike



            -----Original Message-----
            From: Ken Schwaber [mailto:ken.schwaber@...]
            Sent:
            Monday, July 08, 2002 7:55 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution


            Mike,
            I congratulate your focus. We are in danger of this being thought and
            whittled to death. Like the movie, "Death by a Thousand Blows." I had a
            similar feeling at XP2002, which caused my to get up in a rather testy mood
            and give the attached speech to the attendees.
            Ken

            -----Original Message-----
            From: Mike Beedle [mailto:beedlem@...]
            Sent:
            Monday, July 08, 2002 7:16 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] RE: Agile Software Development Revolution



            (I know most of the people subscribed to this list belong to
            the Extreme Programming mailing list, but just in case some
            of you missed this posting at the Extreme mailing list.....
            here it is.  My apologies included if you have received multiple
            copies of this message.)

            Dear agileers,

            It troubles me that the _fundamental differences_  between
            traditional and agile processes are not highlighted,
            either by, we, the creators and supporters of the Agile movement,
            or by traditional software development figure-heads.

            Because if we don't highlight the differences of why Agile
            Software Development processes we run the danger of hearing
            and, worse, accepting that:

                  there is nothing really all that new with
                  Agile Software Development processes

            This will relinquish Agile Software Development as "one"
            of many other compatible worldviews, and soon Agility will be
            muddled into oblivion.

            Don't take me wrong, I admire and respect the contributions
            of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
            Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
            desperate effort to make sense of Agility, we will find
            that many important concepts are forgotten if we try to equate them
            with their traditional software development counterparts.  And that
            misconceptions and misunderstandings will be created like:

                  The CMM is compatible with agile processes, or
                  XP can be an instance of RUP

            In my opinion, there are radical and fundamental _differences_
            that make Agile Software Development Processes and Traditional Software
            Development Processes two very different ways of developing software
            from the perspective of the nature of their underlying processes:

                  Traditional Software Development Processes advocate and
                  eventually prescribe a _defined_ and _repeatable software
                  engineering process, as well as many other _defined_ and
                  _repeatable_ processes that correspond to different
                  "process areas".  And they are based on the erroneous belief,
                  in my opinion, that software can be "manufactured".

            But,

                  Agile Software Development Processes, on the other hand,
                  use inspection/adaptation feedback cycles that "generate"
                  a process by people that self-organize based on the
                  application of a set of practices, or patterns really,
                  that in an Alexandrian way lead to the emergence of
                  an organization and a process.  This is stated directly
                  in the Agile Principles:

                  "The best architectures, requirements, and designs
                  emerge from self-organizing teams."
                  http://www.agilemanifesto.org/principles.html

                  Therefore Agile Software Development Process more
                  closely resembles a New Product development process
                  like the one described in:

                  [NonakaTakeuchi] Takeuchi H. and
            Nonaka I., The New New Product
                  Development Game, Harvard Business Review (January 1986),
                  pp. 137-146, 1986.

            In my opinion, this is an important, radical and fundamental
            _difference_, that subtly changes the underlying assumptions
            of why and how things work in a software development process.

            How does this difference affects the people that work on an
            Agile Software Development Process?

            It is this feature of Agility that brings out these essential
            characteristics in an Agile Software Development Process:


                  1) Greater
            Liberty and Freedom

                  People in an Agile Software project feel more liberated
                  because they feel _free_ to do whatever it takes
                  to achieve their goal:

                        talk to the customer, think, imagine, code, test, refactor,

                  in any order, as many times as they need/want, and as often as
                  they need to.


                  2) Required Learning, Knowledge Creation and Knowledge Sharing

                  People in an Agile Software project are constantly learning,
                  and sharing knowledge because by definition Agility is
                  based on continuous short feedback cycles of:

                        inspection --> adaptation

                  where we learn from the customers, from other team members,
                  from practitioners in the field, and even from ourselves
                  on a daily basis.


                  3) A More Enjoyable and Humane Work Environment

                  People in an Agile Software project participate in a more
                  human "fun-like" way because the more human and intellectual
                  activities of research, understanding, imagination,
                  creativity, cooperation and sharing are encouraged and required;
                  as opposed to being considered just "another station in
                  a production line".


                  4) A Hyper-productive Cooperative Work Mode

                  People in an Agile Software project work in teams that
                  exhibit a mode of cooperation that leads to hyper-productivity --
                  the dynamic pull-system way that Nonaka and Takeuchi describe in the
                  Knowledge Creating Company as the "hypertext" organization.

                  This mode of cooperation, taps into the collective
                  intelligence and collective knowledge and memory stored
                  in the distributed mind of the team and the organization
                  as a whole.


                  5) The Quality of Life

                  Agile Software projects work under the assumption and
                  expectation that "emergent" behavior is the only way to
                  confront uncertainty.  Agile Software projects openly
                  accept that it is impossible to:

                        outline what tasks are going to be needed
                        to complete a software project up-front, and

                        get all the requirements up-front, and/or
                        design an architecture up-front.

                  Rather, the plan, the requirements and the architecture
                  of the project, gradually emerge, by constant feedback cycles,
                  research and creativity, and constant interaction among
                  the participants of the project and the customer.

                  This is what gives Agile Software Development teams
                  the distinctive feature of "ordered chaos" that
                  Life itself uses to accomplish its miraculous chores.

                  And therefore, this is what literally makes teams
                  more "alive", because teams more closely resemble
                  living systems like ant or bee colonies,
                  brains, or rugby/soccer/football teams.

                  etc.

            For these reasons, which are not all, I hereby declare the
            beginning of a new era in software development, and I therefore
            proclaim officially that the creation of the Agile Manifesto:

                  http://www.agilemanifesto.org/

            and its principles:

                  http://www.agilemanifesto.org/principles.html

            mark unequivocally the beginning of the:

                  Agile Software Development Revolution

            which was created, sponsored and supported by all of
            you brave souls that dared the world by practicing and
            advocating a _new_ Agile way, that makes software development
            different, more productive, more humane and therefore
            clearly better, in my opinion.

            Don't find yourself muddled out by figure-heads ... stay Agile!

            - Mike

            http://www.agilescrum.com
            http://www.xbreed.net


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

            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



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

            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



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


            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          • Ken Schwaber
            Mike, I ll have to remember these two tasks (3 and 4) for my next project. What a parody! Barry Boehm and a lot of other respected people like him are the
            Message 5 of 17 , Jul 8, 2002
            View Source
            • 0 Attachment
              Mike,
              I'll have to remember these two tasks (3 and 4) for my next project. What a parody!
               
              Barry Boehm and a lot of other respected people like him are the worst thing that could happen to agile. They don't get it; they think agile is a task3, task4 thing that is really "lightweight", but not something radically new. They are part of the problem, not part of the solution. And it seems that the more we work with them, the more we lose our focus and they redefine agile into "just a small change." It must feel like this when a religion gets institutionalized into a church, with all of the rituals and power structures.
               
              Ken
              -----Original Message-----
              From: Mike Cohn [mailto:mike@...]
              Sent: Monday, July 08, 2002 11:00 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

              A huge problem results from software developers (and certainly development managers) having been trained over the past 20 years or so to want to write down a list of meta-tasks that must be performed on every project. With agile processes there just isn’t as much to write down—we see this in the size of Ken’s and Mike’s wonderful Scrum book and in the XP series. There are probably fewer words in all those books than in The Unified Software Development Process book. And even at that each of the XP books after the first two added very little. RUP does take 500 dense pages to describe, though.

               

              In organizations filled with people who have been trained to write down their methodologies they look to write down the steps of an agile process—and on the surface that doesn’t seem so evil but it just completely misses the point. I envision organizations with Gantt charts with items like:

               

              Task 3: Have team self-organize, 3 days

              Task 4: Allow requirements to emerge, 5 days

               

              I remember when I first read the Rational article on how RUP could really be XP (http://www.rational.com/media/products/rup/tp183.pdf). I thought it was a joke at first. First, how could any “unified process” be agile? Agile processes have to be ones that adapt to the organizations using them. RUP will always feel like RUP even with some activities removed. The thing that really scared about RUP = XP was that Bob Martin seemed to be endorsing it with his dX process: http://www.objectmentor.com/resources/articles/RUPvsXP.pdf. At least with his paper I couldn’t be sure if he was truly endorsing that as a way to proceed or if he’d written the paper as a thought experiment to see if it really was possible “ to do XP within RUP.”

               

              I remember almost two years ago joking with Ward Cunningham that I was going to come out with an “Extreme Management” methodology which would be centered around the belief that “pair managing” was appropriate and that I would assign two managers to sit at the keyboard with each programmer. Now of course there is something called “Extreme Project Management” from Rob Thomsett (http://www.cutter.com/freestuff/epmr0102.html). I go back and forth on whether this is agile or not—the article appears to be pro-agile (except for odd comments like (XPM Rule 2: The less the project manager knows about the technical issues of the project, the better, which completely scares me!) but his book seems far less so (admittedly I’ve not yet finished reading it).

               

              We’ve also got things like Feature-Driven Development from Togethersoft that appear (to me at least) to be masquerading as agile. I don’t see anything in FDD that is agile—unless you consider delivering software within 4 month sprints agile.

               

              I’ve had the feeling for a few months that while momentum continues in favor of agile methodologies those supplying the momentum are of the “we’re already doing that” variety mentioned in Ken’s XP2002 speech earlier in this thread.

               

              We somehow have to keep at the forefront of the discussion of agile methods that these approaches are revolutionary and that they are not just a different set of tasks to be performed.

               

              --Mike

               

               

              -----Original Message-----
              From: Mike Beedle [mailto:beedlem@...]
              Sent:
              Monday, July 08, 2002 7:38 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

               


              Ken:

              What a joy to read your XP 2002 speech.  I wish I would have been there.
              It is certainly inspiring, provocative and gets the point across:

                     Agile is certainly different and revolutionary

              and your speech explains why -- that's important.  (I beg you to
              offer your Speech as a download from your website, and to publish it,
              or a variation of it, in Software Development magazine, or a
              similar widely read publication.)

              You should find interesting that what provoked me to write my note to
              Extreme Programming, was a similar feeling of dissatisfaction with the
              several discussions I was holding and hearing at the time at
              the list that orbited around 1) comparing agile processes with
              traditional processes, 2)  exploratory metaphors to explain
              agile processes, and 3) about techniques from other domains to improve
              and explain agile processes.

              All of these discussions are interesting and productive but somehow
              managed to leave out what I consider they _key differences_
              of agility.

              Superficially, everything that glitters can be confused with
              precious stones.  But we get to know as we understand more,
              that there is a difference between zirconias and diamonds i.e.
              between the "real" thing and something that superficially '
              looks like it.

              At times, I often feel that's were we are as a community --
              there is not enough understanding as to why agile is a diamond.

              Clearly statements like:

                    XP can be an instance of RUP

              ignore the latent, seldom-unspoken but _fundamental_
              nature of agile processes,

              - Mike



              -----Original Message-----
              From: Ken Schwaber [mailto:ken.schwaber@...]
              Sent:
              Monday, July 08, 2002 7:55 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution


              Mike,
              I congratulate your focus. We are in danger of this being thought and
              whittled to death. Like the movie, "Death by a Thousand Blows." I had a
              similar feeling at XP2002, which caused my to get up in a rather testy mood
              and give the attached speech to the attendees.
              Ken

              -----Original Message-----
              From: Mike Beedle [mailto:beedlem@...]
              Sent:
              Monday, July 08, 2002 7:16 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] RE: Agile Software Development Revolution



              (I know most of the people subscribed to this list belong to
              the Extreme Programming mailing list, but just in case some
              of you missed this posting at the Extreme mailing list.....
              here it is.  My apologies included if you have received multiple
              copies of this message.)

              Dear agileers,

              It troubles me that the _fundamental differences_  between
              traditional and agile processes are not highlighted,
              either by, we, the creators and supporters of the Agile movement,
              or by traditional software development figure-heads.

              Because if we don't highlight the differences of why Agile
              Software Development processes we run the danger of hearing
              and, worse, accepting that:

                    there is nothing really all that new with
                    Agile Software Development processes

              This will relinquish Agile Software Development as "one"
              of many other compatible worldviews, and soon Agility will be
              muddled into oblivion.

              Don't take me wrong, I admire and respect the contributions
              of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
              Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
              desperate effort to make sense of Agility, we will find
              that many important concepts are forgotten if we try to equate them
              with their traditional software development counterparts.  And that
              misconceptions and misunderstandings will be created like:

                    The CMM is compatible with agile processes, or
                    XP can be an instance of RUP

              In my opinion, there are radical and fundamental _differences_
              that make Agile Software Development Processes and Traditional Software
              Development Processes two very different ways of developing software
              from the perspective of the nature of their underlying processes:

                    Traditional Software Development Processes advocate and
                    eventually prescribe a _defined_ and _repeatable software
                    engineering process, as well as many other _defined_ and
                    _repeatable_ processes that correspond to different
                    "process areas".  And they are based on the erroneous belief,
                    in my opinion, that software can be "manufactured".

              But,

                    Agile Software Development Processes, on the other hand,
                    use inspection/adaptation feedback cycles that "generate"
                    a process by people that self-organize based on the
                    application of a set of practices, or patterns really,
                    that in an Alexandrian way lead to the emergence of
                    an organization and a process.  This is stated directly
                    in the Agile Principles:

                    "The best architectures, requirements, and designs
                    emerge from self-organizing teams."
                    http://www.agilemanifesto.org/principles.html

                    Therefore Agile Software Development Process more
                    closely resembles a New Product development process
                    like the one described in:

                    [NonakaTakeuchi] Takeuchi H. and
              Nonaka I., The New New Product
                    Development Game, Harvard Business Review (January 1986),
                    pp. 137-146, 1986.

              In my opinion, this is an important, radical and fundamental
              _difference_, that subtly changes the underlying assumptions
              of why and how things work in a software development process.

              How does this difference affects the people that work on an
              Agile Software Development Process?

              It is this feature of Agility that brings out these essential
              characteristics in an Agile Software Development Process:


                    1) Greater
              Liberty and Freedom

                    People in an Agile Software project feel more liberated
                    because they feel _free_ to do whatever it takes
                    to achieve their goal:

                          talk to the customer, think, imagine, code, test, refactor,

                    in any order, as many times as they need/want, and as often as
                    they need to.


                    2) Required Learning, Knowledge Creation and Knowledge Sharing

                    People in an Agile Software project are constantly learning,
                    and sharing knowledge because by definition Agility is
                    based on continuous short feedback cycles of:

                          inspection --> adaptation

                    where we learn from the customers, from other team members,
                    from practitioners in the field, and even from ourselves
                    on a daily basis.


                    3) A More Enjoyable and Humane Work Environment

                    People in an Agile Software project participate in a more
                    human "fun-like" way because the more human and intellectual
                    activities of research, understanding, imagination,
                    creativity, cooperation and sharing are encouraged and required;
                    as opposed to being considered just "another station in
                    a production line".


                    4) A Hyper-productive Cooperative Work Mode

                    People in an Agile Software project work in teams that
                    exhibit a mode of cooperation that leads to hyper-productivity --
                    the dynamic pull-system way that Nonaka and Takeuchi describe in the
                    Knowledge Creating Company as the "hypertext" organization.

                    This mode of cooperation, taps into the collective
                    intelligence and collective knowledge and memory stored
                    in the distributed mind of the team and the organization
                    as a whole.


                    5) The Quality of Life

                    Agile Software projects work under the assumption and
                    expectation that "emergent" behavior is the only way to
                    confront uncertainty.  Agile Software projects openly
                    accept that it is impossible to:

                          outline what tasks are going to be needed
                          to complete a software project up-front, and

                          get all the requirements up-front, and/or
                          design an architecture up-front.

                    Rather, the plan, the requirements and the architecture
                    of the project, gradually emerge, by constant feedback cycles,
                    research and creativity, and constant interaction among
                    the participants of the project and the customer.

                    This is what gives Agile Software Development teams
                    the distinctive feature of "ordered chaos" that
                    Life itself uses to accomplish its miraculous chores.

                    And therefore, this is what literally makes teams
                    more "alive", because teams more closely resemble
                    living systems like ant or bee colonies,
                    brains, or rugby/soccer/football teams.

                    etc.

              For these reasons, which are not all, I hereby declare the
              beginning of a new era in software development, and I therefore
              proclaim officially that the creation of the Agile Manifesto:

                    http://www.agilemanifesto.org/

              and its principles:

                    http://www.agilemanifesto.org/principles.html

              mark unequivocally the beginning of the:

                    Agile Software Development Revolution

              which was created, sponsored and supported by all of
              you brave souls that dared the world by practicing and
              advocating a _new_ Agile way, that makes software development
              different, more productive, more humane and therefore
              clearly better, in my opinion.

              Don't find yourself muddled out by figure-heads ... stay Agile!

              - Mike

              http://www.agilescrum.com
              http://www.xbreed.net


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

              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



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

              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



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


              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.




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


              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            • Mike Cohn
              You re right. I was shocked to Boehm speaking at XPUniverse but I ll be anxious to hear what he has to say. The Spiral Model definitely was a major
              Message 6 of 17 , Jul 8, 2002
              View Source
              • 0 Attachment

                You’re right. I was shocked to Boehm speaking at XPUniverse but I’ll be anxious to hear what he has to say. The Spiral Model definitely was a major contribution and helped lead to agile in some ways but it isn’t an agile process in itself. Some of Boehm’s Win-Win and later stuff is similarly interesting reading but seems to miss some key points of agility.

                 

                On the RUP subject I did like Jim Highsmith’s point (in his Ecosystems book) that he thought RUP probably started out to be more agile (or probably just “more lightweight” which definitely isn’t the same thing) than it ended up. For example, Booch’s “Object Solutions” book was very good and has relevant advice in it about how to build systems. To be honest, I couldn’t even finish the RUP book by Jacobsen [Booch and Rumbaugh]. I stack those two books together and can’t help but think that RUP was more Jacobsen and Objectory than anything else.

                 

                Mike

                 

                -----Original Message-----
                From: Ken Schwaber [mailto:ken.schwaber@...]
                Sent: Monday, July 08, 2002 11:03 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

                 

                Mike,

                I'll have to remember these two tasks (3 and 4) for my next project. What a parody!

                 

                Barry Boehm and a lot of other respected people like him are the worst thing that could happen to agile. They don't get it; they think agile is a task3, task4 thing that is really "lightweight", but not something radically new. They are part of the problem, not part of the solution. And it seems that the more we work with them, the more we lose our focus and they redefine agile into "just a small change." It must feel like this when a religion gets institutionalized into a church, with all of the rituals and power structures.

                 

                Ken

                -----Original Message-----
                From: Mike Cohn [mailto:mike@...]
                Sent: Monday, July 08, 2002 11:00 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

                A huge problem results from software developers (and certainly development managers) having been trained over the past 20 years or so to want to write down a list of meta-tasks that must be performed on every project. With agile processes there just isn’t as much to write down—we see this in the size of Ken’s and Mike’s wonderful Scrum book and in the XP series. There are probably fewer words in all those books than in The Unified Software Development Process book. And even at that each of the XP books after the first two added very little. RUP does take 500 dense pages to describe, though.

                 

                In organizations filled with people who have been trained to write down their methodologies they look to write down the steps of an agile process—and on the surface that doesn’t seem so evil but it just completely misses the point. I envision organizations with Gantt charts with items like:

                 

                Task 3: Have team self-organize, 3 days

                Task 4: Allow requirements to emerge, 5 days

                 

                I remember when I first read the Rational article on how RUP could really be XP (http://www.rational.com/media/products/rup/tp183.pdf). I thought it was a joke at first. First, how could any “unified process” be agile? Agile processes have to be ones that adapt to the organizations using them. RUP will always feel like RUP even with some activities removed. The thing that really scared about RUP = XP was that Bob Martin seemed to be endorsing it with his dX process: http://www.objectmentor.com/resources/articles/RUPvsXP.pdf. At least with his paper I couldn’t be sure if he was truly endorsing that as a way to proceed or if he’d written the paper as a thought experiment to see if it really was possible “ to do XP within RUP.”

                 

                I remember almost two years ago joking with Ward Cunningham that I was going to come out with an “Extreme Management” methodology which would be centered around the belief that “pair managing” was appropriate and that I would assign two managers to sit at the keyboard with each programmer. Now of course there is something called “Extreme Project Management” from Rob Thomsett (http://www.cutter.com/freestuff/epmr0102.html). I go back and forth on whether this is agile or not—the article appears to be pro-agile (except for odd comments like (XPM Rule 2: The less the project manager knows about the technical issues of the project, the better, which completely scares me!) but his book seems far less so (admittedly I’ve not yet finished reading it).

                 

                We’ve also got things like Feature-Driven Development from Togethersoft that appear (to me at least) to be masquerading as agile. I don’t see anything in FDD that is agile—unless you consider delivering software within 4 month sprints agile.

                 

                I’ve had the feeling for a few months that while momentum continues in favor of agile methodologies those supplying the momentum are of the “we’re already doing that” variety mentioned in Ken’s XP2002 speech earlier in this thread.

                 

                We somehow have to keep at the forefront of the discussion of agile methods that these approaches are revolutionary and that they are not just a different set of tasks to be performed.

                 

                --Mike

                 

                 

                -----Original Message-----
                From: Mike Beedle [mailto:beedlem@...]
                Sent: Monday, July 08, 2002 7:38 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

                 


                Ken:

                What a joy to read your XP 2002 speech.  I wish I would have been there.
                It is certainly inspiring, provocative and gets the point across:

                       Agile is certainly different and revolutionary

                and your speech explains why -- that's important.  (I beg you to
                offer your Speech as a download from your website, and to publish it,
                or a variation of it, in Software Development magazine, or a
                similar widely read publication.)

                You should find interesting that what provoked me to write my note to
                Extreme Programming, was a similar feeling of dissatisfaction with the
                several discussions I was holding and hearing at the time at
                the list that orbited around 1) comparing agile processes with
                traditional processes, 2)  exploratory metaphors to explain
                agile processes, and 3) about techniques from other domains to improve
                and explain agile processes.

                All of these discussions are interesting and productive but somehow
                managed to leave out what I consider they _key differences_
                of agility.

                Superficially, everything that glitters can be confused with
                precious stones.  But we get to know as we understand more,
                that there is a difference between zirconias and diamonds i.e.
                between the "real" thing and something that superficially '
                looks like it.

                At times, I often feel that's were we are as a community --
                there is not enough understanding as to why agile is a diamond.

                Clearly statements like:

                      XP can be an instance of RUP

                ignore the latent, seldom-unspoken but _fundamental_
                nature of agile processes,

                - Mike



                -----Original Message-----
                From: Ken Schwaber [mailto:ken.schwaber@...]
                Sent: Monday, July 08, 2002 7:55 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution


                Mike,
                I congratulate your focus. We are in danger of this being thought and
                whittled to death. Like the movie, "Death by a Thousand Blows." I had a
                similar feeling at XP2002, which caused my to get up in a rather testy mood
                and give the attached speech to the attendees.
                Ken

                -----Original Message-----
                From: Mike Beedle [mailto:beedlem@...]
                Sent: Monday, July 08, 2002 7:16 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] RE: Agile Software Development Revolution



                (I know most of the people subscribed to this list belong to
                the Extreme Programming mailing list, but just in case some
                of you missed this posting at the Extreme mailing list.....
                here it is.  My apologies included if you have received multiple
                copies of this message.)

                Dear agileers,

                It troubles me that the _fundamental differences_  between
                traditional and agile processes are not highlighted,
                either by, we, the creators and supporters of the Agile movement,
                or by traditional software development figure-heads.

                Because if we don't highlight the differences of why Agile
                Software Development processes we run the danger of hearing
                and, worse, accepting that:

                      there is nothing really all that new with
                      Agile Software Development processes

                This will relinquish Agile Software Development as "one"
                of many other compatible worldviews, and soon Agility will be
                muddled into oblivion.

                Don't take me wrong, I admire and respect the contributions
                of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
                Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
                desperate effort to make sense of Agility, we will find
                that many important concepts are forgotten if we try to equate them
                with their traditional software development counterparts.  And that
                misconceptions and misunderstandings will be created like:

                      The CMM is compatible with agile processes, or
                      XP can be an instance of RUP

                In my opinion, there are radical and fundamental _differences_
                that make Agile Software Development Processes and Traditional Software
                Development Processes two very different ways of developing software
                from the perspective of the nature of their underlying processes:

                      Traditional Software Development Processes advocate and
                      eventually prescribe a _defined_ and _repeatable software
                      engineering process, as well as many other _defined_ and
                      _repeatable_ processes that correspond to different
                      "process areas".  And they are based on the erroneous belief,
                      in my opinion, that software can be "manufactured".

                But,

                      Agile Software Development Processes, on the other hand,
                      use inspection/adaptation feedback cycles that "generate"
                      a process by people that self-organize based on the
                      application of a set of practices, or patterns really,
                      that in an Alexandrian way lead to the emergence of
                      an organization and a process.  This is stated directly
                      in the Agile Principles:

                      "The best architectures, requirements, and designs
                      emerge from self-organizing teams."
                      http://www.agilemanifesto.org/principles.html

                      Therefore Agile Software Development Process more
                      closely resembles a New Product development process
                      like the one described in:

                      [NonakaTakeuchi] Takeuchi H. and Nonaka I., The New New Product
                      Development Game, Harvard Business Review (January 1986),
                      pp. 137-146, 1986.

                In my opinion, this is an important, radical and fundamental
                _difference_, that subtly changes the underlying assumptions
                of why and how things work in a software development process.

                How does this difference affects the people that work on an
                Agile Software Development Process?

                It is this feature of Agility that brings out these essential
                characteristics in an Agile Software Development Process:


                      1) Greater Liberty and Freedom

                      People in an Agile Software project feel more liberated
                      because they feel _free_ to do whatever it takes
                      to achieve their goal:

                            talk to the customer, think, imagine, code, test, refactor,

                      in any order, as many times as they need/want, and as often as
                      they need to.


                      2) Required Learning, Knowledge Creation and Knowledge Sharing

                      People in an Agile Software project are constantly learning,
                      and sharing knowledge because by definition Agility is
                      based on continuous short feedback cycles of:

                            inspection --> adaptation

                      where we learn from the customers, from other team members,
                      from practitioners in the field, and even from ourselves
                      on a daily basis.


                      3) A More Enjoyable and Humane Work Environment

                      People in an Agile Software project participate in a more
                      human "fun-like" way because the more human and intellectual
                      activities of research, understanding, imagination,
                      creativity, cooperation and sharing are encouraged and required;
                      as opposed to being considered just "another station in
                      a production line".


                      4) A Hyper-productive Cooperative Work Mode

                      People in an Agile Software project work in teams that
                      exhibit a mode of cooperation that leads to hyper-productivity --
                      the dynamic pull-system way that Nonaka and Takeuchi describe in the
                      Knowledge Creating Company as the "hypertext" organization.

                      This mode of cooperation, taps into the collective
                      intelligence and collective knowledge and memory stored
                      in the distributed mind of the team and the organization
                      as a whole.


                      5) The Quality of Life

                      Agile Software projects work under the assumption and
                      expectation that "emergent" behavior is the only way to
                      confront uncertainty.  Agile Software projects openly
                      accept that it is impossible to:

                            outline what tasks are going to be needed
                            to complete a software project up-front, and

                            get all the requirements up-front, and/or
                            design an architecture up-front.

                      Rather, the plan, the requirements and the architecture
                      of the project, gradually emerge, by constant feedback cycles,
                      research and creativity, and constant interaction among
                      the participants of the project and the customer.

                      This is what gives Agile Software Development teams
                      the distinctive feature of "ordered chaos" that
                      Life itself uses to accomplish its miraculous chores.

                      And therefore, this is what literally makes teams
                      more "alive", because teams more closely resemble
                      living systems like ant or bee colonies,
                      brains, or rugby/soccer/football teams.

                      etc.

                For these reasons, which are not all, I hereby declare the
                beginning of a new era in software development, and I therefore
                proclaim officially that the creation of the Agile Manifesto:

                      http://www.agilemanifesto.org/

                and its principles:

                      http://www.agilemanifesto.org/principles.html

                mark unequivocally the beginning of the:

                      Agile Software Development Revolution

                which was created, sponsored and supported by all of
                you brave souls that dared the world by practicing and
                advocating a _new_ Agile way, that makes software development
                different, more productive, more humane and therefore
                clearly better, in my opinion.

                Don't find yourself muddled out by figure-heads ... stay Agile!

                - Mike

                http://www.agilescrum.com
                http://www.xbreed.net


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

                Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



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

                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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


                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

                 



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


                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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


                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

              • Mike Beedle
                Mike: Well said: the intellectual baggage of _defined_ processes carried over from previous lives, projects, related experience, and education causes for most
                Message 7 of 17 , Jul 9, 2002
                View Source
                • 0 Attachment
                  Mike:

                  Well said:

                  the intellectual baggage of _defined_ processes
                  carried over from previous lives, projects, related
                  experience, and education causes for most
                  metaphor-block and dysfunctional translation.
                  (What a challenge we have ahead of us!!!)

                  That's why it is so important to have good mentors,
                  experienced Scrum masters, and experienced developers,
                  that understand, at least in a tacit way that there
                  is a _fundamental_ difference of Agile vs. Traditional
                  (defined) software development.

                  Also, just like Ken said, I'll have to add these ones
                  to the next Gantt chart I see:

                  Task 3: Have teams self-organize, 3 days
                  Task 4: Allow requirements to emerge, 5 days

                  :-) :-) ;-)

                  And I'll eve add a few more:

                  Task 5: Turn the Management pyramid upside down
                  Task 6: Adopt Agile Values

                  More relevant to Scrum, and to continue the parody above,
                  I often see trained Team Leaders and Managers
                  walking into the Scrum meeting assigning tasks and
                  expecting direct reports like (to continue the parody):

                  "Your _assigned_ task yesterday was to adopt the
                  Agile Values, were you able to do that?

                  No?!!

                  _You are having issues again_. _Report_
                  to me your any progress you are able to make
                  by tomorrow."

                  They think that management _asigns_ tasks, that it
                  is developers who have issues to resolve, and that
                  developers should _report_ back to them in the morning.

                  What we mean in Scrum is:

                  Let me hear how things went and see how we, the
                  team, can help you

                  Let me hear any issues you have that go beyond
                  your control so I can help you

                  and

                  Let me hear what new tasks _you are choosing_ to
                  work on next and see how we, the team, can help you

                  instead of:

                  I assign tasks to you every day

                  you must tell me the issues you may have and
                  solve them

                  and

                  you report to me every day

                  (Definitely NOT the spirit of Scrum)

                  Attitude for the most part is what makes Scrum different than
                  micromanagement and Master/Slave direct management and
                  reporting,

                  - Mike
                • Jonas Bengtsson
                  Mike, Mike, Everybody: I like these. Can t someone put together a nice article that describe these, and similar, in length? As an anti-pattern (of course :-) )
                  Message 8 of 17 , Jul 9, 2002
                  View Source
                  • 0 Attachment
                    Mike, Mike, Everybody:

                    I like these. Can't someone put together a nice article that describe these,
                    and similar, in length? As an anti-pattern (of course :-) ) for adaption of
                    agile. I think it's a good way to describe how agile is different.

                    Regards,
                    Jonas

                    > Task 3: Have teams self-organize, 3 days
                    > Task 4: Allow requirements to emerge, 5 days
                    > Task 5: Turn the Management pyramid upside down
                    > Task 6: Adopt Agile Values
                  • Mike Beedle
                    ... Ken: I didn t have the courage to put it quite on these words, but yes, I wholeheartedly agree. If people hear believable misconceptions, half truths, or
                    Message 9 of 17 , Jul 9, 2002
                    View Source
                    • 0 Attachment
                      Ken wrote:
                      > Barry Boehm and a lot of other respected people like
                      > him are the worst thing that could happen to agile.
                      > They don't get it; they think agile is a task3, task4
                      > thing that is really "lightweight", but not something
                      > radically new. They are part of the problem, not
                      > part of the solution. And it seems that the more we
                      > work with them, the more we lose our focus and
                      > they redefine agile into "just a small change."

                      Ken:

                      I didn't have the courage to put it quite on these words,
                      but yes, I wholeheartedly agree. If people hear believable
                      misconceptions, half truths, or just plain ole illed advice
                      from figure heads like:

                      * XP can be an instance or RUP

                      * Agile processes are _defined_ ETVX processes and
                      are CMM compatible

                      * Agile processes are just lightweight processes

                      * We've done _all_ of this for the last 30 years

                      etc.

                      Agile will be reduced to whatever else they want and it
                      to be, and the agile concept will be so muddled and garbled
                      that it will be hard to tell, specially for new comers,
                      what Software Agility really is or is not.

                      An old quote comes to mind, in 1982, Tim Rentsch said:

                      " ...object oriented programming will be in the 1980's
                      what structured programming was in the 1970's. Everyone
                      will be in favor of it. Every manufacturer will promote
                      his products as supporting it. Every manager will pay
                      lip service to it. Every programmer will practice it
                      (differently). And no one will know just what it is."

                      [Rentsch82]
                      Nguyen, Van and Hailpern, Brent "A Generalized Object Model",
                      ACM SIGPLAN NOTICES, v17, n9 Ed: G. Richard Wexelblat,
                      September 1982

                      So let me translate it to the agile software development:

                      " ...Agile Software Development will be in the 2000's
                      what Defined-Process Software Development was in the 1980's.
                      Everyone will be in favor of it. Every manufacturer will promote
                      his products as supporting it. Every manager will pay
                      lip service to it. Every programmer will practice it
                      (differently). And no one will know just what it is."

                      The scary part is that Rentsch's observations were valid
                      also in the 1990's, so if history repeats itself, we are
                      talking about an absorption rate of 20-30 years or so,

                      - Mike
                    • Ken Schwaber
                      MIke, Linda Rising is the bard and songstress of agile. I hope she takes these from village to village so people understand better. Ken ... From: Mike Beedle
                      Message 10 of 17 , Jul 9, 2002
                      View Source
                      • 0 Attachment
                        MIke,
                        Linda Rising is the bard and songstress of agile. I hope she takes these
                        from village to village so people understand better.
                        Ken

                        -----Original Message-----
                        From: Mike Beedle [mailto:beedlem@...]
                        Sent: Tuesday, July 09, 2002 4:50 AM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: RE: [scrumdevelopment] RE: Agile Software Development
                        Revolution



                        Mike:

                        Well said:

                        the intellectual baggage of _defined_ processes
                        carried over from previous lives, projects, related
                        experience, and education causes for most
                        metaphor-block and dysfunctional translation.
                        (What a challenge we have ahead of us!!!)

                        That's why it is so important to have good mentors,
                        experienced Scrum masters, and experienced developers,
                        that understand, at least in a tacit way that there
                        is a _fundamental_ difference of Agile vs. Traditional
                        (defined) software development.

                        Also, just like Ken said, I'll have to add these ones
                        to the next Gantt chart I see:

                        Task 3: Have teams self-organize, 3 days
                        Task 4: Allow requirements to emerge, 5 days

                        :-) :-) ;-)

                        And I'll eve add a few more:

                        Task 5: Turn the Management pyramid upside down
                        Task 6: Adopt Agile Values

                        More relevant to Scrum, and to continue the parody above,
                        I often see trained Team Leaders and Managers
                        walking into the Scrum meeting assigning tasks and
                        expecting direct reports like (to continue the parody):

                        "Your _assigned_ task yesterday was to adopt the
                        Agile Values, were you able to do that?

                        No?!!

                        _You are having issues again_. _Report_
                        to me your any progress you are able to make
                        by tomorrow."

                        They think that management _asigns_ tasks, that it
                        is developers who have issues to resolve, and that
                        developers should _report_ back to them in the morning.

                        What we mean in Scrum is:

                        Let me hear how things went and see how we, the
                        team, can help you

                        Let me hear any issues you have that go beyond
                        your control so I can help you

                        and

                        Let me hear what new tasks _you are choosing_ to
                        work on next and see how we, the team, can help you

                        instead of:

                        I assign tasks to you every day

                        you must tell me the issues you may have and
                        solve them

                        and

                        you report to me every day

                        (Definitely NOT the spirit of Scrum)

                        Attitude for the most part is what makes Scrum different than
                        micromanagement and Master/Slave direct management and
                        reporting,

                        - Mike


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

                        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                      • mpoppendieck
                        I have a couple of observations. Observation 1: Every movement I know of – Just-in-Time, Quality, Lean Manufacturing, Theory of Constraints, you name it –
                        Message 11 of 17 , Jul 9, 2002
                        View Source
                        • 0 Attachment
                          I have a couple of observations.

                          Observation 1:

                          Every movement I know of – Just-in-Time, Quality, Lean
                          Manufacturing, Theory of Constraints, you name it – has been
                          misunderstood and misapplied by people who size on a piece of the
                          message. People looking for a formula or sliver bullet always
                          seem to miss the fundamentals. At the core, every one of these
                          movements focuses on team empowerment, providing customer value, and
                          moving from a parochial to a holistic view of the system. In every
                          case, these `movements' emphasize that the manager must act
                          as a coach, provide training, and help the team understand and
                          achieve overall business value.

                          If these very worthy paradigm shifts are mis-applied more often than
                          used correctly, why would we think that agile development would be
                          immune from the same fate?

                          Observation 2:

                          I worry about stereotyping managers as people who assign tasks and
                          check that they are done. I know many managers who understand their
                          role to be coaching, training, supporting, and providing a valuable
                          business mission to an empowered team. Okay, so most of them are in
                          operations or product development, but that just goes to show the
                          JIT/TQM/Lean/TOC movements have had some positive impact.

                          We can't influence people who feel we do not respect them.

                          Mary Poppendieck
                          www.LeanProgramming.com
                        • Mike Cohn
                          You re right, Mike! I ve heard that quote before and it is totally appropriate in this case as well. It already seems like agile has become the decade s new
                          Message 12 of 17 , Jul 9, 2002
                          View Source
                          • 0 Attachment

                            You’re right, Mike!

                            I’ve heard that quote before and it is totally appropriate in this case as well.

                            It already seems like “agile” has become the decade’s new buzzword.

                             

                            I guess the worthwhile innovations have weathered their buzzword periods—certainly OO surpassed buzzword status. Hopefully agile does the same.

                             

                            Even someone who dumps RUP for “lighter RUP” or some of the less-agile of the agile methods (e.g., FDD) is taking a step in the right direction. If people convert to those types of methodologies for a few years they may then be more willing to hear the true gospel of agile and go all the way—that would certainly fit with your comment that we may be facing a 20-30 year absorption.

                             

                            -----Original Message-----
                            From: Mike Beedle [mailto:beedlem@...]
                            Sent: Tuesday, July 09, 2002 4:01 AM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

                             


                            Ken wrote:
                            > Barry Boehm and a lot of other respected people like
                            > him are the worst thing that could happen to agile.
                            > They don't get it; they think agile is a task3, task4
                            > thing that is really "lightweight", but not something
                            > radically new. They are part of the problem, not
                            > part of the solution. And it seems that the more we
                            > work with them, the more we lose our focus and
                            > they redefine agile into "just a small change."

                            Ken:

                            I didn't have the courage to put it quite on these words,
                            but yes, I wholeheartedly agree.  If people hear believable
                            misconceptions, half truths, or just plain ole illed advice
                            from figure heads like:

                                  * XP can be an instance or RUP

                                  * Agile processes are _defined_ ETVX processes and
                                  are CMM compatible

                                  * Agile processes are just lightweight processes

                                  * We've done _all_ of this for the last 30 years

                                  etc.

                            Agile will be reduced to whatever else they want and it
                            to be, and the agile concept will be so muddled and garbled
                            that it will be hard to tell, specially for new comers,
                            what Software Agility really is or is not.

                            An old quote comes to mind, in 1982, Tim Rentsch said:

                            " ...object oriented programming will be in the 1980's
                            what structured programming was in the 1970's. Everyone
                            will be in favor of it. Every manufacturer will promote
                            his products as supporting it. Every manager will pay
                            lip service to it. Every programmer will practice it
                            (differently). And no one will know just what it is."

                            [Rentsch82]
                            Nguyen, Van and Hailpern, Brent "A Generalized Object Model",
                            ACM SIGPLAN NOTICES, v17, n9 Ed: G. Richard Wexelblat,
                            September 1982

                            So let me translate it to the agile software development:

                            " ...Agile Software Development will be in the 2000's
                            what Defined-Process Software Development was in the 1980's.
                            Everyone will be in favor of it. Every manufacturer will promote
                            his products as supporting it. Every manager will pay
                            lip service to it. Every programmer will practice it
                            (differently). And no one will know just what it is."

                            The scary part is that Rentsch's observations were valid
                            also in the 1990's, so if history repeats itself, we are
                            talking about an absorption rate of 20-30 years or so,

                            - Mike
                             

                          • Mike Cohn
                            Mike- The differences you describe here are perfect. Somewhat to Mary s point about needing to trust managers, though, sometimes this isn t the manager s or
                            Message 13 of 17 , Jul 9, 2002
                            View Source
                            • 0 Attachment

                              Mike—

                              The differences you describe here are perfect.

                               

                              Somewhat to Mary’s point about needing to trust managers, though, sometimes this isn’t the manager’s or ScrumMaster’s fault. I am working with a team right now that is slowly becoming accustomed to Scrum but I think they’re so used to having tasks assigned to them they are uncomfortable when I don’t tell them what task is next. I probably go a little further than you and Ken describe in your book in helping the team figure out what moves into the Sprint Backlog but I don’t tell them at all what order in which to work on things. It’s taken a few months with this team to convince them that I am not “checking up” on them in daily scrums and that the main purpose of the meeting is to make commitments to each other and for me to find out about impediments. They are coming around but they are nervous about the additional control and responsibility that ends up on their shoulders.

                               

                              This team also had a hard time of buying into the full “the product must be shippable”. One way I’ve got them around that (almost completely now) is to introduce the idea of a “stabilization sprint”. This was just a sprint with no new coding but just a catching up on testing application. Not a good idea in some situations but in this one it made sense (this was a team of 4 people who were left after 80 of their coworkers were fired and they are continuing on with work started by the 84 person team—that’s the type of project that needs extra “stabilization”).

                               

                              --Mike

                               

                              -----Original Message-----
                              From: Mike Beedle [mailto:beedlem@...]
                              Sent:
                              Tuesday, July 09, 2002 2:50 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

                               


                               
                              What we mean in Scrum is:

                                    Let me hear how things went and see how we, the
                                    team, can help you

                                    Let me hear any issues you have that go beyond
                                    your control so I can help you

                                    and

                                    Let me hear what new tasks _you are choosing_ to
                                    work on next and see how we, the team, can help you
                                   
                              instead of:

                                    I assign tasks to you every day

                                    you must tell me the issues you may have and
                                    solve them

                                    and

                                    you report to me every day

                                    (Definitely NOT the spirit of Scrum)

                              Attitude for the most part is what makes Scrum different than
                              micromanagement and Master/Slave direct management and
                              reporting,

                               

                            • Linda Rising
                              Now that I m back from Ireland, I can add a little bodhran accompaniment ... http://www.ifccsa.org/bodhran.html
                              Message 14 of 17 , Jul 15, 2002
                              View Source
                              • 0 Attachment
                                Now that I'm back from Ireland, I can add a little bodhran accompaniment
                                :-)!

                                http://www.ifccsa.org/bodhran.html



                                Ken Schwaber wrote:

                                >MIke,
                                >Linda Rising is the bard and songstress of agile. I hope she takes these
                                >from village to village so people understand better.
                                >Ken
                                >
                                >-----Original Message-----
                                >From: Mike Beedle [mailto:beedlem@...]
                                >Sent: Tuesday, July 09, 2002 4:50 AM
                                >To: scrumdevelopment@yahoogroups.com
                                >Subject: RE: [scrumdevelopment] RE: Agile Software Development
                                >Revolution
                                >
                                >
                                >
                                >Mike:
                                >
                                >Well said:
                                >
                                > the intellectual baggage of _defined_ processes
                                > carried over from previous lives, projects, related
                                > experience, and education causes for most
                                > metaphor-block and dysfunctional translation.
                                > (What a challenge we have ahead of us!!!)
                                >
                                >That's why it is so important to have good mentors,
                                >experienced Scrum masters, and experienced developers,
                                >that understand, at least in a tacit way that there
                                >is a _fundamental_ difference of Agile vs. Traditional
                                >(defined) software development.
                                >
                                >Also, just like Ken said, I'll have to add these ones
                                >to the next Gantt chart I see:
                                >
                                > Task 3: Have teams self-organize, 3 days
                                > Task 4: Allow requirements to emerge, 5 days
                                >
                                >:-) :-) ;-)
                                >
                                >And I'll eve add a few more:
                                >
                                > Task 5: Turn the Management pyramid upside down
                                > Task 6: Adopt Agile Values
                                >
                                >More relevant to Scrum, and to continue the parody above,
                                >I often see trained Team Leaders and Managers
                                >walking into the Scrum meeting assigning tasks and
                                >expecting direct reports like (to continue the parody):
                                >
                                > "Your _assigned_ task yesterday was to adopt the
                                > Agile Values, were you able to do that?
                                >
                                > No?!!
                                >
                                > _You are having issues again_. _Report_
                                > to me your any progress you are able to make
                                > by tomorrow."
                                >
                                >They think that management _asigns_ tasks, that it
                                >is developers who have issues to resolve, and that
                                >developers should _report_ back to them in the morning.
                                >
                                >What we mean in Scrum is:
                                >
                                > Let me hear how things went and see how we, the
                                > team, can help you
                                >
                                > Let me hear any issues you have that go beyond
                                > your control so I can help you
                                >
                                > and
                                >
                                > Let me hear what new tasks _you are choosing_ to
                                > work on next and see how we, the team, can help you
                                >
                                >instead of:
                                >
                                > I assign tasks to you every day
                                >
                                > you must tell me the issues you may have and
                                > solve them
                                >
                                > and
                                >
                                > you report to me every day
                                >
                                > (Definitely NOT the spirit of Scrum)
                                >
                                >Attitude for the most part is what makes Scrum different than
                                >micromanagement and Master/Slave direct management and
                                >reporting,
                                >
                                >- Mike
                                >
                                >
                                >To Post a message, send it to: scrumdevelopment@...
                                >To Unsubscribe, send a blank message to:
                                >scrumdevelopment-unsubscribe@...
                                >
                                >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                >
                                >
                                >
                                >
                                >To Post a message, send it to: scrumdevelopment@...
                                >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                >
                                >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                >
                                >
                                >
                              • Peter McGowan
                                Did you bring one back with you? If we ever meet up, we can play a reel or a jig and drink a pint together! Keep the wrist lose, Peter ... From: Linda
                                Message 15 of 17 , Jul 15, 2002
                                View Source
                                • 0 Attachment
                                  Did you bring one back with you? If we ever meet up, we can play a reel or
                                  a jig and drink a pint together!

                                  Keep the wrist lose,
                                  Peter


                                  ----- Original Message -----
                                  From: "Linda Rising" <risingl@...>
                                  To: <scrumdevelopment@yahoogroups.com>
                                  Sent: Monday, July 15, 2002 4:48 PM
                                  Subject: Re: [scrumdevelopment] RE: Agile Software Development Revolution


                                  > Now that I'm back from Ireland, I can add a little bodhran accompaniment
                                  > :-)!
                                  >
                                  > http://www.ifccsa.org/bodhran.html
                                  >
                                  >
                                  >
                                  > Ken Schwaber wrote:
                                  >
                                  > >MIke,
                                  > >Linda Rising is the bard and songstress of agile. I hope she takes these
                                  > >from village to village so people understand better.
                                  > >Ken
                                  > >
                                  > >-----Original Message-----
                                  > >From: Mike Beedle [mailto:beedlem@...]
                                  > >Sent: Tuesday, July 09, 2002 4:50 AM
                                  > >To: scrumdevelopment@yahoogroups.com
                                  > >Subject: RE: [scrumdevelopment] RE: Agile Software Development
                                  > >Revolution
                                  > >
                                  > >
                                  > >
                                  > >Mike:
                                  > >
                                  > >Well said:
                                  > >
                                  > > the intellectual baggage of _defined_ processes
                                  > > carried over from previous lives, projects, related
                                  > > experience, and education causes for most
                                  > > metaphor-block and dysfunctional translation.
                                  > > (What a challenge we have ahead of us!!!)
                                  > >
                                  > >That's why it is so important to have good mentors,
                                  > >experienced Scrum masters, and experienced developers,
                                  > >that understand, at least in a tacit way that there
                                  > >is a _fundamental_ difference of Agile vs. Traditional
                                  > >(defined) software development.
                                  > >
                                  > >Also, just like Ken said, I'll have to add these ones
                                  > >to the next Gantt chart I see:
                                  > >
                                  > > Task 3: Have teams self-organize, 3 days
                                  > > Task 4: Allow requirements to emerge, 5 days
                                  > >
                                  > >:-) :-) ;-)
                                  > >
                                  > >And I'll eve add a few more:
                                  > >
                                  > > Task 5: Turn the Management pyramid upside down
                                  > > Task 6: Adopt Agile Values
                                  > >
                                  > >More relevant to Scrum, and to continue the parody above,
                                  > >I often see trained Team Leaders and Managers
                                  > >walking into the Scrum meeting assigning tasks and
                                  > >expecting direct reports like (to continue the parody):
                                  > >
                                  > > "Your _assigned_ task yesterday was to adopt the
                                  > > Agile Values, were you able to do that?
                                  > >
                                  > > No?!!
                                  > >
                                  > > _You are having issues again_. _Report_
                                  > > to me your any progress you are able to make
                                  > > by tomorrow."
                                  > >
                                  > >They think that management _asigns_ tasks, that it
                                  > >is developers who have issues to resolve, and that
                                  > >developers should _report_ back to them in the morning.
                                  > >
                                  > >What we mean in Scrum is:
                                  > >
                                  > > Let me hear how things went and see how we, the
                                  > > team, can help you
                                  > >
                                  > > Let me hear any issues you have that go beyond
                                  > > your control so I can help you
                                  > >
                                  > > and
                                  > >
                                  > > Let me hear what new tasks _you are choosing_ to
                                  > > work on next and see how we, the team, can help you
                                  > >
                                  > >instead of:
                                  > >
                                  > > I assign tasks to you every day
                                  > >
                                  > > you must tell me the issues you may have and
                                  > > solve them
                                  > >
                                  > > and
                                  > >
                                  > > you report to me every day
                                  > >
                                  > > (Definitely NOT the spirit of Scrum)
                                  > >
                                  > >Attitude for the most part is what makes Scrum different than
                                  > >micromanagement and Master/Slave direct management and
                                  > >reporting,
                                  > >
                                  > >- Mike
                                  > >
                                  > >
                                  > >To Post a message, send it to: scrumdevelopment@...
                                  > >To Unsubscribe, send a blank message to:
                                  > >scrumdevelopment-unsubscribe@...
                                  > >
                                  > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >To Post a message, send it to: scrumdevelopment@...
                                  > >To Unsubscribe, send a blank message to:
                                  scrumdevelopment-unsubscribe@...
                                  > >
                                  > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                  > >
                                  > >
                                  > >
                                  >
                                  >
                                  >
                                  >
                                  > To Post a message, send it to: scrumdevelopment@...
                                  > To Unsubscribe, send a blank message to:
                                  scrumdevelopment-unsubscribe@...
                                  >
                                  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                  >
                                  >
                                • Linda Rising
                                  I had one before I went -- and a tin whistle -- but I got to see lots of players at the Willy Clancy festival -- now I have to find some local set dancers :-)!
                                  Message 16 of 17 , Jul 15, 2002
                                  View Source
                                  • 0 Attachment
                                    I had one before I went -- and a tin whistle -- but I got to see lots of players at the Willy
                                    Clancy festival -- now I have to find some local set dancers :-)!




                                    Peter McGowan wrote:
                                    Did you bring one back with you?  If we ever meet up, we can play a reel or
                                    a jig and drink a pint together!

                                    Keep the wrist lose,
                                    Peter


                                    ----- Original Message -----
                                    From: "Linda Rising" <risingl@...>
                                    To: <scrumdevelopment@yahoogroups.com>
                                    Sent: Monday, July 15, 2002 4:48 PM
                                    Subject: Re: [scrumdevelopment] RE: Agile Software Development Revolution


                                    Now that I'm back from Ireland, I can add a little bodhran accompaniment
                                    :-)!

                                    http://www.ifccsa.org/bodhran.html



                                    Ken Schwaber wrote:

                                    MIke,
                                    Linda Rising is the bard and songstress of agile. I hope she takes these
                                    >from village to village so people understand better.
                                    Ken

                                    -----Original Message-----
                                    From: Mike Beedle [mailto:beedlem@...]
                                    Sent: Tuesday, July 09, 2002 4:50 AM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: RE: [scrumdevelopment] RE: Agile Software Development
                                    Revolution



                                    Mike:

                                    Well said:

                                    the intellectual baggage of _defined_ processes
                                    carried over from previous lives, projects, related
                                    experience, and education causes for most
                                    metaphor-block and dysfunctional translation.
                                    (What a challenge we have ahead of us!!!)

                                    That's why it is so important to have good mentors,
                                    experienced Scrum masters, and experienced developers,
                                    that understand, at least in a tacit way that there
                                    is a _fundamental_ difference of Agile vs. Traditional
                                    (defined) software development.

                                    Also, just like Ken said, I'll have to add these ones
                                    to the next Gantt chart I see:

                                    Task 3: Have teams self-organize, 3 days
                                    Task 4: Allow requirements to emerge, 5 days

                                    :-) :-) ;-)

                                    And I'll eve add a few more:

                                    Task 5: Turn the Management pyramid upside down
                                    Task 6: Adopt Agile Values

                                    More relevant to Scrum, and to continue the parody above,
                                    I often see trained Team Leaders and Managers
                                    walking into the Scrum meeting assigning tasks and
                                    expecting direct reports like (to continue the parody):

                                    "Your _assigned_ task yesterday was to adopt the
                                    Agile Values, were you able to do that?

                                    No?!!

                                    _You are having issues again_. _Report_
                                    to me your any progress you are able to make
                                    by tomorrow."

                                    They think that management _asigns_ tasks, that it
                                    is developers who have issues to resolve, and that
                                    developers should _report_ back to them in the morning.

                                    What we mean in Scrum is:

                                    Let me hear how things went and see how we, the
                                    team, can help you

                                    Let me hear any issues you have that go beyond
                                    your control so I can help you

                                    and

                                    Let me hear what new tasks _you are choosing_ to
                                    work on next and see how we, the team, can help you

                                    instead of:

                                    I assign tasks to you every day

                                    you must tell me the issues you may have and
                                    solve them

                                    and

                                    you report to me every day

                                    (Definitely NOT the spirit of Scrum)

                                    Attitude for the most part is what makes Scrum different than
                                    micromanagement and Master/Slave direct management and
                                    reporting,

                                    - Mike


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

                                    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




                                    To Post a message, send it to: scrumdevelopment@...
                                    To Unsubscribe, send a blank message to:
                                    scrumdevelopment-unsubscribe@...
                                    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/






                                    To Post a message, send it to: scrumdevelopment@...
                                    To Unsubscribe, send a blank message to:
                                    scrumdevelopment-unsubscribe@...
                                    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




                                    ------------------------ Yahoo! Groups Sponsor ---------------------~-->
                                    Save on REALTOR Fees
                                    http://us.click.yahoo.com/Xw80LD/h1ZEAA/Ey.GAA/9EfwlB/TM
                                    ---------------------------------------------------------------------~->

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

                                    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




                                  • Ken Schwaber
                                    Neat!! ... From: Linda Rising [mailto:risingl@acm.org] Sent: Monday, July 15, 2002 4:48 PM To: scrumdevelopment@yahoogroups.com Subject: Re: [scrumdevelopment]
                                    Message 17 of 17 , Jul 17, 2002
                                    View Source
                                    • 0 Attachment
                                      Neat!!

                                      -----Original Message-----
                                      From: Linda Rising [mailto:risingl@...]
                                      Sent: Monday, July 15, 2002 4:48 PM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: Re: [scrumdevelopment] RE: Agile Software Development
                                      Revolution


                                      Now that I'm back from Ireland, I can add a little bodhran accompaniment
                                      :-)!

                                      http://www.ifccsa.org/bodhran.html



                                      Ken Schwaber wrote:

                                      >MIke,
                                      >Linda Rising is the bard and songstress of agile. I hope she takes these
                                      >from village to village so people understand better.
                                      >Ken
                                      >
                                      >-----Original Message-----
                                      >From: Mike Beedle [mailto:beedlem@...]
                                      >Sent: Tuesday, July 09, 2002 4:50 AM
                                      >To: scrumdevelopment@yahoogroups.com
                                      >Subject: RE: [scrumdevelopment] RE: Agile Software Development
                                      >Revolution
                                      >
                                      >
                                      >
                                      >Mike:
                                      >
                                      >Well said:
                                      >
                                      > the intellectual baggage of _defined_ processes
                                      > carried over from previous lives, projects, related
                                      > experience, and education causes for most
                                      > metaphor-block and dysfunctional translation.
                                      > (What a challenge we have ahead of us!!!)
                                      >
                                      >That's why it is so important to have good mentors,
                                      >experienced Scrum masters, and experienced developers,
                                      >that understand, at least in a tacit way that there
                                      >is a _fundamental_ difference of Agile vs. Traditional
                                      >(defined) software development.
                                      >
                                      >Also, just like Ken said, I'll have to add these ones
                                      >to the next Gantt chart I see:
                                      >
                                      > Task 3: Have teams self-organize, 3 days
                                      > Task 4: Allow requirements to emerge, 5 days
                                      >
                                      >:-) :-) ;-)
                                      >
                                      >And I'll eve add a few more:
                                      >
                                      > Task 5: Turn the Management pyramid upside down
                                      > Task 6: Adopt Agile Values
                                      >
                                      >More relevant to Scrum, and to continue the parody above,
                                      >I often see trained Team Leaders and Managers
                                      >walking into the Scrum meeting assigning tasks and
                                      >expecting direct reports like (to continue the parody):
                                      >
                                      > "Your _assigned_ task yesterday was to adopt the
                                      > Agile Values, were you able to do that?
                                      >
                                      > No?!!
                                      >
                                      > _You are having issues again_. _Report_
                                      > to me your any progress you are able to make
                                      > by tomorrow."
                                      >
                                      >They think that management _asigns_ tasks, that it
                                      >is developers who have issues to resolve, and that
                                      >developers should _report_ back to them in the morning.
                                      >
                                      >What we mean in Scrum is:
                                      >
                                      > Let me hear how things went and see how we, the
                                      > team, can help you
                                      >
                                      > Let me hear any issues you have that go beyond
                                      > your control so I can help you
                                      >
                                      > and
                                      >
                                      > Let me hear what new tasks _you are choosing_ to
                                      > work on next and see how we, the team, can help you
                                      >
                                      >instead of:
                                      >
                                      > I assign tasks to you every day
                                      >
                                      > you must tell me the issues you may have and
                                      > solve them
                                      >
                                      > and
                                      >
                                      > you report to me every day
                                      >
                                      > (Definitely NOT the spirit of Scrum)
                                      >
                                      >Attitude for the most part is what makes Scrum different than
                                      >micromanagement and Master/Slave direct management and
                                      >reporting,
                                      >
                                      >- Mike
                                      >
                                      >
                                      >To Post a message, send it to: scrumdevelopment@...
                                      >To Unsubscribe, send a blank message to:
                                      >scrumdevelopment-unsubscribe@...
                                      >
                                      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                      >
                                      >
                                      >
                                      >
                                      >To Post a message, send it to: scrumdevelopment@...
                                      >To Unsubscribe, send a blank message to:
                                      scrumdevelopment-unsubscribe@...
                                      >
                                      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                      >
                                      >
                                      >




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

                                      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.