36929Re: [scrumdevelopment] Re: A tale of two Scrums
- Mar 3, 2009On Tue, Mar 3, 2009 at 2:58 PM, jens.meydam <jens.meydam@...> wrote:
> Hi RoyThe concept of a spike solution is to create a small naive
>> Why is that not Scrum? If a User Story appears to have substantial
>> 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.
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 areSomething that takes "several entire iterations" is most decidedly not
> 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.
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, inspectingThe original descriptions of Scrum refer to a planning process, a
> 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.
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?Your premise seems to be that small stories come from XP and that
>> Yes, potentially there will be user stories that are high risk ...
> but how
>> often have you actually encountered that in fact, rather than in
>> 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."
> 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.
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.
- << Previous post in topic Next post in topic >>