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

18609Re: Scrum illness, symptoms and possible treatments

Expand Messages
  • dnicolet99
    Jan 3, 2007
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "Clinton Keith" <ckeith@...>
      wrote:

      >
      > We've been using Scrum for three years now and it seems as if a couple
      > of teams are experiencing an increased drag from the lack of novelty or
      > more of a robotic adherence to the Scrum practices. The Daily Burndown
      > is a good example of a practice that they are following, but not taking
      > full advantage of.

      The question reminds me of a topic that was addressed at the XP Days
      Germany conference in November. There was a session entitled "Turning
      up the heat without getting burned." It dealt with just this sort of
      thing - teams falling into a predictable and boring routine. The agile
      mode of work seems to call for a certain level of intensity. When that
      fades into monotony, some of the effectiveness of agile teams may be lost.

      The presenters of that session would probably suggest looking for ways
      to stir things up a bit; ways to "turn up the heat". Maybe introduce
      some sort of process roadblock or deliberately dredge up a known (but
      suppressed) interpersonal conflict. The point is to "shock" the team
      into remembering principles by forcing them to confront some sort of
      problem as a team (and not as a bunch of individuals).

      Even something as mundane as physically moving the team might break
      the logjam. Just sitting in different seats and looking at different
      backgrounds might give them a fresh perspective.

      It sounds like what you've got here is not a "process" problem that
      can be addressed in a "mechanical" way such as doing super-short
      iterations or increasing the measurements you make (daily burndowns,
      etc.). It sounds more like a "human factors" issue.


      >
      > - Lot's of dropped user stories.

      Ideally, only the Product Owner can drop stories (or at least, only
      he/she can choose which stories to drop when the team explains that it
      can't meet its commitments). What's happening in your case? Why and
      how are stories being dropped? Is it connected with another problem
      you mention, that extra tasks tend to proliferate while the stories
      don't change? Do the teams reflect on this and assess how they might
      self-correct? Do the teams have Scrum Masters or process facilitators
      under some other name? If not, consider adding this role; if the role
      already exists, find out why they are not acting on these problems.

      >
      > - "completeness" isn't quite there on stories that are marked as
      > complete (bugs, lack of polish)

      Why are Product Owners / customers accepting the results, then?

      >
      > - Lots of new tasks added during a sprint (without stories changing)

      Estimation problem?

      >
      > - Very quiet daily scrums

      Might need to prod team members into talking until they get (back?)
      into the habit.

      > The question that I have is, apart from
      > beating the teams during the reviews, are there some exercises and
      > coaching practices that can be used to help focus on these issues?
      >

      The beatings should continue until morale improves. That's basic
      Management Science, after all. ;-)

      -Dave
    • Show all 18 messages in this topic