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

The Essence of Agile and Scrum

Expand Messages
  • Ken Schwaber
    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,
    Message 1 of 8 , Dec 5, 2002
    • 0 Attachment
      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
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.