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

36929Re: [scrumdevelopment] Re: A tale of two Scrums

Expand Messages
  • Adam Sroka
    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:

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

      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.
    • Show all 25 messages in this topic