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

Re: [scrumdevelopment] The Essence of Agile and Scrum

Expand Messages
  • Ulrich Winter
    Ken, Craig, I d like to add another aspect: An agile project avoids planning details a long time in advance. Keeping the planning focus to the next sprint /
    Message 1 of 8 , Dec 6, 2002
    • 0 Attachment
      Ken, Craig,

      I'd like to add another aspect:

      An agile project avoids planning details a long time in advance.
      Keeping the planning focus to the next sprint / time box
      allows for quick reaction after every sprint and avoids
      wasted planning/estimating efforts.

      Bye,
      Uli
    • Ron Jeffries
      ... Outstanding thoughts, Ken. Some of your best work. On the same subject, time-boxing, I m reminded of my funning way of describing Alistair s Crystal Clear:
      Message 2 of 8 , Dec 6, 2002
      • 0 Attachment
        On Friday, December 6, 2002, at 12:27:57 AM, Ken Schwaber wrote:

        > 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."

        Outstanding thoughts, Ken. Some of your best work.

        On the same subject, time-boxing, I'm reminded of my funning way of
        describing Alistair's Crystal Clear:

        Come together in peace, love, and understanding, ship software every
        month, and think about it.

        Again, the timebox is critical. If I were to say why, in XP terms, I
        would emphasize primarily the feedback value.

        Good stuff!

        Ron Jeffries
        www.XProgramming.com
        Only the hand that erases can write the true thing. -- Meister Eckhart
      • 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 3 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 4 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 5 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 6 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 7 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.