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

36936Re: A tale of two Scrums

Expand Messages
  • jens.meydam
    Mar 4, 2009
    • 0 Attachment
      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
      > >
      > >
      > >
      >
    • Show all 25 messages in this topic