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

Scrumdog Millionaire

Expand Messages
  • dbodenheimer@adicio.com
    Okay, so I couldn t resist that title. My apologies. My recent experience with scrum has been challenging. The Team has one strong lead personality who is
    Message 1 of 39 , Feb 19, 2009
    • 0 Attachment
      Okay, so I couldn't resist that title. My apologies.

      My recent experience with scrum has been challenging. The Team has one
      strong lead personality who is pushing hard for the following rules:
      1) User stories will not be estimated until they have wireframe mock-ups
      2) User stories that can not be done in a couple of days have to be broken
      down further -- nothing is estimated over 3 days
      3) All completed stories must be Accepted "on your own" before the
      iteration review.
      4) Demos at iteration review are only done as an exception and avoided at
      all costs to save time
      5) All discussions must be documented
      6) Any change, even small changes, to a User Story require a new User
      Story to be estimated at the next Estimation meeting (mock-ups required)
      7) Acceptance criteria "discovered along the way" that is not in the
      original estimated User Story has to be put into a new User Story and
      estimated at the next Estimation meeting -- some exceptions are made in
      which case the Acceptance Criteria has to be updated in the story.

      Please note that I'm trying to be fair here, and not attempting to be
      funny by overstating things -- these are the plain facts. Does the group
      strongly agree or disagree with any or all of these? I would appreciate a
      "checkup" on my expectations.

      One other note is that we are using Rally to track all stories,
      iterations, estimations, planning, status, and releases. www.rallydev.com
      -- we are not using cards pasted on a board.
    • davenicolette
      Good observations. I suspect what made that presentation effective wasn t necessarily that the drawings were low fidelity compared with PowerPoint slides, but
      Message 39 of 39 , Mar 1, 2009
      • 0 Attachment
        Good observations. I suspect what made that presentation effective
        wasn't necessarily that the drawings were low fidelity compared with
        PowerPoint slides, but rather that the drawings were made in real time
        in conjunction with your talk. The combination tends to help
        information stick in people's minds. People recall how the drawings
        were elaborated more easily than they can remember the details of a
        completed diagram that is presented to them all at once.

        --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
        >
        >
        > 'little cartooney icons' ... great idea and very successful often.
        One of the best (as in well received) presentations I ever made, to a
        group of user area people, including high level managers, was made by
        using a white board, some coloured markers, and free hand drawn images
        of telephone lines across the country, factories, stick figures in
        various colours for different users, badly drawn little cars and
        trucks and stuff like that. In the eyes of the 'Powerpoint Brigade' it
        may have been considered highly unprofessional and untidy, but the
        audience loved it. The comment was 'This is the first time I've ever
        really understaood a presentation about our systems. Usually we get
        snowed with a lot of technical jargon and beautiful diagrams that we
        don't understand'.
        >
        >
        >
        > This is somewhat reminiscent of the 'Rich Picture' that is part of
        the Soft Systems methodology, and could even be seen almost as a mind
        mapping diagram.
        >
        >
        >
        > As someone once said, it doesn't have to have sharp corners to be
        useful. The 'cloud' or 'potato' is ok too.
        >
        >
        >
        > Regards,
        >
        > Roy Morien
        >
        >
        >
        > To: scrumdevelopment@yahoogroups.com
        > From: dnicolet@...
        > Date: Sat, 28 Feb 2009 13:07:06 +0000
        > Subject: [scrumdevelopment] Re: ScrumMaster as facilitator vs.
        ScrumMaster as coach
        >
        >
        >
        >
        >
        > I like the IRiC idea. Sometimes I use little cartooney icons to
        > represent various stakeholders when explaining these concepts to
        > people unfamiliar with them. The one I like to use to represent the
        > ScrumMaster role is Ganesha, the god of removing obstacles.
        >
        > I don't think everyone has the same notions of what the plain English
        > words "coach" and "mentor" mean, and that further complicates
        > discussions of the difference between SM and "coach."
        >
        > Words get in the way, eh?
        >
        > Cheers,
        > Dave
        >
        > --- In scrumdevelopment@yahoogroups.com, "Joseph Little"
        > <jhlittle@> wrote:
        > >
        > > To the subject line and one comment below...
        > >
        > > My experience is that the most important thing an SM does is remove
        > > impediments (get impediments removed). He is the "Impediment Remover
        > > In Chief". All the other things fall under this. ("All" is perhaps too
        > > simplistic.)
        > >
        > > My experience is that "facilitator" (as I use that term) is a minor
        > > role in Scrum. (Others might define it more broadly than I do.)
        > >
        > > "Coach" again has different meanings to different people. If one means
        > > "coaching the team and those around the team to help remove
        > > impediments so that the team becomes more effective" then, it means
        > > about what I mean by Impediment-Remover-In-Chief.
        > >
        > > The IRiC phrase wants to emphasize an aspect parallel to the PO. It is
        > > key that the SM prioritize (do final prioritization) and own the
        > > Impediment List. And drive them, one-by-one to completion. (Drive's
        > > connotation of being Command & Control not intended.)
        > >
        > > My 2 cents.
        > >
        > > Thanks, Joe
        > >
        > >
        > >
        > > --- In scrumdevelopment@yahoogroups.com, "jens.meydam"
        > > <jens.meydam@> wrote:
        > > >
        > > > Hi Jaideep
        > > >
        > > > > Sustainable success can never be forced or imposed, it has to be
        > > > inculcated
        > > > > and groomed. If as soon as the ScrumMaster is gone, the impact is
        > > > also gone
        > > > > then it is the failure of SM. SM as facilitator or Coach, whatever
        > > > role he
        > > > > adopts, its sole purpose is to mature the team in such a manner to
        > > > be able
        > > > > to achieve success at the same pace, even if SM is gone.
        > > >
        > > > I don't really disagree with this. However, I think that often -
        > > > perhaps paradoxically - the best way to achieve this maturity
        quickly
        > > > is to do what Jeff Sutherland describes.
        > > >
        > > > "Forceful and mandatory" may sound politically incorrect to some
        > > > people here, but a "total [...] immersion experience" is exactly
        what
        > > > I want if I want to learn fast. This also applies to things like
        > > > learning a foreign language.
        > > >
        > > > Regards
        > > >
        > > > Jens
        > > >
        > > > _____
        > > > >
        > > > > From: scrumdevelopment@yahoogroups.com
        > > > > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of jens.meydam
        > > > > Sent: 27 February, 2009 11:49
        > > > > To: scrumdevelopment@yahoogroups.com
        > > > > Subject: [scrumdevelopment] Re: ScrumMaster as facilitator vs.
        > > > ScrumMaster
        > > > > as coach
        > > > >
        > > > >
        > > > >
        > > > > Hi Dave
        > > > >
        > > > > > I definitely agree the role of coach is responsible for
        making the
        > > > > > team successful. To me, that doesn't mean successful in meeting
        > > their
        > > > > > immediate commitments. It means helping them develop into
        the best
        > > > > > team they can be, over the long haul.
        > > > >
        > > > > I agree that ultimately, sustainable success cannot be forced.
        > If the
        > > > > team - even after a couple of months of success - is still
        likely to
        > > > > abandon everything the ScrumMaster introduced as soon as the
        > > > > ScrumMaster is gone, the success that might have been achieved
        > is not
        > > > > sustainable.
        > > > >
        > > > > On the other hand, I really like what Jeff Sutherland describes
        > in the
        > > > > blog post I referred to earlier
        > > > > (http://jeffsutherla
        > > > >
        > > >
        > >
        >
        <http://jeffsutherland.com/scrum/2008/09/shock-therapy-bootstrapping.html>
        > > > > nd.com/scrum/2008/09/shock-therapy-bootstrapping.html).
        > > > >
        > > > > Let me quote two paragraphs:
        > > > >
        > > > > "I heard similar stories from an Agile leader at JayWay in Sweden.
        > > > > Using a forceful and mandatory way of implementing Scrum and good
        > > > > engineering practices, that Agile leader got similar results to
        > > MySpace.
        > > > >
        > > > > Rob Mee at Pivotal Labs in San Francisco uses a forceful total XP
        > > > > immersion experience to bootstrap teams. They do everything
        exactly
        > > > > his way for three months. After that they have full body
        > understanding
        > > > > of the Agile motion and he can send them on their way. It has
        worked
        > > > > well on 40 startups so far."
        > > > >
        > > > > Regards
        > > > >
        > > > > Jens
        > > >
        > >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > _________________________________________________________________
        > Need a new place to rent, share or buy? Let ninemsn property help
        >
        http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Edomain%2Ecom%2Eau%2F%3Fs%5Fcid%3DFDMedia%3ANineMSN%5FHotmail%5FTagline&_t=774152450&_r=Domain_tagline&_m=EXT
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.