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

Re: Scrum illness, symptoms and possible treatments

Expand Messages
  • dnicolet99
    ... 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
    Message 1 of 18 , 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
    • Mark Graybill
      I sure wish I had time to stay on this forum - lots of good stuff. I m curious about the people-factor characteristics. How would you describe their general
      Message 2 of 18 , Jan 8, 2007
      • 0 Attachment

        I sure wish I had time to stay on this forum – lots of good stuff.

         

        I’m curious about the people-factor characteristics… How would you describe their general attitudes, level of enthusiasm and other observations you may have noticed, such as inability to agree  - even conflict, or negative hallway conversations?  Do they surf or take breaks often or otherwise spend a lot of time socializing outside of work-related issues?  

         

        Have the teams ever really come together and developed into interdependent and cohesive teams?  Did they ever really buy into Scrum?  Have they been working overtime – do you think burnout and/or work-life imbalances?  I wonder if there may be external, non-Scrum factors involved (layoffs, sociopolitical/organizational stressors, or consistent discouragements and disappointments.

         

        How do you get along with the teams?  Are you overworked, such as also doing the people management side as well as development?  Do you lean toward Theory-X and/or Taylorism philosophies of management or do you like to be in control?  Do you feel the team needs to be managed or coached into a self-organizing, self-directing team?  Do you make task assignments or do they determine assignments?  Describe the confidence you have in team members and the team.  How well do you think you are leading?

         

        Has the teams’ team formation and leadership ever been developed?  Are there any strong personalities on the team?  What is the typical load factor?  Are there many distractions/fires to put out stealing their time?  Are there hero developers on the team?  Is there inconsistent (hypocritical) sponsorship or stakeholder support?

         

        Have they openly communicated ideas and concerns often, and then no longer?  

         

        What is your role?  Are you one of the Scrum masters or are you doing Scrum of Scrums and/or managing the Scrum masters?  If the latter, apply the inquiry above to your Scrum masters as well.  Also, how do the items mentioned above compare between the problematic teams and the others?  

         

        Was there a noticeable turning point, or was it more gradual?  

         

        If you are interested in this exchange, feel free to respond to me directly (Mark@...).

         

        Cheers!

        Mark

         


        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Clinton Keith
        Sent: Friday, December 29, 2006 12:35 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Scrum illness, symptoms and possible treatments

         

        Hi,

         

        I’ve been following the debate on Daily Burndowns here with interest  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.

         

        I would like to get some advice on how to rejuvenate the Scrum principles among teams. 

        First, the symptoms:

        - Lot ’s of dropped user stories.

        - “completeness” isn’t quite there on stories that are marked as complete (bugs, lack of polish)

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

        - Very quiet daily scrums

         

        I know these symptoms point to a lack of commitment and ownership on the teams.  We customers have pointed out the failures in the stories delivered during the reviews.  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? 

         

        There was mention of 2-day Sprints being used to help teams examine how they function and what they deliver.  Does this work?  Are there others? 


        Thanks,

        Clint

         

      Your message has been successfully submitted and would be delivered to recipients shortly.