36936Re: A tale of two Scrums
- Mar 4, 2009Hi Pablo
This sounds all like "commons sense" - I don't understand why the agile community doesn't speak more about this.
--- In email@example.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
- << Previous post in topic Next post in topic >>