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

RE: [scrumdevelopment] A tale of two Scrums

Expand Messages
  • Roy Morien
    I think that you have made some very compelling points. It has long been a practice to deliver the smaller, easier things at the start. This does have some
    Message 1 of 25 , Mar 1, 2009
      I think that you have made some very compelling points. It has long been a practice to deliver the smaller, easier things at the start. This does have some advantages which are real and should not be deprecated. It can have a substantially positive psychological effect on many project participants, and create a not unrealistic atmosphere of confidence, good progress, well-being. Not to be underestimated as beneficial!.
       
      It can also have quite negative effects. By doing the easy things first, we are not testing the complexities and difficulties of the project to see if there are any substantial, or even mortal blockages ahead. That feeling of confidence and progress can be ephemeral, and mask reality.
       
      I like to have a combination of things. Get some people started on actually delivering something (as a confidence builder) but at the same time identify the difficult things and work to overcome them, before too much has been done. I think in this day and age there is very little that is impossible and can't be overcome, but that doesn't mean they needn't be addressed as soon as possible.
       
      But, however you do it, forget about predictability and it's bedfellow productivity. Notions of productivity is always at risk because of unpredictability. We can only do our best to mitigate future risks, we cannot eradicate them.
       
      Regards,
      Roy Morien   
       

      To: scrumdevelopment@yahoogroups.com
      From: jens.meydam@...
      Date: Sun, 1 Mar 2009 23:03:23 +0000
      Subject: [scrumdevelopment] A tale of two Scrums

      Many of those who post questions on this list seem to aim for a very
      high degree of predictability.

      There is a lot of good advice, starting with the popular practice to
      fill the (top of the) backlog with small, relatively well understood
      user stories. Such small stories can already be estimated quite well
      even without decomposing them into tasks.

      To make progress even more predictable, it is often recommended to
      double-check the estimates of the selected backlog (usually in story
      points) by decomposing all stories up front into tasks (during the
      second half of the sprint planning meeting), estimating the tasks
      (usually in hours) and then adding up the task estimates to see if the
      result really seems doable.

      A sprint is then considered successful if the selected stories all get
      done as promised, perhaps plus or minus one story.

      This is Scrum, right?

      Well, today I picked up "Agile Software Development with Scrum" by Ken
      Schwaber and Mike Beedle and re-read some passages, and I noticed how
      very different their notion of Scrum is compared to Scrum as it is
      often described and practiced today. The leitmotiv of that book is
      the complexity and unpredictability of the work, and how much courage
      and determination it takes just to get started, let alone to promise
      anything concrete.

      Rather than committing to the delivery of a number of well-understood,
      fine-grained user stories, the team tries to achieve a single
      important goal, the scope of which is deliberately left vague. The
      team is not expected to be able to say precisely how much it will
      deliver. In fact, the work might be so difficult that it might be
      perfectly acceptable for the team not to achieve the sprint goal at
      all, as long as important knowledge has been gained.

      A few months ago, Ken Schwaber said in one of his comments on this
      list that Scrum was really created for situations where "more is
      unknown than known" (quoted from memory). I suppose this points to
      the view of Scrum that is documented in "Agile Software Development
      with Scrum".

      So there seem two quite distinct types or styles of Scrum, with
      different practices, meant for different situations:

      Scrum I:

      - emphasizing knowledge generation
      - development can be described as achieving break-throughs in the face
      of substantial uncertainty and risk
      - if you make precise commitments you are fooling yourself

      Scrum II:

      - emphasizing (at least short-term) predictability and speed of
      development
      - development can be described as growing a system feature by feature

      I wonder what you think about this.

      Jens




      Explore the new Windows Live. Looking for a place to manage all your online stuff?
    • jens.meydam
      Hi Roy ... bedfellow productivity. Notions of productivity is always at risk because of unpredictability. We can only do our best to mitigate future risks, we
      Message 2 of 25 , Mar 2, 2009
        Hi Roy

        --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:

        > But, however you do it, forget about predictability and it's
        bedfellow productivity. Notions of productivity is always at risk
        because of unpredictability. We can only do our best to mitigate
        future risks, we cannot eradicate them.
        >

        In my opinion, Scrum as described in the first book by Ken Schwaber is
        incompatible with the concept of velocity. Moreover, some of the
        prescribed practices of Scrum make perfect sense only in the context
        of this style of Scrum.

        Below I have added some quotes I found interesting in this context.

        On the other hand, XP-style Scrum (requirements in form of small user
        stories, velocity), which seems to be the dominant practice today, is
        obviously well suited for software development in a corporate setting.

        Technology is often not _that_ unpredictable any more (after having
        developed a couple of applications with .NET or whatever, one can say
        pretty well how long a feature takes), and management obviously loves
        predictablilty and the emphasis on productivity. The main risk in
        such scenarious is often to build the wrong application, or an
        application that doesn't nearly serve the business as well as it could
        have. This risk can be effectivly mitigated by producing something
        useful as early as possible and iteratively improving it based on
        feedback.

        Regards

        Jens


        The following comment to Corey Ladas' Scrumban-article can be read as
        a testimony to the continuing appeal of the first style of Scrum for
        genuinely creative, novel work and is very much in line with Ken
        Schwaber's first book on Scrum and comments by Ken Schwaber on this
        list concerning the relationship of Scrum and Lean:

        http://leansoftwareengineering.com/ksse/scrum-ban/#comment-3382

        "[...] I'm applying this [kanban-based organization of development
        work] to game development where there is a transition from exploring
        the game mechanics (fun) using Scrum to the production phases where we
        develop 8-12 hours of assets using a Lean-Kanban approach. [...]
        Preproduction (Scrum) iterations are ideal for a 'unifying audacious
        goal' for the team. We don't know all of our tasks (often only 50%),
        so we leave room in the schedule for exploration."

        (You can read more on the context in the following article:
        http://www.gamasutra.com/view/feature/3847/beyond_scrum_lean_and_kanban_for_.php?print=1)

        Compare this to some random quotes from "Agile Software Development
        with Scrum" by Ken Schwaber and Mike Beedle:

        p 48: "The reason for having a Sprint goal is to give the team some
        wiggle room regarding the functionality."

        p 49: "The team compiles a list of tasks it has to complete to meet
        the Sprint goal. [...] Sometimes only a partial Sprint Backlog can be
        created."

        p 50: "During conflicts, the military will put teams of soldiers into
        insertion points in areas of operations. Each team is assigned a
        mission to accomplish and self-organizes to accomplish it. [...]
        Scrum was first described in similar terms [Takeuchi and Nonaka]:
        'Typically, the process starts with management giving the project team
        a broad goal. Rarely do they hand out a clear-cut new product concept
        or a specific work plan. Thus, while the project team has extreme
        freedom, it is also faced with extreme challenges embodied within the
        goal.'"

        p 51: "Scrum asks people to try to wrest a predictable product from
        unpredictable complexity."

        p 53: "Because Scrum allows the team to change the amount of work it
        performs during the Sprint, the team has some flexibility, and is able
        to do more or less so long as it meets its Sprint Goals."
      • MasaKevin Maeda
        We should also make sure that features that add a lot of value to the product and which are also high risk are addressed early on. That allows us to have test
        Message 3 of 25 , Mar 2, 2009
          We should also make sure that features that add a lot of value to the product and which are also high risk are addressed early on. That allows us to have test them more thoroughly and also to fail quickly, if we do. So my preference is to combine some easy stories with the high-value-high-risk ones at the beginning of a project.

          Masa K Maeda



        • jens.meydam
          Hi Masa ... the product and which are also high risk are addressed early on. That allows us to have test them more thoroughly and also to fail quickly, if we
          Message 4 of 25 , Mar 2, 2009
            Hi Masa

            --- In scrumdevelopment@yahoogroups.com, MasaKevin Maeda
            <masakmaeda@...> wrote:
            >
            > We should also make sure that features that add a lot of value to
            the product and which are also high risk are addressed early on. That
            allows us to have test them more thoroughly and also to fail quickly,
            if we do. So my preference is to combine some easy stories with the
            high-value-high-risk ones at the beginning of a project.
            >
            > Masa K Maeda
            >

            Do you estimate the features with high risk, and if you do, how?

            Difficult features may often be broken up into several smaller
            features, each of which is relatively straightforward to attack, but
            then, those are difficult features, not necessarily risky ones.

            For me, working on a risky feature is more like trying to fix a
            strange bug: perhaps you know where to start, but you can't really say
            how long it is going to take. "Here be dragons."

            One could try to do lots of research up front until one feels ready
            to commit, but that is not really the point of Scrum, is it?

            Regards

            Jens
          • aacockburn
            Nice! I am just teaching a Scrum course this week, and your post fits well with what I m encountering, and is a good reminder. The drive of newcomers for
            Message 5 of 25 , Mar 2, 2009
              Nice! I am just teaching a Scrum course this week, and your post fits
              well with what I'm encountering, and is a good reminder. The drive of
              newcomers for certainty is at odds with certain aspects of Scrum.

              Nothing more to add at this point - looking forward to others' posts.

              Alistair

              --- In scrumdevelopment@yahoogroups.com, "jens.meydam"
              <jens.meydam@...> wrote:
              >
              > Many of those who post questions on this list seem to aim for a very
              > high degree of predictability.
              >
              > There is a lot of good advice, starting with the popular practice to
              > fill the (top of the) backlog with small, relatively well understood
              > user stories. Such small stories can already be estimated quite
              well
              > even without decomposing them into tasks.
              >
              > To make progress even more predictable, it is often recommended to
              > double-check the estimates of the selected backlog (usually in story
              > points) by decomposing all stories up front into tasks (during the
              > second half of the sprint planning meeting), estimating the tasks
              > (usually in hours) and then adding up the task estimates to see if
              the
              > result really seems doable.
              >
              > A sprint is then considered successful if the selected stories all
              get
              > done as promised, perhaps plus or minus one story.
              >
              > This is Scrum, right?
              >
              > Well, today I picked up "Agile Software Development with Scrum" by
              Ken
              > Schwaber and Mike Beedle and re-read some passages, and I noticed
              how
              > very different their notion of Scrum is compared to Scrum as it is
              > often described and practiced today. The leitmotiv of that book is
              > the complexity and unpredictability of the work, and how much
              courage
              > and determination it takes just to get started, let alone to promise
              > anything concrete.
              >
              > Rather than committing to the delivery of a number of well-
              understood,
              > fine-grained user stories, the team tries to achieve a single
              > important goal, the scope of which is deliberately left vague. The
              > team is not expected to be able to say precisely how much it will
              > deliver. In fact, the work might be so difficult that it might be
              > perfectly acceptable for the team not to achieve the sprint goal at
              > all, as long as important knowledge has been gained.
              >
              > A few months ago, Ken Schwaber said in one of his comments on this
              > list that Scrum was really created for situations where "more is
              > unknown than known" (quoted from memory). I suppose this points to
              > the view of Scrum that is documented in "Agile Software Development
              > with Scrum".
              >
              > So there seem two quite distinct types or styles of Scrum, with
              > different practices, meant for different situations:
              >
              > Scrum I:
              >
              > - emphasizing knowledge generation
              > - development can be described as achieving break-throughs in the
              face
              > of substantial uncertainty and risk
              > - if you make precise commitments you are fooling yourself
              >
              > Scrum II:
              >
              > - emphasizing (at least short-term) predictability and speed of
              > development
              > - development can be described as growing a system feature by
              feature
              >
              > I wonder what you think about this.
              >
              > Jens
              >
            • Roy Morien
              Why is that not Scrum? If a User Story appears to have substantial risk, then you need to understand more about it before you commit to it. I would assume that
              Message 6 of 25 , Mar 2, 2009
                Why is that not Scrum? If a User Story appears to have substantial risk, then you need to understand more about it before you commit to it. I would assume that the Story Points for that story would go up to reflect the potential time requirements, and the complexity of it. If it needs more time to think about, discuss, mull over, try out then so be it. Why would Scrum somehow indicate that you shouldn't spend that time doing that? I would certainly do the high risk stories at the start, if it appears that the rest of the project hangs on the success or failure of that.
                 
                But, is this problem of 'high risk' more apparent than real? Yes, potentially there will be user stories that are high risk ... but how often have you actually encountered that in fact, rather than in theory? And is 'high risk' the same as 'complexity'? I don't think so, but what do you think?
                 
                Regards,
                Roy Morien
                 

                To: scrumdevelopment@yahoogroups.com
                From: jens.meydam@...
                Date: Mon, 2 Mar 2009 20:27:09 +0000
                Subject: [scrumdevelopment] Re: A tale of two Scrums

                Hi Masa

                --- In scrumdevelopment@ yahoogroups. com, MasaKevin Maeda
                <masakmaeda@ ...> wrote:
                >
                > We should also make sure that features that add a lot of value to
                the product and which are also high risk are addressed early on. That
                allows us to have test them more thoroughly and also to fail quickly,
                if we do. So my preference is to combine some easy stories with the
                high-value-high- risk ones at the beginning of a project.
                >
                > Masa K Maeda
                >

                Do you estimate the features with high risk, and if you do, how?

                Difficult features may often be broken up into several smaller
                features, each of which is relatively straightforward to attack, but
                then, those are difficult features, not necessarily risky ones.

                For me, working on a risky feature is more like trying to fix a
                strange bug: perhaps you know where to start, but you can't really say
                how long it is going to take. "Here be dragons."

                One could try to do lots of research up front until one feels ready
                to commit, but that is not really the point of Scrum, is it?

                Regards

                Jens




                Explore the new Windows Live. Looking for a place to manage all your online stuff?
              • Roy Morien
                I agree that things are probably not as unpredictable as in previous times. But they are still unpredictable. It is just a matter of how much. I have long held
                Message 7 of 25 , Mar 2, 2009
                  I agree that things are probably not as unpredictable as in previous times. But they are still unpredictable. It is just a matter of how much. I have long held the belief that the various measurement scales such as Soft systems <===== >  Hard Systems, Complex Systems <=====> Simple Systems etc. are inappropriate. In the case now being discussed, that is of some measure of predictability, the measurement scale is, in my view Highly Unpredictable <=====> Less Unpredictable (or something). The point being that there is always a level of unpredictablity. The trick is to acknowledge and make whatever attempts you can to handle it. The problem has always been that people somehow thought that they could eradicate it by the studious use of Gantt Charts and other detailed planning devices.
                   
                  Regards,
                  Roy Morien

                   

                  To: scrumdevelopment@yahoogroups.com
                  From: jens.meydam@...
                  Date: Mon, 2 Mar 2009 17:03:30 +0000
                  Subject: [scrumdevelopment] Re: A tale of two Scrums

                  Hi Roy

                  --- In scrumdevelopment@ yahoogroups. com, Roy Morien <roymorien@. ..> wrote:

                  > But, however you do it, forget about predictability and it's
                  bedfellow productivity. Notions of productivity is always at risk
                  because of unpredictability. We can only do our best to mitigate
                  future risks, we cannot eradicate them.
                  >

                  In my opinion, Scrum as described in the first book by Ken Schwaber is
                  incompatible with the concept of velocity. Moreover, some of the
                  prescribed practices of Scrum make perfect sense only in the context
                  of this style of Scrum.

                  Below I have added some quotes I found interesting in this context.

                  On the other hand, XP-style Scrum (requirements in form of small user
                  stories, velocity), which seems to be the dominant practice today, is
                  obviously well suited for software development in a corporate setting.

                  Technology is often not _that_ unpredictable any more (after having
                  developed a couple of applications with .NET or whatever, one can say
                  pretty well how long a feature takes), and management obviously loves
                  predictablilty and the emphasis on productivity. The main risk in
                  such scenarious is often to build the wrong application, or an
                  application that doesn't nearly serve the business as well as it could
                  have. This risk can be effectivly mitigated by producing something
                  useful as early as possible and iteratively improving it based on
                  feedback.

                  Regards

                  Jens

                  The following comment to Corey Ladas' Scrumban-article can be read as
                  a testimony to the continuing appeal of the first style of Scrum for
                  genuinely creative, novel work and is very much in line with Ken
                  Schwaber's first book on Scrum and comments by Ken Schwaber on this
                  list concerning the relationship of Scrum and Lean:

                  http://leansoftware engineering. com/ksse/ scrum-ban/ #comment- 3382

                  "[...] I'm applying this [kanban-based organization of development
                  work] to game development where there is a transition from exploring
                  the game mechanics (fun) using Scrum to the production phases where we
                  develop 8-12 hours of assets using a Lean-Kanban approach. [...]
                  Preproduction (Scrum) iterations are ideal for a 'unifying audacious
                  goal' for the team. We don't know all of our tasks (often only 50%),
                  so we leave room in the schedule for exploration. "

                  (You can read more on the context in the following article:
                  http://www.gamasutr a.com/view/ feature/3847/ beyond_scrum_ lean_and_ kanban_for_ .php?print= 1)

                  Compare this to some random quotes from "Agile Software Development
                  with Scrum" by Ken Schwaber and Mike Beedle:

                  p 48: "The reason for having a Sprint goal is to give the team some
                  wiggle room regarding the functionality. "

                  p 49: "The team compiles a list of tasks it has to complete to meet
                  the Sprint goal. [...] Sometimes only a partial Sprint Backlog can be
                  created."

                  p 50: "During conflicts, the military will put teams of soldiers into
                  insertion points in areas of operations. Each team is assigned a
                  mission to accomplish and self-organizes to accomplish it. [...]
                  Scrum was first described in similar terms [Takeuchi and Nonaka]:
                  'Typically, the process starts with management giving the project team
                  a broad goal. Rarely do they hand out a clear-cut new product concept
                  or a specific work plan. Thus, while the project team has extreme
                  freedom, it is also faced with extreme challenges embodied within the
                  goal.'"

                  p 51: "Scrum asks people to try to wrest a predictable product from
                  unpredictable complexity."

                  p 53: "Because Scrum allows the team to change the amount of work it
                  performs during the Sprint, the team has some flexibility, and is able
                  to do more or less so long as it meets its Sprint Goals."




                  Get what you want at ebay. View photos of singles in your area
                • jens.meydam
                  Hi Alistair Thanks for your comment! I was myself a bit surprised when I caught myself thinking that, yes, sometimes, raw Scrum - no fine-grained user
                  Message 8 of 25 , Mar 3, 2009
                    Hi Alistair

                    Thanks for your comment!

                    I was myself a bit surprised when I caught myself thinking that, yes,
                    sometimes, "raw" Scrum - no fine-grained user stories with detailed
                    conditions of satisfaction, no story points, no velocity - just
                    a challenging goal and the inspect and adapt cycle - may be a much
                    better fit.

                    For me, the essence of Scrum is summed up in the following anecdote
                    ("Agile Software Development with Scrum" by Ken Schwaber and
                    Mike Beedle, p. 82):

                    "[...] Jeff Sutherland, VP of Engineering, went to the President of
                    Easel Corporation, and asked him, 'Have you ever seen a development
                    team to meet a traditional project plan.' He said, 'No.' Jeff said,
                    'I think the only thing you can trust is working software that the
                    team can demo. If you give the team complete freedom for 30 day
                    Sprints, at the end of the Sprint you will see exactly where the
                    product is, for better or worse.' He said, 'Fine, for the first time
                    I will know where product development really stands and can make the
                    appropriate decisions. I'm willing to take the risk of giving the
                    team autonomy for defined periods.'"

                    Regards

                    Jens
                  • jens.meydam
                    Hi Roy ... risk, ... then so ... that time ... My understanding is that there is a strong bias not to spend a lot of time just thinking and preparing. There is
                    Message 9 of 25 , Mar 3, 2009
                      Hi Roy

                      > Why is that not Scrum? If a User Story appears to have substantial
                      risk,
                      > then you need to understand more about it before you commit to it.

                      > If it needs more time to think about, discuss, mull over, try out
                      then so
                      > be it. Why would Scrum somehow indicate that you shouldn't spend
                      that time
                      > doing that?

                      My understanding is that there is a strong bias not to spend a lot of
                      time just thinking and preparing.

                      There is the concept of a "spike story", which may be considered as a
                      very small, time-boxed research project that is scheduled along with
                      other stories. The purpose of a spike story is to shed enough light
                      on the original, "risky" story so that it can be planned and estimated
                      in a meaningful way.

                      But if you are about to venture into uncharted territory, if you are
                      doing something totally new, you may have to dedicate one or even
                      several entire iterations to finding a spike solution before you can
                      return to "normal", (relatively) predictable development.

                      "Raw" Scrum - just giving a team challenging goals, inspecting
                      whatever it manages to achieve, and adapting accordingly - is an
                      excellent process for such highly creative work the main purpose of
                      which is to generate knowledge.

                      > But, is this problem of 'high risk' more apparent than real?
                      > Yes, potentially there will be user stories that are high risk ...
                      but how
                      > often have you actually encountered that in fact, rather than in
                      theory?
                      > And is 'high risk' the same as 'complexity'? I don't think so,
                      > but what do you think?

                      I think that XP-style Scrum (requirements in the form of fine-grained,
                      relatively well-understood user stories with detailed conditions of
                      satisfaction, predictable velocity) has become the dominant style of
                      Scrum because it is usually possible to progress in small,
                      well-defined steps, even if one cannot see clearly more than a few
                      steps ahead:

                      "Affirming the desirability of the goal [...], we have concentrated on
                      the steps that are achievable and verifiable."

                      (http://groups.yahoo.com/group/scrumdevelopment/message/36567)

                      A situation I have recently encountered where "raw" Scrum was more
                      appropriate was the development of a prototype for a
                      CRM-customization. The CRM-software was highly extensible, but we
                      didn't know if we could really make it fit our needs, nor did we know
                      what the customized solution should precisely look like. Just trying
                      it (after minimal preparation) was a very effective and efficient way
                      to find answers to both questions.

                      Regards

                      Jens
                    • Pablo Emanuel
                      Message 10 of 25 , Mar 3, 2009
                        <<But if you are about to venture into uncharted territory, if you are
                        doing something totally new, you may have to dedicate one or even
                        several entire iterations to finding a spike solution before you can
                        return to "normal", (relatively) predictable development.>>
                         
                        That's what RUP calls the Elaboration phase. People often misunderstand RUP's Elaboration with a document-centric phase, but it's stated goal is to have a "validated architecture", i.e., the proposed architecture must be implemented and validated. Moreover, the elaboration phase is structured in time-boxed iterations just like the construction phase.
                         
                        Essentially, in RUP, you divide your iterations (sprints) in 4 types - you call them Inception when you're still trying to understand the vision and the business case - what we're going to do, what are the business constraints, what are our ballpark estimates; you call them Elaboration until you're confident enough with the technical solution, so you can start to have better estimates and a framework to guide development, and you're confident with the main risks; then you call them Construction until you're decided to go to market; after that, you start calling it Transition. It's important for some reasons: to set multi-iteration goals to drive the work, to create decision gates and - more related to the point of the e-mail - to change the level of formality of the process. It's a principle that's in the RUP literature to increase the formalism towards the end of the project - in the first phases, people should be freer to experiment, change their minds, and review their estimates; in the last phases, when you're trying to land the project, you should start being stricter.

                        2009/3/3 jens.meydam <jens.meydam@...>

                        Hi Roy



                        > Why is that not Scrum? If a User Story appears to have substantial
                        risk,
                        > then you need to understand more about it before you commit to it.

                        > If it needs more time to think about, discuss, mull over, try out
                        then so
                        > be it. Why would Scrum somehow indicate that you shouldn't spend
                        that time
                        > doing that?

                        My understanding is that there is a strong bias not to spend a lot of
                        time just thinking and preparing.

                        There is the concept of a "spike story", which may be considered as a
                        very small, time-boxed research project that is scheduled along with
                        other stories. The purpose of a spike story is to shed enough light
                        on the original, "risky" story so that it can be planned and estimated
                        in a meaningful way.

                        But if you are about to venture into uncharted territory, if you are
                        doing something totally new, you may have to dedicate one or even
                        several entire iterations to finding a spike solution before you can
                        return to "normal", (relatively) predictable development.

                        "Raw" Scrum - just giving a team challenging goals, inspecting
                        whatever it manages to achieve, and adapting accordingly - is an
                        excellent process for such highly creative work the main purpose of
                        which is to generate knowledge.


                        > But, is this problem of 'high risk' more apparent than real?
                        > Yes, potentially there will be user stories that are high risk ...
                        but how
                        > often have you actually encountered that in fact, rather than in
                        theory?
                        > And is 'high risk' the same as 'complexity'? I don't think so,
                        > but what do you think?

                        I think that XP-style Scrum (requirements in the form of fine-grained,
                        relatively well-understood user stories with detailed conditions of
                        satisfaction, predictable velocity) has become the dominant style of
                        Scrum because it is usually possible to progress in small,
                        well-defined steps, even if one cannot see clearly more than a few
                        steps ahead:

                        "Affirming the desirability of the goal [...], we have concentrated on
                        the steps that are achievable and verifiable."

                        (http://groups.yahoo.com/group/scrumdevelopment/message/36567)

                        A situation I have recently encountered where "raw" Scrum was more
                        appropriate was the development of a prototype for a
                        CRM-customization. The CRM-software was highly extensible, but we
                        didn't know if we could really make it fit our needs, nor did we know
                        what the customized solution should precisely look like. Just trying
                        it (after minimal preparation) was a very effective and efficient way
                        to find answers to both questions.

                        Regards

                        Jens


                      • Adam Sroka
                        ... The concept of a spike solution is to create a small naive implementation that illuminates the problem you are trying to solve without necessarily being
                        Message 11 of 25 , Mar 3, 2009
                          On Tue, Mar 3, 2009 at 2:58 PM, jens.meydam <jens.meydam@...> wrote:
                          > Hi Roy
                          >
                          >> Why is that not Scrum? If a User Story appears to have substantial
                          > risk,
                          >> then you need to understand more about it before you commit to it.
                          >
                          >> If it needs more time to think about, discuss, mull over, try out
                          > then so
                          >> be it. Why would Scrum somehow indicate that you shouldn't spend
                          > that time
                          >> doing that?
                          >
                          > My understanding is that there is a strong bias not to spend a lot of
                          > time just thinking and preparing.
                          >
                          > There is the concept of a "spike story", which may be considered as a
                          > very small, time-boxed research project that is scheduled along with
                          > other stories. The purpose of a spike story is to shed enough light
                          > on the original, "risky" story so that it can be planned and estimated
                          > in a meaningful way.

                          The concept of a spike solution is to create a small naive
                          implementation that illuminates the problem you are trying to solve
                          without necessarily being adequate for production use. Such a solution
                          drives a "spike" through the system, shedding light on the relevant
                          bits without paying a lot of attention to quality or correctness.

                          The "spike story" is an extension of "spike solution" which devotes a
                          time-box to develop such a solution in order to more accurately
                          estimate what is involved in an actual solution.

                          As practiced in XP spike solutions take minutes, often hours, rarely
                          days. Most of the time a spike story should be time-boxed to no more
                          than a few hours. If you can't learn anything about what you plan to
                          do in a few hours then it is likely the problem you are attacking is
                          too large to be defined this way. Actual research would probably be
                          more appropriate than experimentation for a very large problem space.
                          Although it is possible that such a problem could be decomposed and
                          individual bits of it could benefit from spiking.

                          > But if you are about to venture into uncharted territory, if you are
                          > doing something totally new, you may have to dedicate one or even
                          > several entire iterations to finding a spike solution before you can
                          > return to "normal", (relatively) predictable development.
                          >

                          Something that takes "several entire iterations" is most decidedly not
                          a spike solution. It is something else entirely. Most likely it is big
                          upfront design. I would prefer it if you didn't use the term Spike to
                          describe such a thing for the reasons discussed here:
                          http://martinfowler.com/bliki/SemanticDiffusion.html

                          > "Raw" Scrum - just giving a team challenging goals, inspecting
                          > whatever it manages to achieve, and adapting accordingly - is an
                          > excellent process for such highly creative work the main purpose of
                          > which is to generate knowledge.
                          >

                          The original descriptions of Scrum refer to a planning process, a
                          predefined period of work known as a Sprint, and a demonstration at
                          the end of the Sprint where working software that was completed during
                          the Sprint is demonstrated prior to the next phase of planning. The
                          only thing it says about what happens /during/ the Sprint is that
                          developers go off and develop software and there are daily Scrum
                          meetings.

                          The problem with this is that a lot of the organizations attempting to
                          adopt Scrum had never asked their people to go off and develop and
                          return with something that worked and was demonstrable in thirty days
                          (or less). So, inevitably people said, "This is great, but what
                          exactly is it that I'm supposed to be doing for thirty days?"

                          Over the years we have come up with a number of recommendations about
                          what people should be doing day-to-day and even hour-to-hour (or
                          minute-to-minute in the case of things like TDD and Continuous
                          Integration.) Some of these things were borrowed from XP (Which itself
                          borrowed from Scrum.) Some of these things were borrowed from Lean, or
                          elsewhere. Some were new inventions entirely. The nice thing is that
                          Scrum neither forces us to use any of these nor gets in the way if we
                          do chose to use them. The important thing is that all of these methods
                          have values in common, derived from or at least compatible with the
                          values expressed in the Agile Manifesto.

                          >> But, is this problem of 'high risk' more apparent than real?
                          >> Yes, potentially there will be user stories that are high risk ...
                          > but how
                          >> often have you actually encountered that in fact, rather than in
                          > theory?
                          >> And is 'high risk' the same as 'complexity'? I don't think so,
                          >> but what do you think?
                          >
                          > I think that XP-style Scrum (requirements in the form of fine-grained,
                          > relatively well-understood user stories with detailed conditions of
                          > satisfaction, predictable velocity) has become the dominant style of
                          > Scrum because it is usually possible to progress in small,
                          > well-defined steps, even if one cannot see clearly more than a few
                          > steps ahead:
                          >
                          > "Affirming the desirability of the goal [...], we have concentrated on
                          > the steps that are achievable and verifiable."
                          >
                          > (http://groups.yahoo.com/group/scrumdevelopment/message/36567)
                          >
                          > A situation I have recently encountered where "raw" Scrum was more
                          > appropriate was the development of a prototype for a
                          > CRM-customization. The CRM-software was highly extensible, but we
                          > didn't know if we could really make it fit our needs, nor did we know
                          > what the customized solution should precisely look like. Just trying
                          > it (after minimal preparation) was a very effective and efficient way
                          > to find answers to both questions.
                          >

                          Your premise seems to be that small stories come from XP and that
                          Scrum has borrowed them from there though they aren't always
                          appropriate for every project. I don't think that this is historically
                          accurate. I've been involved in the Agile community since the late 90s
                          when both Scrum and XP were just becoming popular. At that time, both
                          XP and Scrum described stories differently than they do today. In
                          fact, the original XP "White Book" describes stories as individual
                          feature descriptions which take a few weeks to implement (As opposed
                          to today where many people say that a story should take a couple of
                          days or less.)

                          In my estimation smaller story size started to become popular in
                          *both* XP and Scrum around the same time that the idea of automated
                          acceptance testing became popular. I'm not sure when this started but
                          it reached a peak with the popular adoption of FIT/FitNesse eventually
                          progressing to things like BDD/RSpec and "Story-Test Driven
                          Development". Around this time there was a movement to eschew names
                          like Scrum and XP in favor of the all encompassing Big-A Agile.

                          So, the waters are necessarily muddier than you would have us believe.
                          There is a set of practices that are distinctly XP. There is, to some
                          extent, a set of rules that are distinctly Lean. There is a set of
                          practices that are distinctly Scrum which consist exclusively of
                          Release/Sprint Planning, Sprints, Daily Scrums, and
                          Demo/Retrospective. Then there are a nearly infinite number of ways of
                          combining these fundamental things together with a whole host of
                          optional things and things that are variously interpreted all of which
                          fall under the general heading of Agile.
                        • Ron Jeffries
                          Hello, jens.meydam. On Monday, March 2, 2009, at 12:03:30 PM, you ... Doesn t the burn down occur in the first book? Isn t velocity just the first derivative
                          Message 12 of 25 , Mar 4, 2009
                            Hello, jens.meydam. On Monday, March 2, 2009, at 12:03:30 PM, you
                            wrote:

                            > In my opinion, Scrum as described in the first book by Ken Schwaber is
                            > incompatible with the concept of velocity.

                            Doesn't the burn down occur in the first book? Isn't velocity just
                            the first derivative of burn down?

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            Attend our CSM Plus Course!
                            http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                            Analysis kills spontaneity.
                            The grain once ground into flour germinates no more. -- Henri Amiel
                          • jens.meydam
                            Hi Ron ... Yes, although the term burndown chart seems to have come into use only after the first book was published. The expression backlog chart is used
                            Message 13 of 25 , Mar 4, 2009
                              Hi Ron

                              --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                              >
                              > Hello, jens.meydam. On Monday, March 2, 2009, at 12:03:30 PM, you
                              > wrote:
                              >
                              > > In my opinion, Scrum as described in the first book by Ken Schwaber is
                              > > incompatible with the concept of velocity.
                              >
                              > Doesn't the burn down occur in the first book?

                              Yes, although the term "burndown chart" seems to have come into use only after the first book was published. The expression "backlog chart" is used instead.

                              > Isn't velocity just the first derivative of burn down?

                              No - if burndown is tracked in the way originally recommended for Scrum. I would define velocity and burndown (done properly the Scrum way) as follows:

                              Velocity: The speed at which functionality is being developed, measured as complexity units per time period. Example: "Our average velocity is 20 story points per three-week sprint."

                              Burndown (done by the book): The change of the total time estimate for all the work the team is planning to do in order to meet the sprint goal. Example: "We couldn't implement the functionality as originally intended - we couldn't possibly have finished everything (totaling 100 hours) in time for the sprint review tomorrow. We decided to leave everything out that is not absolutely essential and implement the functionality with a workaround. See our burndown chart: from 100 to 5 hours in just one day! At least it will work, and now we know how to do it properly."

                              In Scrum, the team is free to change scope. It usually _has_ to manage scope in order to finish the sprint on the X-axis:

                              "Every product development project is constrained by four variables, (1) time available, (2) cost [...], (3) delivered quality, and (4) delivered functionality. A Sprint greatly fixes the first three variables. [...] The team has the authority to change the functionality of the Sprint so long as it meets its Sprint Goal. The team does this by decreasing or increasing the scope or depth of the functionality delivered." ("Agile Software Development with Scrum" by Ken Schwaber and Mike Beedle, p. 52)

                              It is perfectly OK to fill the sprint backlog with just enough work to get started (http://leansoftwareengineering.com/ksse/scrum-ban/#comment-3382). New work may be discovered while making progress towards the sprint goal, but the team may also decide to leave out tasks because they no longer make sense or because they aren't essential for meeting the sprint goal and there is not enough time left.

                              Used that way, the graph of the burndown chart may move up and down without any relation to the speed at which functionality is being developed - that is, without any relation to velocity. It may just have gone down steeply not because the team *implemented* lots of complicated functionality, but because it decided to *leave out* functionality!

                              Now, our own burndown chart does not work that way. We faithfully track completed story points, so we can in fact interpret the slope of the graph as our velocity. But then, the backlog items have to be fairly well understood and our progress has to be very predictable if we want to end up on the X-axis. It is possible for us to end up way above the X-axis - this is not what is supposed to happen with a real burndown chart!

                              Regards

                              Jens
                            • jens.meydam
                              Hi Adam I appreciate your detailed comments concerning the usage of the term spike and the history of the adoption of fine-grained user stories as the
                              Message 14 of 25 , Mar 4, 2009
                                Hi Adam

                                I appreciate your detailed comments concerning the usage of the term "spike" and the history of the adoption of fine-grained user stories as the preferred way to specify requirements. (Mike Cohn probably deserves some credit for the latter.)

                                Let me just add that my association of certain practices (like specification of soon-to-be developed requirements in form of small, well understood user stories) with XP may stem from my observation that people close to XP seem to feel particularly strongly about these practices.

                                What I still wonder, though, is whether we are really heading towards a kind of "Unified Agile Method" combining the best of Scrum, XP, Chrystal, ... - or whether these approaches to software development and creative work are not really to some extent incompatible.

                                I have the impression that - depending on the style of Scrum - doing Scrum and doing XP can feel very different.

                                Regards

                                Jens
                              • Ron Jeffries
                                Hello, jens.meydam. On Wednesday, March 4, 2009, at 2:00:43 PM, ... That s why I recommend a burn UP chart. But even those who use a burn down do something to
                                Message 15 of 25 , Mar 4, 2009
                                  Hello, jens.meydam. On Wednesday, March 4, 2009, at 2:00:43 PM,
                                  you wrote:

                                  > Used that way, the graph of the burndown chart may move up and
                                  > down without any relation to the speed at which functionality is
                                  > being developed - that is, without any relation to velocity. It
                                  > may just have gone down steeply not because the team *implemented*
                                  > lots of complicated functionality, but because it decided to
                                  > *leave out* functionality!

                                  That's why I recommend a burn UP chart. But even those who use a
                                  burn down do something to show the jumps, as far as I've seen.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  www.xprogramming.com/blog
                                  Attend our CSM Plus Course!
                                  http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                                  Don't confuse more exact with better. -- Brian Marick
                                • Ron Jeffries
                                  Hello, jens.meydam. On Wednesday, March 4, 2009, at 3:36:29 PM, ... Yes, especially since we think we originated the ideas. Not that anyone is counting ...
                                  Message 16 of 25 , Mar 4, 2009
                                    Hello, jens.meydam. On Wednesday, March 4, 2009, at 3:36:29 PM,
                                    you wrote:

                                    > Let me just add that my association of certain practices (like
                                    > specification of soon-to-be developed requirements in form of
                                    > small, well understood user stories) with XP may stem from my
                                    > observation that people close to XP seem to feel particularly
                                    > strongly about these practices.

                                    Yes, especially since we think we originated the ideas. Not that
                                    anyone is counting ...

                                    > What I still wonder, though, is whether we are really heading
                                    > towards a kind of "Unified Agile Method" combining the best of
                                    > Scrum, XP, Chrystal, ... - or whether these approaches to software
                                    > development and creative work are not really to some extent incompatible.

                                    > I have the impression that - depending on the style of Scrum -
                                    > doing Scrum and doing XP can feel very different.

                                    I'm not quite sure what that means. Certainly operating at a high
                                    level of discipline feels different from a low level. Alistair used
                                    to say that Crystal was designed to require low discipline (and
                                    implicitly XP wasn't). I see no reason why a sufficiently
                                    low-discipline execution of XP wouldn't begin to look a lot like
                                    Crystal or Scrum, or why high-discipline versions of those wouldn't
                                    look like XP.

                                    I think it is all one elephant, whose tail and trunk and legs we
                                    grab onto and apply as our needs and judgment dictate.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    www.xprogramming.com/blog
                                    Attend our CSM Plus Course!
                                    http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                                    Those who attain to any excellence commonly spend life in some single
                                    pursuit, for excellence is not often gained upon easier terms.
                                    -- Samuel Johnson
                                  • jens.meydam
                                    Hi Pablo This sounds all like commons sense - I don t understand why the agile community doesn t speak more about this. Regards Jens
                                    Message 17 of 25 , Mar 4, 2009
                                      Hi Pablo

                                      This sounds all like "commons sense" - I don't understand why the agile community doesn't speak more about this.

                                      Regards
                                      Jens


                                      --- In scrumdevelopment@yahoogroups.com, Pablo Emanuel <pablo.emanuel@...> wrote:
                                      >
                                      > <<But if you are about to venture into uncharted territory, if you are
                                      > doing something totally new, you may have to dedicate one or even
                                      > several entire iterations to finding a spike solution before you can
                                      > return to "normal", (relatively) predictable development.>>
                                      >
                                      > That's what RUP calls the Elaboration phase. People often misunderstand
                                      > RUP's Elaboration with a document-centric phase, but it's stated goal is to
                                      > have a "validated architecture", i.e., the proposed architecture must be
                                      > implemented and validated. Moreover, the elaboration phase is structured in
                                      > time-boxed iterations just like the construction phase.
                                      >
                                      > Essentially, in RUP, you divide your iterations (sprints) in 4 types - you
                                      > call them Inception when you're still trying to understand the vision and
                                      > the business case - what we're going to do, what are the business
                                      > constraints, what are our ballpark estimates; you call them Elaboration
                                      > until you're confident enough with the technical solution, so you can start
                                      > to have better estimates and a framework to guide development, and you're
                                      > confident with the main risks; then you call them Construction until you're
                                      > decided to go to market; after that, you start calling it Transition. It's
                                      > important for some reasons: to set multi-iteration goals to drive the work,
                                      > to create decision gates and - more related to the point of the e-mail - to
                                      > change the level of formality of the process. It's a principle that's in the
                                      > RUP literature to increase the formalism towards the end of the project - in
                                      > the first phases, people should be freer to experiment, change their minds,
                                      > and review their estimates; in the last phases, when you're trying to land
                                      > the project, you should start being stricter.
                                      >
                                      > 2009/3/3 jens.meydam <jens.meydam@...>
                                      >
                                      > > Hi Roy
                                      > >
                                      > > > Why is that not Scrum? If a User Story appears to have substantial
                                      > > risk,
                                      > > > then you need to understand more about it before you commit to it.
                                      > >
                                      > > > If it needs more time to think about, discuss, mull over, try out
                                      > > then so
                                      > > > be it. Why would Scrum somehow indicate that you shouldn't spend
                                      > > that time
                                      > > > doing that?
                                      > >
                                      > > My understanding is that there is a strong bias not to spend a lot of
                                      > > time just thinking and preparing.
                                      > >
                                      > > There is the concept of a "spike story", which may be considered as a
                                      > > very small, time-boxed research project that is scheduled along with
                                      > > other stories. The purpose of a spike story is to shed enough light
                                      > > on the original, "risky" story so that it can be planned and estimated
                                      > > in a meaningful way.
                                      > >
                                      > > But if you are about to venture into uncharted territory, if you are
                                      > > doing something totally new, you may have to dedicate one or even
                                      > > several entire iterations to finding a spike solution before you can
                                      > > return to "normal", (relatively) predictable development.
                                      > >
                                      > > "Raw" Scrum - just giving a team challenging goals, inspecting
                                      > > whatever it manages to achieve, and adapting accordingly - is an
                                      > > excellent process for such highly creative work the main purpose of
                                      > > which is to generate knowledge.
                                      > >
                                      > > > But, is this problem of 'high risk' more apparent than real?
                                      > > > Yes, potentially there will be user stories that are high risk ...
                                      > > but how
                                      > > > often have you actually encountered that in fact, rather than in
                                      > > theory?
                                      > > > And is 'high risk' the same as 'complexity'? I don't think so,
                                      > > > but what do you think?
                                      > >
                                      > > I think that XP-style Scrum (requirements in the form of fine-grained,
                                      > > relatively well-understood user stories with detailed conditions of
                                      > > satisfaction, predictable velocity) has become the dominant style of
                                      > > Scrum because it is usually possible to progress in small,
                                      > > well-defined steps, even if one cannot see clearly more than a few
                                      > > steps ahead:
                                      > >
                                      > > "Affirming the desirability of the goal [...], we have concentrated on
                                      > > the steps that are achievable and verifiable."
                                      > >
                                      > > (http://groups.yahoo.com/group/scrumdevelopment/message/36567)
                                      > >
                                      > > A situation I have recently encountered where "raw" Scrum was more
                                      > > appropriate was the development of a prototype for a
                                      > > CRM-customization. The CRM-software was highly extensible, but we
                                      > > didn't know if we could really make it fit our needs, nor did we know
                                      > > what the customized solution should precisely look like. Just trying
                                      > > it (after minimal preparation) was a very effective and efficient way
                                      > > to find answers to both questions.
                                      > >
                                      > > Regards
                                      > >
                                      > > Jens
                                      > >
                                      > >
                                      > >
                                      >
                                    • jens.meydam
                                      Hi Ron Corey Ladas advocates the use of cumulative flow diagrams , which are a kind of burn UP chart
                                      Message 18 of 25 , Mar 4, 2009
                                        Hi Ron

                                        Corey Ladas advocates the use of "cumulative flow diagrams", which are a kind of "burn UP chart"
                                        (http://leansoftwareengineering.com/2009/01/23/video-lean-thinking-for-agile-process-evolution/).

                                        Those diagrams are a little complicated, though.

                                        Jeff Sutherland once pointed out a not-to-be-neglected advantage of burndown charts: For some reason, managers find them very easy to understand.

                                        Regards

                                        Jens


                                        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                        >
                                        > Hello, jens.meydam. On Wednesday, March 4, 2009, at 2:00:43 PM,
                                        > you wrote:
                                        >
                                        > > Used that way, the graph of the burndown chart may move up and
                                        > > down without any relation to the speed at which functionality is
                                        > > being developed - that is, without any relation to velocity. It
                                        > > may just have gone down steeply not because the team *implemented*
                                        > > lots of complicated functionality, but because it decided to
                                        > > *leave out* functionality!
                                        >
                                        > That's why I recommend a burn UP chart. But even those who use a
                                        > burn down do something to show the jumps, as far as I've seen.
                                        >
                                        > Ron Jeffries
                                        > www.XProgramming.com
                                        > www.xprogramming.com/blog
                                        > Attend our CSM Plus Course!
                                        > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                                        > Don't confuse more exact with better. -- Brian Marick
                                        >
                                      • jens.meydam
                                        Hi Ron Thanks for your comment - you helped me make sense of the elephant. It s always a delight to read your posts. Regards Jens
                                        Message 19 of 25 , Mar 4, 2009
                                          Hi Ron

                                          Thanks for your comment - you helped me make sense of the elephant.

                                          It's always a delight to read your posts.

                                          Regards

                                          Jens

                                          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                          >
                                          > Hello, jens.meydam. On Wednesday, March 4, 2009, at 3:36:29 PM,
                                          > you wrote:
                                          >
                                          > > Let me just add that my association of certain practices (like
                                          > > specification of soon-to-be developed requirements in form of
                                          > > small, well understood user stories) with XP may stem from my
                                          > > observation that people close to XP seem to feel particularly
                                          > > strongly about these practices.
                                          >
                                          > Yes, especially since we think we originated the ideas. Not that
                                          > anyone is counting ...
                                          >
                                          > > What I still wonder, though, is whether we are really heading
                                          > > towards a kind of "Unified Agile Method" combining the best of
                                          > > Scrum, XP, Chrystal, ... - or whether these approaches to software
                                          > > development and creative work are not really to some extent incompatible.
                                          >
                                          > > I have the impression that - depending on the style of Scrum -
                                          > > doing Scrum and doing XP can feel very different.
                                          >
                                          > I'm not quite sure what that means. Certainly operating at a high
                                          > level of discipline feels different from a low level. Alistair used
                                          > to say that Crystal was designed to require low discipline (and
                                          > implicitly XP wasn't). I see no reason why a sufficiently
                                          > low-discipline execution of XP wouldn't begin to look a lot like
                                          > Crystal or Scrum, or why high-discipline versions of those wouldn't
                                          > look like XP.
                                          >
                                          > I think it is all one elephant, whose tail and trunk and legs we
                                          > grab onto and apply as our needs and judgment dictate.
                                          >
                                          > Ron Jeffries
                                          > www.XProgramming.com
                                          > www.xprogramming.com/blog
                                          > Attend our CSM Plus Course!
                                          > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                                          > Those who attain to any excellence commonly spend life in some single
                                          > pursuit, for excellence is not often gained upon easier terms.
                                          > -- Samuel Johnson
                                          >
                                        • Ron Jeffries
                                          Hello, jens.meydam. On Wednesday, March 4, 2009, at 4:14:16 PM, ... Yes, well ... they can understand this, too ...
                                          Message 20 of 25 , Mar 4, 2009
                                            Hello, jens.meydam. On Wednesday, March 4, 2009, at 4:14:16 PM,
                                            you wrote:

                                            > Jeff Sutherland once pointed out a not-to-be-neglected advantage
                                            > of burndown charts: For some reason, managers find them very easy to understand.

                                            Yes, well ... they can understand this, too ...

                                            http://www.xprogramming.com/xpmag/BigVisibleCharts.htm#N65708

                                            Ron Jeffries
                                            www.XProgramming.com
                                            www.xprogramming.com/blog
                                            Attend our CSM Plus Course!
                                            http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                                            Adapt, improvise, overcome.
                                            --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
                                          • Lang Tran
                                            ... This seems to imply that Scrum and XP are the same. I m pretty new to Scrum and agile so I m hoping to improve my understanding. My understanding of
                                            Message 21 of 25 , Mar 7, 2009
                                              --- In scrumdevelopment@yahoogroups.com, "jens.meydam" <jens.meydam@...> wrote:
                                              >
                                              > Hi Adam
                                              >
                                              > I appreciate your detailed comments concerning the usage of the term "spike" and the history of the adoption of fine-grained user stories as the preferred way to specify requirements. (Mike Cohn probably deserves some credit for the latter.)
                                              >
                                              > Let me just add that my association of certain practices (like specification of soon-to-be developed requirements in form of small, well understood user stories) with XP may stem from my observation that people close to XP seem to feel particularly strongly about these practices.
                                              >
                                              > What I still wonder, though, is whether we are really heading towards a kind of "Unified Agile Method" combining the best of Scrum, XP, Chrystal, ... - or whether these approaches to software development and creative work are not really to some extent incompatible.
                                              >
                                              > I have the impression that - depending on the style of Scrum - doing Scrum and doing XP can feel very different.

                                              This seems to imply that Scrum and XP are the same. I'm pretty new to Scrum and agile so I'm hoping to improve my understanding. My understanding of Scrum is it's a way to manage agile software development and a wrapper for the engineering practices. XP represents the engineering practices that seem to align best with Scrum but are not prescribed by Scrum.

                                              Lang
                                            • Ron Jeffries
                                              ... XP //includes// engineering practices. It is, however, a full-on Agile method whose management wrapper is almost indistinguishable from that of Scrum,
                                              Message 22 of 25 , Mar 7, 2009
                                                Hello, Lang. On Saturday, March 7, 2009, at 9:11:51 AM, you wrote:

                                                > This seems to imply that Scrum and XP are the same. I'm pretty
                                                > new to Scrum and agile so I'm hoping to improve my understanding.
                                                > My understanding of Scrum is it's a way to manage agile software
                                                > development and a wrapper for the engineering practices. XP
                                                > represents the engineering practices that seem to align best with
                                                > Scrum but are not prescribed by Scrum.

                                                XP //includes// engineering practices. It is, however, a full-on
                                                Agile method whose management wrapper is almost indistinguishable
                                                from that of Scrum, especially now that Scrummers are adopting more
                                                aspects from the XP lexicon.

                                                Ron Jeffries
                                                www.XProgramming.com
                                                www.xprogramming.com/blog
                                                Attend our CSM Plus Course!
                                                http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                                                What is your dream? And knowing this, what have you
                                                done to work towards realizing it today? -- Les Brown
                                              • srinivas chillara
                                                almost indistinguishable   Really!?! I think the roles are much more explicit in Scrum....and even practices (other than the planning and stand-up) are
                                                Message 23 of 25 , Mar 8, 2009
                                                  "almost indistinguishable"
                                                   
                                                  Really!?! I think the roles are much more explicit in Scrum....and even practices (other than the planning and stand-up) are quite different... without being prescriptive.
                                                  Yes, if you are talking about the way stories are picked up for the iteration/Sprint, there is not much difference. In arriving at an approach for managing projects (small or large) Scrum surely brings much more clarity and over all control than XP does.
                                                   
                                                  I'm not splitting hairs, pointing out how the SPM is conducted vurses how an XP iteration is planned, would be.

                                                  --- On Sat, 7/3/09, Ron Jeffries <ronjeffries@...> wrote:

                                                  From: Ron Jeffries <ronjeffries@...>
                                                  Subject: Re: [scrumdevelopment] Re: A tale of two Scrums
                                                  To: scrumdevelopment@yahoogroups.com
                                                  Date: Saturday, 7 March, 2009, 11:53 PM

                                                  Hello, Lang. On Saturday, March 7, 2009, at 9:11:51 AM, you wrote:

                                                  > This seems to imply that Scrum and XP are the same. I'm pretty
                                                  > new to Scrum and agile so I'm hoping to improve my understanding.
                                                  > My understanding of Scrum is it's a way to manage agile software
                                                  > development and a wrapper for the engineering practices. XP
                                                  > represents the engineering practices that seem to align best with
                                                  > Scrum but are not prescribed by Scrum.

                                                  XP //includes// engineering practices. It is, however, a full-on
                                                  Agile method whose management wrapper is almost indistinguishable
                                                  from that of Scrum, especially now that Scrummers are adopting more
                                                  aspects from the XP lexicon.

                                                  Ron Jeffries
                                                  www.XProgramming. com
                                                  www.xprogramming. com/blog
                                                  Attend our CSM Plus Course!
                                                  http://hendricksonx p.com/index. php?option= com_eventlist& Itemid=28
                                                  What is your dream? And knowing this, what have you
                                                  done to work towards realizing it today? -- Les Brown



                                                  Add more friends to your messenger and enjoy! Invite them now.
                                                • Ron Jeffries
                                                  Hello, srinivas. On Sunday, March 8, 2009, at 6:45:45 AM, you ... What are the main differences you see between the XP management wrapper and Scrum? Ron
                                                  Message 24 of 25 , Mar 8, 2009
                                                    Hello, srinivas. On Sunday, March 8, 2009, at 6:45:45 AM, you
                                                    wrote:

                                                    > Really!?! I think the roles are much more explicit in
                                                    > Scrum....and even practices (other than the planning and stand-up)
                                                    > are quite different... without being prescriptive.
                                                    > Yes, if you are talking about the way stories are picked up for
                                                    > the iteration/Sprint, there is not much difference. In arriving at
                                                    > an approach for managing projects (small or large) Scrum surely
                                                    > brings much more clarity and over all control than XP does.

                                                    > I'm not splitting hairs, pointing out how the SPM is conducted
                                                    > vurses how an XP iteration is planned, would be.

                                                    What are the main differences you see between the XP "management
                                                    wrapper" and Scrum?

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    www.xprogramming.com/blog
                                                    Attend our CSM Plus Course!
                                                    http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                                                    For me, XP ain't out there, it's in here. -- Bill Caputo
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.