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

Scrum illness, symptoms and possible treatments

Expand Messages
  • Clinton Keith
    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
    Message 1 of 18 , Dec 29 10:35 AM

      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

       

    • Mike Bria
      Hi Keith -- As far as the quality - Are your teams practicing TDD? Have you tried pair programming? Do you have a DONE checklist? As far as the dropped
      Message 2 of 18 , Dec 29 10:51 AM
        Hi Keith --

        As far as the quality - Are your teams practicing TDD? Have you tried
        pair programming? Do you have a "DONE" checklist?

        As far as the dropped stories and new tasks - How do approach sprint
        planning?

        Another thing that seems interesting is that your daily stand-ups are
        "quiet", yet new tasks are frequently "added during the sprint" - how
        are these new tasks communicated (and agreed on)? In general, how would
        you rate the collaboration among team members?

        --MB


        --- In scrumdevelopment@yahoogroups.com, "Clinton Keith" <ckeith@...>
        wrote:
        >
        > 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
        >
      • Clinton Keith
        Hi Mike, We do TDD/PP, but since we make video games TDD doesn t translate to all the disciplines (art, design, programming) on the team. We have a done
        Message 3 of 18 , Dec 29 11:13 AM

          Hi Mike,

           

          We do TDD/PP, but since we make video games TDD doesn’t translate to all the disciplines (art, design, programming) on the team.   We have a done column for our tasks and conditions of satisfaction for our stories.

           

          Sprint planning:

          - We have 2-week sprints based on ~1/2 day planning sessions with stories taken from a release backlog and broken down by the team.  They are usually 50% accurate with their sprint tasks (hours and task count), which is often due to the uncertainties even in a 2-week planning window for video games.

          - We have 120 people working on a game spread across ~14 teams.  All these team deliver on the same day (one product).

           

          The new tasks are identified during the day outside the scrum and the new cards brought to the daily scrums and posted.

           

          I would rate the collaboration among people of the same discipline (e.g. programmer-programmer, artist-artist) as good, but the collaboration across disciplines as less than that.

           

          I found that Alistair Cockburn’s article that Ron Jeffries pointed out the other day

          http://alistair.cockburn.us/index.php/Are_iterations_hazardous_to_your_project%3F

           

          To be insightful into a potential problem:  Do highly cross-discipline teams tend to pipeline more easily and prevent meaningful value in short iterations?


          Clint

           

           

           

           

          -----Original Message-----
          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Bria
          Sent: Friday, December 29, 2006 10:52 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Re: Scrum illness, symptoms and possible treatments

           

          Hi Keith --

          As far as the quality - Are your teams practicing TDD? Have you tried
          pair programming? Do you have a "DONE" checklist?

          As far as the dropped stories and new tasks - How do approach sprint
          planning?

          Another thing that seems interesting is that your daily stand-ups are
          "quiet", yet new tasks are frequently "added during the sprint" - how
          are these new tasks communicated (and agreed on)? In general, how would
          you rate the collaboration among team members?

          --MB

          --- In scrumdevelopment@ yahoogroups. com, "Clinton Keith" <ckeith@...>
          wrote:

          >
          > 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
          >

        • Ron Jeffries
          Hello, Clinton. On Friday, December 29, 2006, at 1:35:16 PM, you ... The only mention of 2-day sprints that I recall is that Chet and I use 2-day sprints in
          Message 4 of 18 , Dec 29 11:45 AM
            Hello, Clinton. On Friday, December 29, 2006, at 1:35:16 PM, you
            wrote:

            > 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?

            The only mention of 2-day sprints that I recall is that Chet and I
            use 2-day sprints in our training / immersion courses.

            Ron Jeffries
            www.XProgramming.com
            A man hears what he wants to hear, and disregards the rest. -- Paul Simon
          • Tobias Fors
            2006/12/29, Clinton Keith : I know these symptoms point to a lack of commitment and ownership on the teams. We customers have
            Message 5 of 18 , Dec 29 1:28 PM
              2006/12/29, Clinton Keith <ckeith@...>:

              "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?"

              Clinton:

              could you say something about how you have approached these issues
              during sprint retrospectives, so far?

              /Tobias

              --
              Tobias: http://www.tobiasfors.se
              Citerus: http://www.citerus.se
              PNEHM!: http://pnehm.citerus.se/
            • Clinton Keith
              ... From Tobias Fors ... Tobias, We used to have a dozen Scrum team Sprint reviews (one for each feature team) which used to take a couple of days. During
              Message 6 of 18 , Dec 29 2:35 PM
                -----Original Message-----
                From Tobias Fors

                > 2006/12/29, Clinton Keith <ckeith@...>:
                > "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?"

                >Clinton:

                > could you say something about how you have approached these issues
                > during sprint retrospectives, so far?

                > /Tobias

                Tobias,

                We used to have a dozen Scrum team Sprint reviews (one for each feature
                team) which used to take a couple of days. During these reviews we
                could go in-depth about each story issue. We found however, that the
                product integration and progress suffered, so we asked for a product
                Sprint review from the entire team. This is a ~2 hour review. During
                this review (120 people present), we address the issues of the product.
                Addressing one team's stories in this setting is not as effective due to
                the size of the crowd.

                Clint
              • Mike Bria
                ... on ... feature ... product. ... to ... Clint -- I find it interesting that you have an all hands on review and you re observing decreased done-ness and
                Message 7 of 18 , Dec 29 3:42 PM
                  --- In scrumdevelopment@yahoogroups.com, "Clinton Keith" <ckeith@...>
                  wrote:
                  >
                  >
                  >
                  > -----Original Message-----
                  > From Tobias Fors
                  >
                  > > 2006/12/29, Clinton Keith ckeith@...:
                  > > "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?"
                  >
                  > >Clinton:
                  >
                  > > could you say something about how you have approached these issues
                  > > during sprint retrospectives, so far?
                  >
                  > > /Tobias
                  >
                  > Tobias,
                  >
                  > We used to have a dozen Scrum team Sprint reviews (one for each
                  feature
                  > team) which used to take a couple of days. During these reviews we
                  > could go in-depth about each story issue. We found however, that the
                  > product integration and progress suffered, so we asked for a product
                  > Sprint review from the entire team. This is a ~2 hour review. During
                  > this review (120 people present), we address the issues of the
                  product.
                  > Addressing one team's stories in this setting is not as effective due
                  to
                  > the size of the crowd.
                  >
                  > Clint
                  >

                  Clint --

                  I find it interesting that you have an "all hands on" review and you're
                  observing decreased "done-ness" and quaility - I would think that might
                  help to improve your teams' desire to deliver high quality software come
                  review time, as they will be showing it not only to a "few in the room",
                  but rather to over a hundred people (read: a subtle, positive dose of
                  "peer incentive"). Why do you think that is?

                  Also, you answered Tobias' question about your 'retrospectives' with a
                  description of your latest 'review' strategy - do you still have a
                  team-specific 'retrospective' session independent of the review?

                  --MB
                • Clinton Keith
                  ... From: Mike Bria Clint -- I find it interesting that you have an all hands on review and you re observing decreased done-ness and quaility - I
                  Message 8 of 18 , Dec 29 4:30 PM
                    -----Original Message-----
                    From: Mike Bria

                    <quote>
                    Clint --

                    I find it interesting that you have an "all hands on" review and you're
                    observing decreased "done-ness" and quaility - I would think that might
                    help to improve your teams' desire to deliver high quality software come
                    review time, as they will be showing it not only to a "few in the room",
                    but rather to over a hundred people (read: a subtle, positive dose of
                    "peer incentive"). Why do you think that is?

                    Also, you answered Tobias' question about your 'retrospectives' with a
                    description of your latest 'review' strategy - do you still have a
                    team-specific 'retrospective' session independent of the review?

                    --MB
                    </quote>

                    Mike,

                    One of the reasons to have the all hands review was to look at the whole
                    product rather than the polished (feature team) parts that didn't quite
                    fit together. It does generate a lot of awareness of the current status
                    of the entire product but it does not increase the full team's
                    _behavior_ to deliver high quality integrated features.

                    A number of things contribute to this:

                    - Feature teams are not completely independent of one another. There
                    are overlaps and occasional hand-off issues.
                    - Separate disciplines (art, design, and programming) do not communicate
                    as effectively as they could. Pipelining and hot potato issues arise
                    (e.g. does a poorly moving character mean bad animation or a bug with
                    the animation technology?)
                    - 120 people on one product/14 teams have more of these issues than 30
                    people/4 teams.

                    With respect to retrospectives, the team retrospectives have tended to
                    focus on the practices of the team. We have encouraged the teams to
                    address product issues as well during these, but they seldom do. The
                    full team (120 people) has tried product retrospectives, but they didn't
                    have a lot of success.

                    Recently due to these issues we have started to have customer reviews of
                    the game _during_ the Sprint. I know this is not an ideal Scrum
                    practice, but the teams have encouraged it. The reviews (twice a week)
                    consist of some customers and senior members of the team playing the
                    game after hours and identifying story related task work that the team
                    might consider "done", but are obviously unpolished. This is a band-aid
                    though. We'd like the teams to learn how to catch these issues on their
                    own (most are obvious).

                    I can't emphasize enough that these issues are usually artistic and
                    subjective. Unit tests don't apply here. They are the kind of things
                    that every one who has ever played a game has seen (characters acting
                    unrealistic, odd physics, etc).

                    Clint
                  • Tamara Sulaiman
                    Why not address the issues directly with individual teams? Schedule separate team retrospectives where you bring up the issues you ve identified and ask
                    Message 9 of 18 , Dec 29 4:44 PM
                      Why not address the issues directly with individual teams? Schedule
                      separate team retrospectives where you bring up the issues you've
                      identified and ask them? (Make sure to bring recent performance
                      stats for the team with you.) Bringing in an experienced, nuetral
                      facilitator would be of benefit here. You're asking them hard
                      questions, and may need to push for some answers.

                      Also, do you have the Sprint Backlog, with estimates of hours
                      remaining and the Sprint Burndown posted prominantly on the wall and
                      updated daily? I've found that once teams can see that, every day,
                      they are more conscious of the impact of dropping and adding items
                      on the sprint backlog, and of driving all stories to completion in
                      the Sprint.

                      As follow up, perhaps you can take a look at what kind of team
                      building efforts can be implemented.(Yeah, I know, it sounds hokey,
                      but often it makes a big difference in building team pride.) Does
                      it make sense to engage in friendly competition with other teams?
                      Does it make more sense to post the stats on Stories Committed to,
                      Stories Completed, and Stories postponed (i.e. "lost") on a sprint
                      by sprint basis up on the wall?

                      Good luck with this. I hope you post and let us know how you are
                      overcoming this obstacle.

                      Regards,

                      Tamara
                    • Clinton Keith
                      ... From: Tamara Sulaiman Why not address the issues directly with individual teams? Schedule separate team retrospectives where you bring up the issues
                      Message 10 of 18 , Dec 29 7:02 PM
                        -----Original Message-----
                        From: Tamara Sulaiman

                        "Why not address the issues directly with individual teams? Schedule
                        separate team retrospectives where you bring up the issues you've
                        identified and ask them? (Make sure to bring recent performance
                        stats for the team with you.) Bringing in an experienced, nuetral
                        facilitator would be of benefit here. You're asking them hard
                        questions, and may need to push for some answers."

                        This was a common practice when we had separate team Sprint reviews. Our experience was that the chemistry of a team either works or doesn't work. If the peer pressure isn't effective, it doesn't seem as if the customer pressure is either.

                        "Also, do you have the Sprint Backlog, with estimates of hours
                        remaining and the Sprint Burndown posted prominantly on the wall and
                        updated daily? I've found that once teams can see that, every day,
                        they are more conscious of the impact of dropping and adding items
                        on the sprint backlog, and of driving all stories to completion in
                        the Sprint."

                        Yes we do. As a customer I would rather have the team nail 50% of the highest priority User Stories in a Sprint than have them think they achieved 100% of them and disappoint us in a review with a "letter of the story, but not spirit". A game development User Story is typically a hard beast to put on a 3x5 card, but most game developers should "know" when it's complete. Even a game player should know if it's really "done" or not.

                        "As follow up, perhaps you can take a look at what kind of team
                        building efforts can be implemented.(Yeah, I know, it sounds hokey,
                        but often it makes a big difference in building team pride.) Does
                        it make sense to engage in friendly competition with other teams?
                        Does it make more sense to post the stats on Stories Committed to,
                        Stories Completed, and Stories postponed (i.e. "lost") on a sprint
                        by sprint basis up on the wall? "

                        This is a good idea...not hokey. On occasion I've wondered if we couldn't, say, drop a problem team off in the woods with three matches and a pile of 3x5 cards and see if they can learn to survive a week. Seriously, this is the kind of thing I'm hoping some of you have used and has worked.

                        "Good luck with this. I hope you post and let us know how you are
                        overcoming this obstacle."

                        Sure will. Most of the teams make this process easy, but if we can find ways to help some of the teams that need it, it'll be much a bigger success.

                        Thanks!
                        Clint
                      • Hubert Smits
                        Clint, Why did you use the title Scrum Illness... for the post? Isn t Scrum working, showing that your teams are bothered by something? That remark doesn t
                        Message 11 of 18 , Dec 29 10:01 PM
                          Clint,

                          Why did you use the title 'Scrum Illness...' for the post? Isn't Scrum working, showing that your teams are bothered by something? That remark doesn't help you much, but may shift your focus to the team and their environment. I've seen all the fun movies from your company (even use them in CSM training, hope you don't mind), but do these movies show the real team spirit? Have you looked outside Scrum, what is happening around the teams. Did the wrong personality enter the team or management somewhere, pressure on the (business) results maybe, is the team unhappy with lack of focus on some part of the system (architecture, refactoring). I can't possibly know from a distance, but wonder if Scrum is the problem.

                          --Hubert

                          On 12/29/06, Clinton Keith <ckeith@...> wrote:

                          -----Original Message-----
                          From:   Tamara Sulaiman

                          "Why not address the issues directly with individual teams?  Schedule
                          separate team retrospectives where you bring up the issues you've
                          identified  and ask them?  (Make sure to bring recent performance
                          stats for the team with you.)   Bringing in an experienced, nuetral
                          facilitator would be of benefit here. You're asking them hard
                          questions, and may need to push for some answers."

                          This was a common practice when we had separate team Sprint reviews.  Our experience was that the chemistry of a team either works or doesn't work.  If the peer pressure isn't effective, it doesn't seem as if the customer pressure is either.

                          "Also,  do you have the Sprint Backlog, with estimates of hours
                          remaining and the Sprint Burndown posted prominantly on the wall and
                          updated daily?  I've found that once teams can see that, every day,
                          they are more conscious of the impact of dropping and adding items
                          on the sprint backlog, and of driving all stories to completion in
                          the Sprint."

                          Yes we do.  As a customer I would rather have the team nail 50% of the highest  priority User Stories in a Sprint than have them think they achieved 100% of them and disappoint us in a review with a "letter of the story, but not spirit".  A game development User Story is typically a hard beast to put on a 3x5 card, but most game developers should "know" when it's complete.  Even a game player should know if it's really "done" or not.

                          "As follow up, perhaps you can take a look at what kind of team
                          building efforts can be implemented.(Yeah, I know, it sounds hokey,
                          but often it makes a big difference in building team pride.)   Does
                          it make sense to engage in friendly competition with other teams?
                          Does it make more sense to post the stats on Stories Committed to,
                          Stories Completed, and Stories postponed (i.e. "lost") on a sprint
                          by sprint basis up on the wall?  "

                          This is a good idea...not hokey.  On occasion I've wondered if we couldn't, say, drop a problem team off in the woods with three matches and a pile of 3x5 cards and see if they can learn to survive a week.  Seriously, this is the kind of thing I'm hoping some of you have used and has worked.

                          "Good luck with this. I hope you post and let us know how you are
                          overcoming this obstacle."

                          Sure will.  Most of the teams make this process easy, but if we can find ways to help some of the teams that need it, it'll be much a bigger success.

                          Thanks!
                          Clint







                          To Post a message, send it to:   scrumdevelopment@...
                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                          Yahoo! Groups Links

                          <*> To visit your group on the web, go to:
                              http://groups.yahoo.com/group/scrumdevelopment/

                          <*> Your email settings:
                              Individual Email | Traditional

                          <*> To change settings online go to:
                              http://groups.yahoo.com/group/scrumdevelopment/join
                              (Yahoo! ID required)

                          <*> To change settings via email:
                              mailto:scrumdevelopment-digest@yahoogroups.com
                              mailto: scrumdevelopment-fullfeatured@yahoogroups.com

                          <*> To unsubscribe from this group, send an email to:
                              scrumdevelopment-unsubscribe@yahoogroups.com

                          <*> Your use of Yahoo! Groups is subject to:
                              http://docs.yahoo.com/info/terms/



                        • Clinton Keith
                          Hubert, It s a fair title. When you are ill, it doesn t mean you re dead, but that you re a little off in some areas. It s just a figure of speech. Scrum
                          Message 12 of 18 , Dec 30 9:32 AM
                            Hubert,

                            It's a fair title. When you are ill, it doesn't mean you're dead, but that you're a little off in some areas. It's just a figure of speech.

                            Scrum isn't a failure. Quoting myself from below:

                            "Most of the teams make this process easy, but if we can find ways to help some of the teams that need it, it'll be much a bigger success."

                            Looking for mentoring, coaching, team building suggestions on improving what works and finding the next gear (oops, another metaphor). Tamara's suggestions were great.

                            Clint


                            -----Original Message-----
                            From: scrumdevelopment@yahoogroups.com on behalf of Hubert Smits
                            Sent: Fri 12/29/2006 10:01 PM
                            To: scrumdevelopment@yahoogroups.com
                            Cc:
                            Subject: Re: [scrumdevelopment] Re: Scrum illness, symptoms and possible treatments

                            Clint,

                            Why did you use the title 'Scrum Illness...' for the post? Isn't Scrum
                            working, showing that your teams are bothered by something? That remark
                            doesn't help you much, but may shift your focus to the team and their
                            environment. I've seen all the fun movies from your company (even use them
                            in CSM training, hope you don't mind), but do these movies show the real
                            team spirit? Have you looked outside Scrum, what is happening around the
                            teams. Did the wrong personality enter the team or management somewhere,
                            pressure on the (business) results maybe, is the team unhappy with lack of
                            focus on some part of the system (architecture, refactoring). I can't
                            possibly know from a distance, but wonder if Scrum is the problem.

                            --Hubert

                            On 12/29/06, Clinton Keith <ckeith@...> wrote:
                            >
                            >
                            > -----Original Message-----
                            > From: Tamara Sulaiman
                            >
                            > "Why not address the issues directly with individual teams? Schedule
                            > separate team retrospectives where you bring up the issues you've
                            > identified and ask them? (Make sure to bring recent performance
                            > stats for the team with you.) Bringing in an experienced, nuetral
                            > facilitator would be of benefit here. You're asking them hard
                            > questions, and may need to push for some answers."
                            >
                            > This was a common practice when we had separate team Sprint reviews. Our
                            > experience was that the chemistry of a team either works or doesn't
                            > work. If the peer pressure isn't effective, it doesn't seem as if the
                            > customer pressure is either.
                            >
                            > "Also, do you have the Sprint Backlog, with estimates of hours
                            > remaining and the Sprint Burndown posted prominantly on the wall and
                            > updated daily? I've found that once teams can see that, every day,
                            > they are more conscious of the impact of dropping and adding items
                            > on the sprint backlog, and of driving all stories to completion in
                            > the Sprint."
                            >
                            > Yes we do. As a customer I would rather have the team nail 50% of the
                            > highest priority User Stories in a Sprint than have them think they
                            > achieved 100% of them and disappoint us in a review with a "letter of the
                            > story, but not spirit". A game development User Story is typically a hard
                            > beast to put on a 3x5 card, but most game developers should "know" when it's
                            > complete. Even a game player should know if it's really "done" or not.
                            >
                            > "As follow up, perhaps you can take a look at what kind of team
                            > building efforts can be implemented.(Yeah, I know, it sounds hokey,
                            > but often it makes a big difference in building team pride.) Does
                            > it make sense to engage in friendly competition with other teams?
                            > Does it make more sense to post the stats on Stories Committed to,
                            > Stories Completed, and Stories postponed (i.e. "lost") on a sprint
                            > by sprint basis up on the wall? "
                            >
                            > This is a good idea...not hokey. On occasion I've wondered if we
                            > couldn't, say, drop a problem team off in the woods with three matches and a
                            > pile of 3x5 cards and see if they can learn to survive a week. Seriously,
                            > this is the kind of thing I'm hoping some of you have used and has worked.
                            >
                            > "Good luck with this. I hope you post and let us know how you are
                            > overcoming this obstacle."
                            >
                            > Sure will. Most of the teams make this process easy, but if we can find
                            > ways to help some of the teams that need it, it'll be much a bigger success.
                            >
                            > Thanks!
                            > Clint
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            > To Post a message, send it to: scrumdevelopment@...
                            > To Unsubscribe, send a blank message to:
                            > scrumdevelopment-unsubscribe@...
                            > Yahoo! Groups Links
                            >
                            >
                            >
                            >
                            >
                          • Chris Leslie
                            Mike Can you expand on the DONE checklist Thanks Chris
                            Message 13 of 18 , Dec 30 10:13 AM
                              Mike

                              Can you expand on the "DONE" checklist

                              Thanks Chris

                              --- In scrumdevelopment@yahoogroups.com, "Mike Bria" <bria526xp@...>
                              wrote:
                              > Do you have a "DONE" checklist?
                            • Mike Bria
                              Sure. Similiar to Clint, my situation is one with many scrums all working on the development of basically one enterprise level product. With the somewhat
                              Message 14 of 18 , Dec 30 10:51 AM
                                Sure. Similiar to Clint, my situation is one with many scrums all
                                working on the development of basically one enterprise level product.
                                With the somewhat increased challenges related to system integration,
                                documentation, integration testing and other product-wide items that
                                exist due in large part to our scale, we've found that it's very helpful
                                to have a documented "DONE" checklist that levels expectations across
                                the teams as to what it means for a Story to be, as you'd guess, "done".
                                In other words, what you need in order to move the card to the "shipped"
                                column on the story board.

                                It's really nothing fancy, it mostly includes the things that seem
                                natural to most, things related to testing, documentation (of the
                                end-user type that is), upgrade support if needed, etc. So for example,
                                it might look like this:

                                Are...
                                - all programmer tests passing?
                                - all customer tests passing?
                                - all function-level integration tests verified?
                                - your related user-docs up to date?
                                - your data upgrade scripts written and tested (if applicable)?
                                - your managers buying you beers for being so dang good?

                                Te real benefits are the things that end up on the list because of
                                something specific to your environment or to a particular release that
                                isn't "standard Scrum/XP business as usual".

                                It's just one more thing posted up in the "open workspace" to help keep
                                everyone thinking about the same general product goals and operating
                                under the same basic standards.

                                Cheers...
                                --MB


                                --- In scrumdevelopment@yahoogroups.com, "Chris Leslie"
                                <chris_leslie01@...> wrote:
                                >
                                > Mike
                                >
                                > Can you expand on the "DONE" checklist
                                >
                                > Thanks Chris
                                >
                                > --- In scrumdevelopment@yahoogroups.com, "Mike Bria" bria526xp@
                                > wrote:
                                > > Do you have a "DONE" checklist?
                                >
                              • Clinton Keith
                                Mike, Who is reponsible for tracking the checklist and communicating to the teams when those things need attention? Clint ... From: Mike Bria Sure. Similiar
                                Message 15 of 18 , Dec 30 12:01 PM
                                  Mike,

                                  Who is reponsible for tracking the checklist and communicating to the teams when those things need attention?

                                  Clint




                                  -----Original Message-----
                                  From: Mike Bria

                                  Sure. Similiar to Clint, my situation is one with many scrums all
                                  working on the development of basically one enterprise level product.
                                  With the somewhat increased challenges related to system integration,
                                  documentation, integration testing and other product-wide items that
                                  exist due in large part to our scale, we've found that it's very helpful
                                  to have a documented "DONE" checklist that levels expectations across
                                  the teams as to what it means for a Story to be, as you'd guess, "done".
                                  In other words, what you need in order to move the card to the "shipped"
                                  column on the story board.

                                  It's really nothing fancy, it mostly includes the things that seem
                                  natural to most, things related to testing, documentation (of the
                                  end-user type that is), upgrade support if needed, etc. So for example,
                                  it might look like this:

                                  Are...
                                  - all programmer tests passing?
                                  - all customer tests passing?
                                  - all function-level integration tests verified?
                                  - your related user-docs up to date?
                                  - your data upgrade scripts written and tested (if applicable)?
                                  - your managers buying you beers for being so dang good?

                                  Te real benefits are the things that end up on the list because of
                                  something specific to your environment or to a particular release that
                                  isn't "standard Scrum/XP business as usual".

                                  It's just one more thing posted up in the "open workspace" to help keep
                                  everyone thinking about the same general product goals and operating
                                  under the same basic standards.

                                  Cheers...
                                  --MB
                                • Mike Bria
                                  Hi Clint -- Well, in most cases its just the team s responsibility to play by the rules . What s often done within the team is a story sale , which means
                                  Message 16 of 18 , Dec 31 4:07 PM
                                    Hi Clint --

                                    Well, in most cases its just the team's responsibility to "play by the
                                    rules".

                                    What's often done within the team is a "story sale", which means this:
                                    As soon as (or before) a story is chosen to be developed by a programmer
                                    (actually, a pair in our case), one non-developer team member (usu. a
                                    business analyst, ui designer, or something of the like) also signs up
                                    as the "buyer". When the pair thinks they're done with the story, they
                                    stand up and say,"hey, story for sale!", at which point everyone around
                                    (at least the "buyer") sits down for a demo where the feature will be
                                    played with (ie, integration testing), programmer/customer tests will be
                                    shown to run, etc. Basically, it's the job of the "buyer" to "track the
                                    checklist" and make sure the t's are crossed. If not, they don't "buy"
                                    the story and the pair goes back to work.

                                    All this said, admittedly, for this to really to be of much help there
                                    needs to be some sense of responsibility within the team. Even in the
                                    absence of that though, at least the checklist provides some common
                                    ground come review time for the Product Owners to look to and somewhat
                                    objectively say hey "we kinda all agreed you would have done x, y, and
                                    z. Can we talk about why z isn't really done?"

                                    One subtle, yet important, side effect (and one that may possibly apply
                                    in you situation) is that this activity helps to bring the "people of
                                    different disciplines" [programmer, "buyer", etc] together to increase
                                    not only the overall communication within the team, but more-so the
                                    sense of "shared responsibility" (collective ownership) to the quality
                                    and completeness of the product being delivered.

                                    Sorry for the windy response, I hope it might help a bit though. Here's
                                    to a spectacular 2007!..
                                    --MB

                                    --- In scrumdevelopment@yahoogroups.com, "Clinton Keith" <ckeith@...>
                                    wrote:
                                    >
                                    > Mike,
                                    >
                                    > Who is reponsible for tracking the checklist and communicating to the
                                    teams when those things need attention?
                                    >
                                    > Clint
                                    >
                                    >
                                    >
                                    >
                                    > -----Original Message-----
                                    > From: Mike Bria
                                    >
                                    > Sure. Similiar to Clint, my situation is one with many scrums all
                                    > working on the development of basically one enterprise level product.
                                    > With the somewhat increased challenges related to system integration,
                                    > documentation, integration testing and other product-wide items that
                                    > exist due in large part to our scale, we've found that it's very
                                    helpful
                                    > to have a documented "DONE" checklist that levels expectations across
                                    > the teams as to what it means for a Story to be, as you'd guess,
                                    "done".
                                    > In other words, what you need in order to move the card to the
                                    "shipped"
                                    > column on the story board.
                                    >
                                    > It's really nothing fancy, it mostly includes the things that seem
                                    > natural to most, things related to testing, documentation (of the
                                    > end-user type that is), upgrade support if needed, etc. So for
                                    example,
                                    > it might look like this:
                                    >
                                    > Are...
                                    > - all programmer tests passing?
                                    > - all customer tests passing?
                                    > - all function-level integration tests verified?
                                    > - your related user-docs up to date?
                                    > - your data upgrade scripts written and tested (if applicable)?
                                    > - your managers buying you beers for being so dang good?
                                    >
                                    > Te real benefits are the things that end up on the list because of
                                    > something specific to your environment or to a particular release that
                                    > isn't "standard Scrum/XP business as usual".
                                    >
                                    > It's just one more thing posted up in the "open workspace" to help
                                    keep
                                    > everyone thinking about the same general product goals and operating
                                    > under the same basic standards.
                                    >
                                    > Cheers...
                                    > --MB
                                    >
                                  • 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 17 of 18 , Jan 3, 2007
                                      --- 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 18 of 18 , Jan 8, 2007

                                        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.