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

Re: [scrumdevelopment] The Essence of Agile and Scrum

Expand Messages
  • David J. Anderson
    My thoughts on this are that timeboxing is the essence of RAD. Agile is much more than RAD! RAD says - prioritize your requirements, estimate what can be
    Message 1 of 8 , Dec 6, 2002
    • 0 Attachment
      My thoughts on this are that "timeboxing" is the
      essence of RAD.

      Agile is much more than RAD!

      RAD says - prioritize your requirements, estimate what
      can be done in a fixed time, draw a line on the list
      and build everything above the line - the most
      important requirements.

      The timebox guarantees a fixed operational expense and
      a delivery date around which others can plan. It helps
      to control financial risk.

      Agile is about much more than RAD. Agile is about
      survivability in a Darwinian-sense - it is about the
      ability to cope with change.

      There are a number of derivatives to this which
      include the human side of engineering which RAD tends
      to ignore.

      For me - the Agile Manifesto and its supporting
      principles define the essence of Agile. I don't see
      the need to try and boil it down to just one thing.

      To get back to Craig's comment, I don't think it is
      the timebox but rather small batch sizes which are
      agile. If Agile and Lean (Production/Thinking) are
      similar in nature (and Bob Charette, Mary Poppendieck
      and others have shown this) then Lean Production
      relies on small batch sizes much more than heart beat
      style timeboxes.

      David
      --
      David Anderson
      http://www.uidesign.net/
      The Webzine for Interaction Designers


      --- Ken Schwaber <ken.schwaber@...> wrote:

      <HR>
      <html><body>
      <tt>
      I was at a BOF at SD East and Craig brought up that he
      thought that<BR>
      time-boxing, as in the Sprint, was the essence of
      agility. I demurred a<BR>
      reply at the time, but I've decided in retrospect that
      time-boxing is<BR>
      critical. </body></html>



      __________________________________________________
      Do you Yahoo!?
      Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
      http://mailplus.yahoo.com
    • Linda Rising
      John Muir, the founder of the Sierra Club said something like -- when you try to pick up any one thing, you find it s connected to everything else in the
      Message 2 of 8 , Dec 9, 2002
      • 0 Attachment
        John Muir, the founder of the Sierra Club said something like -- when you try to pick up any
        one thing, you find it's connected to everything else in the universe :-)!

        I've seen projects that were struggling unsuccessfully with short timeboxed iterations -- what
        saved them was Scrum meetings. I'm a real fan of those meetings. You gotta have good
        communication or those short timeboxed iterations deliver too many surprises :-)!

        It's all connected, guys :-)!




        Craig Larman wrote:
        I think I said something like "an iterative lifecycle of short timeboxed
        iterations is the most important ingredient in successful process."


        Consider an alternative: a 3 year waterfall project in which year 1 is
        requirements analysis, year 2 is design, and year 3 is implementation.


        I claim that on such a project, you could throw all the pair
        programming, self-directed creative team, scrum meetings, test first
        development, etc at it you want, and it would still be very risky, and
        perhaps fail due to the myriad problems that arise from a sequential
        lifecycle of very long req -> des -> impl.


        I've seen lots of techniques and values in the 25 years I've been in the
        business, and nothing has more influence and implications than moving
        from "year 1 req, year 2 des, year 3 impl" to "from the start, when only
        partial reqs are known, incrementally build software in 4 week (or
        whatever) iterations." from that lifecycle practice arises explicitly or
        implicitly so much else in terms of PM, req analysis, adaptation, risk
        mgmt, prioritization, build tools and test practices,
        architecture/design, ...


        I think that in the modern promotion of "agile" methods, the old,
        venerable and key critical practice of short iterations rather than the
        waterfall, which dates back to the 70s in some enlightened camps, is the
        real magic sauce without which the other practices and values lose much
        power.


        As an aside, Dr. Vic Basili and I are writing "the history of iterative
        development" article for IEEE Computer. It is a fascinating history
        imho.

        Do any of you have contributions to the chronology and references? Input
        much appreciated at: http://c2.com/cgi/wiki?HistoryOfIterative

        regards, craig


        -----Original Message-----
        From: Ken Schwaber [mailto:ken.schwaber@...]
        Sent: Thursday, December 05, 2002 11:28 PM
        To: scrumdevelopment@yahoogroups.com
        Cc: Craig Larman
        Subject: The Essence of Agile and Scrum

        I was at a BOF at SD East and Craig brought up that he thought that
        time-boxing, as in the Sprint, was the essence of agility. I demurred
        a
        reply at the time, but I've decided in retrospect that time-boxing is
        critical. However, the following aspects are equally critical, and all
        of
        them play with each other to create the beauty of agility:
        1. That the work being done in the time-box is of the greatest urgency
        and
        importance to the user, the customer, otherwise why is the time-box
        relevant?
        2. That the people in the time-box are able to be as creative as
        possible
        to
        reach the best solution they can come up with. That is, that the
        principles
        of self-organization and then emergence will be given full play within
        the
        time-box. If someone external is directing the team, then it's not
        agile.
        3. That the team has good engineering practices so that what they
        create
        is
        the real thing, not just some pale shadow of the real thing ... such
        as a
        buggy, poorly designed set of functionality that really never has a
        chance
        of being "an increment of potentially shippable code."

        My thoughts,
        Ken



        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/




      • Craig Larman
        I think I said something like an iterative lifecycle of short timeboxed iterations is the most important ingredient in successful process. Consider an
        Message 3 of 8 , Dec 9, 2002
        • 0 Attachment
          I think I said something like "an iterative lifecycle of short timeboxed
          iterations is the most important ingredient in successful process."


          Consider an alternative: a 3 year waterfall project in which year 1 is
          requirements analysis, year 2 is design, and year 3 is implementation.


          I claim that on such a project, you could throw all the pair
          programming, self-directed creative team, scrum meetings, test first
          development, etc at it you want, and it would still be very risky, and
          perhaps fail due to the myriad problems that arise from a sequential
          lifecycle of very long req -> des -> impl.


          I've seen lots of techniques and values in the 25 years I've been in the
          business, and nothing has more influence and implications than moving
          from "year 1 req, year 2 des, year 3 impl" to "from the start, when only
          partial reqs are known, incrementally build software in 4 week (or
          whatever) iterations." from that lifecycle practice arises explicitly or
          implicitly so much else in terms of PM, req analysis, adaptation, risk
          mgmt, prioritization, build tools and test practices,
          architecture/design, ...


          I think that in the modern promotion of "agile" methods, the old,
          venerable and key critical practice of short iterations rather than the
          waterfall, which dates back to the 70s in some enlightened camps, is the
          real magic sauce without which the other practices and values lose much
          power.


          As an aside, Dr. Vic Basili and I are writing "the history of iterative
          development" article for IEEE Computer. It is a fascinating history
          imho.

          Do any of you have contributions to the chronology and references? Input
          much appreciated at: http://c2.com/cgi/wiki?HistoryOfIterative

          regards, craig


          > -----Original Message-----
          > From: Ken Schwaber [mailto:ken.schwaber@...]
          > Sent: Thursday, December 05, 2002 11:28 PM
          > To: scrumdevelopment@yahoogroups.com
          > Cc: Craig Larman
          > Subject: The Essence of Agile and Scrum
          >
          > I was at a BOF at SD East and Craig brought up that he thought that
          > time-boxing, as in the Sprint, was the essence of agility. I demurred
          a
          > reply at the time, but I've decided in retrospect that time-boxing is
          > critical. However, the following aspects are equally critical, and all
          of
          > them play with each other to create the beauty of agility:
          > 1. That the work being done in the time-box is of the greatest urgency
          and
          > importance to the user, the customer, otherwise why is the time-box
          > relevant?
          > 2. That the people in the time-box are able to be as creative as
          possible
          > to
          > reach the best solution they can come up with. That is, that the
          > principles
          > of self-organization and then emergence will be given full play within
          the
          > time-box. If someone external is directing the team, then it's not
          agile.
          > 3. That the team has good engineering practices so that what they
          create
          > is
          > the real thing, not just some pale shadow of the real thing ... such
          as a
          > buggy, poorly designed set of functionality that really never has a
          chance
          > of being "an increment of potentially shippable code."
          >
          > My thoughts,
          > Ken
        • Alan Shalloway <alshall@netobjectives.co
          Linda: It is all connected. However, I believe Craig s observation is still correct -- as is yours. In fact, together, they give the insight that we use to
          Message 4 of 8 , Dec 10, 2002
          • 0 Attachment
            Linda:
            It is "all connected." However, I believe Craig's observation is
            still correct -- as is yours. In fact, together, they give the
            insight that we use to institute agile in a company that is not
            currently doing agile. We say: let's get short, time-boxed cycles
            in. OK, now that we know we have to do this, what things must we do
            to facilitate this (this is usually a scope problem). What things
            can we do to facilitate this (there is always low-hanging fruit).
            If we can't do monthly cycles (our preference) can we at least break
            the project up somewhat?

            This enables us to unfold the problem, so to speak. Do a little,
            see how it works and do some more.

            Alan Shalloway
            Net Objectives


            --- In scrumdevelopment@yahoogroups.com, Linda Rising <risingl@a...>
            wrote:
            > John Muir, the founder of the Sierra Club said something like --
            when
            > you try to pick up any
            > one thing, you find it's connected to everything else in the
            universe :-)!
            >
            > I've seen projects that were struggling unsuccessfully with short
            > timeboxed iterations -- what
            > saved them was Scrum meetings. I'm a real fan of those meetings.
            You
            > gotta have good
            > communication or those short timeboxed iterations deliver too many
            > surprises :-)!
            >
            > It's all connected, guys :-)!
            >
            >
            >
            >
            > Craig Larman wrote:
            >
            > >I think I said something like "an iterative lifecycle of short
            timeboxed
            > >iterations is the most important ingredient in successful
            process."
            > >
            > >
            > >Consider an alternative: a 3 year waterfall project in which year
            1 is
            > >requirements analysis, year 2 is design, and year 3 is
            implementation.
            > >
            > >
            > >I claim that on such a project, you could throw all the pair
            > >programming, self-directed creative team, scrum meetings, test
            first
            > >development, etc at it you want, and it would still be very
            risky, and
            > >perhaps fail due to the myriad problems that arise from a
            sequential
            > >lifecycle of very long req -> des -> impl.
            > >
            > >
            > >I've seen lots of techniques and values in the 25 years I've been
            in the
            > >business, and nothing has more influence and implications than
            moving
            > >from "year 1 req, year 2 des, year 3 impl" to "from the start,
            when only
            > >partial reqs are known, incrementally build software in 4 week (or
            > >whatever) iterations." from that lifecycle practice arises
            explicitly or
            > >implicitly so much else in terms of PM, req analysis, adaptation,
            risk
            > >mgmt, prioritization, build tools and test practices,
            > >architecture/design, ...
            > >
            > >
            > >I think that in the modern promotion of "agile" methods, the old,
            > >venerable and key critical practice of short iterations rather
            than the
            > >waterfall, which dates back to the 70s in some enlightened camps,
            is the
            > >real magic sauce without which the other practices and values
            lose much
            > >power.
            > >
            > >
            > >As an aside, Dr. Vic Basili and I are writing "the history of
            iterative
            > >development" article for IEEE Computer. It is a fascinating
            history
            > >imho.
            > >
            > >Do any of you have contributions to the chronology and
            references? Input
            > >much appreciated at: http://c2.com/cgi/wiki?HistoryOfIterative
            > >
            > >regards, craig
            > >
            > >
            > >>-----Original Message-----
            > >>From: Ken Schwaber [mailto:ken.schwaber@v...]
            > >>Sent: Thursday, December 05, 2002 11:28 PM
            > >>To: scrumdevelopment@yahoogroups.com
            > >>Cc: Craig Larman
            > >>Subject: The Essence of Agile and Scrum
            > >>
            > >>I was at a BOF at SD East and Craig brought up that he thought
            that
            > >>time-boxing, as in the Sprint, was the essence of agility. I
            demurred
            > >>
            > >a
            > >
            > >>reply at the time, but I've decided in retrospect that time-
            boxing is
            > >>critical. However, the following aspects are equally critical,
            and all
            > >>
            > >of
            > >
            > >>them play with each other to create the beauty of agility:
            > >>1. That the work being done in the time-box is of the greatest
            urgency
            > >>
            > >and
            > >
            > >>importance to the user, the customer, otherwise why is the time-
            box
            > >>relevant?
            > >>2. That the people in the time-box are able to be as creative as
            > >>
            > >possible
            > >
            > >>to
            > >>reach the best solution they can come up with. That is, that the
            > >>principles
            > >>of self-organization and then emergence will be given full play
            within
            > >>
            > >the
            > >
            > >>time-box. If someone external is directing the team, then it's
            not
            > >>
            > >agile.
            > >
            > >>3. That the team has good engineering practices so that what they
            > >>
            > >create
            > >
            > >>is
            > >>the real thing, not just some pale shadow of the real thing ...
            such
            > >>
            > >as a
            > >
            > >>buggy, poorly designed set of functionality that really never
            has a
            > >>
            > >chance
            > >
            > >>of being "an increment of potentially shippable code."
            > >>
            > >>My thoughts,
            > >>Ken
            > >>
            > >
            > >
            > >
            > >To Post a message, send it to: scrumdevelopment@e...
            > >To Unsubscribe, send a blank message to: scrumdevelopment-
            unsubscribe@e...
            > >
            > >Your use of Yahoo! Groups is subject to
            http://docs.yahoo.com/info/terms/
            > >
            > >
            > >
          • David J. Anderson
            Which might be why Jim HIghsmith called them ecosystems or Gerry Weinberg applied general systems theory - they are connected systems, there is no isolated
            Message 5 of 8 , Dec 10, 2002
            • 0 Attachment
              Which might be why Jim HIghsmith called them
              "ecosystems" or Gerry Weinberg applied general systems
              theory - they are connected systems, there is no
              isolated cause-effect relationships.

              David
              --
              David Anderson
              http://www.uidesign.net/
              The Webzine for Interaction Designers

              --- Linda Rising <risingl@...> wrote:
              > John Muir, the founder of the Sierra Club said
              > something like -- when
              > you try to pick up any
              > one thing, you find it's connected to everything
              > else in the universe :-)!
              >
              > I've seen projects that were struggling
              > unsuccessfully with short
              > timeboxed iterations -- what
              > saved them was Scrum meetings. I'm a real fan of
              > those meetings. You
              > gotta have good
              > communication or those short timeboxed iterations
              > deliver too many
              > surprises :-)!
              >
              > It's all connected, guys :-)!
              >


              __________________________________________________
              Do you Yahoo!?
              Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
              http://mailplus.yahoo.com
            Your message has been successfully submitted and would be delivered to recipients shortly.