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

Re: [scrumdevelopment] question regarding muliple projects against a small team

Expand Messages
  • clarke_ching@standardlife.com
    Hi Dave, How does your company make money from the work you re doing? Maximising cash flow - long and short term - should be the main consideration. Clarke
    Message 1 of 29 , May 5, 2004
    • 0 Attachment
      Hi Dave,

      How does your company make money from the work you're doing?

      Maximising cash flow - long and short term - should be the main
      consideration.

      Clarke




      Dave Moore
      <jdmoorejr@yaho To: scrumdevelopment@yahoogroups.com
      o.com> cc:
      bcc:
      05/05/2004 Subject: [scrumdevelopment] question regarding muliple projects against a small
      00:45 team
      Please respond
      to
      scrumdevelopmen
      t






      Hey All,

      I'm working at getting my head around how to start using Scrum in our
      little organization. I'm beset by a couple of initial challenges that I'm
      hoping get your feedback/opinions on.

      A little info...
      We are a small custom software development shopt and currently have 5
      developers each either working on a specific project that they "own", or
      bouncing around helping on other projects as their time allows. We have
      about 10 projects that are in maintenance mode, which is to say that the
      backlog would be either periodically empty, or filled with some "hot"
      items... which would hopefully be iterated over in a hurry and the be
      "patched" to the current working code base. Each project is with a
      different customer, represents a different code base, and possibly a
      different technology. We also occassionally take on a new project whose
      typical 1-2 developer lifecyle is anywhere from 3-9 months.

      Some of my confusion/problems.
      I think I could figure out how to form a team, create a backlog, and begin
      a sprint for a new project that has a considerable amount of backlog
      directly related to it.
      But, I can't seem to figure out how to organize the maintenance projects
      into a sprint structure that makes sense. Any ideas?
      Specifically:
      1) Do I create one team and try and divide our time amongst multiple
      projects and consequently multiple (possibly shorter) sprints?
      2) Do I divide the teams up, having one sort of new project team that can
      more closely adhere to the Scrum 30day sprint etc guidelines, and another
      project team that works against several maintenance projects with small
      sprints/quicker releases?
      3) Do something completely different?

      I fear I may not be giving enough information, but I didn't want to make
      this email too long.

      Thank you for your time!
      Dave


      Do you Yahoo!?
      Win a $20,000 Career Makeover at Yahoo! HotJobs

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


      Yahoo! Groups Sponsor




      ADVERTISEMENT








      Yahoo! Groups Links
      To visit your group on the web, go to:
      http://groups.yahoo.com/group/scrumdevelopment/

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

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.





      For more information on Standard Life, visit our website
      http://www.standardlife.co.uk/

      The Standard Life Assurance Company, Standard Life House, 30 Lothian
      Road, Edinburgh EH1 2DH, is registered in Scotland (No. SZ4) and
      regulated by the Financial Services Authority. Tel: 0131 225 2552 -
      calls may be recorded or monitored. This confidential e-mail is for
      the addressee only. If received in error, do not retain/copy/disclose
      it without our consent and please return it to us. We virus scan and
      monitor all e-mails but are not responsible for any damage caused by
      a virus or alteration by a third party after it is sent.
    • Mike Cohn
      Dave- My suggestions are: 1) Consider yourself one team and so have one sprint backlog for the full team. This sounds especially feasible since you say the
      Message 2 of 29 , May 5, 2004
      • 0 Attachment

        Dave—

        My suggestions are:

         

        1) Consider yourself one team and so have one sprint backlog for the full team. This sounds especially feasible since you say the developers are able to help each other some. You may very likely want to maintain multiple product backlogs (one per product, obviously). At the start of each sprint, create the single sprint backlog from the most important items on the associated product backlogs. That may mean taking some in from each product backlog or taking it all from one product backlog sometimes. That will depend on the business.

         

        2) I’d suggest setting your sprint length so that you can be appropriately responsive to customers without having to add all of their new items into current sprints. For example, if you have 2 week sprints you could say “new customer requests go into their product backlogs and get prioritized into the next sprint” and not add customer hot issues into the current sprint. If you do this then the customer will receive a fix within 3 weeks on average. Of course you’ll have a few occasional really hot “showstopper” items that you add to a sprint. Live with those and just let them adjust your velocity down a bit.

         

        3) During the sprint, it’s “we’re all in this together.” Hopefully each developer can see which work he or she can do that will add great value to the organization during the sprint. But, if nothing from my pet project got prioritized in, I am not allowed to work on “my” project and I find other ways to contribute by taking on other sprint backlog items.

         

        Good luck!

         

        --Mike Cohn, Certified ScrumMaster

        Author of User Stories Applied for Agile Software Development

        www.userstories.com

        www.mountaingoatsoftware.com


        From: Dave Moore [mailto:jdmoorejr@...]
        Sent: Tuesday, May 04, 2004 5:46 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] question regarding muliple projects against a small team

         

        Hey All,

         

        I'm working at getting my head around how to start using Scrum in our little organization. I'm beset by a couple of initial challenges that I'm hoping get your feedback/opinions on.

         

        A little info...

        We are a small custom software development shopt and currently have 5 developers each either working on a specific project that they "own", or bouncing around helping on other projects as their time allows.  We have about 10 projects that are in maintenance mode, which is to say that the backlog would be either periodically empty, or filled with some "hot" items... which would hopefully be iterated over in a hurry and the be "patched" to the current working code base.  Each project is with a different customer, represents a different code base, and possibly a different technology.  We also occassionally take on a new project whose typical 1-2 developer lifecyle is anywhere from 3-9 months.

         

        Some of my confusion/problems.

        I think I could figure out how to form a team, create a backlog, and begin a sprint for a new project that has a  considerable amount of backlog directly related to it.

        But, I can't seem to figure out how to organize the maintenance projects into a sprint structure that makes sense. Any ideas?

        Specifically:

        1) Do I create one team and try and divide our time amongst multiple projects and consequently multiple (possibly shorter) sprints?

        2) Do I divide the teams up, having one sort of new project team that can more closely adhere to the Scrum 30day sprint etc guidelines, and another project team that works against several maintenance projects with small sprints/quicker releases?

        3) Do something completely different?

         

        I fear I may not be giving enough information, but I didn't want to make this email too long.

         

        Thank you  for your time!

        Dave


        Do you Yahoo!?
        Win a $20,000 Career Makeover at Yahoo! HotJobs

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




      • Deb
        All good advice. Our team has a similar structure... You might find our spreadsheet informative/useful, esp for planning:
        Message 3 of 29 , May 5, 2004
        • 0 Attachment
          All good advice.
          Our team has a similar structure...
          You might find our spreadsheet informative/useful, esp for planning:
          http://wiki.scrums.org/index.cgi?BacklogSamples
          (might be overkill, but use the features you like)
          deb
          --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
          wrote:
          > Dave-
          >
          > My suggestions are:
          > ...
        • Phlip
          ... Technically, you have one big project, not many small ones. End-users should only see skins over the features they requested. So when any developer hits
          Message 4 of 29 , May 5, 2004
          • 0 Attachment
            Dave Moore wrote:

            > We are a small custom software development shopt and
            > currently have 5
            > developers each either working on a specific project
            > that they "own", or
            > bouncing around helping on other projects as their
            > time allows.

            Technically, you have one big project, not many small
            ones. End-users should only see skins over the
            features they requested. So when any developer hits
            The Test Button, tests should cover all the flavors,
            including the ones in maintenance, not just the flavor
            under development.

            Socially, put all the engineers in the same room.

            These techniques will reinforce collaboration, because
            a rising tide raises all ships.

            > ...Each
            > project is with a
            > different customer, represents a different code
            > base, and possibly a
            > different technology...

            Research the "Software Product Lines" concept by the
            SEI.

            > We also occassionally take on
            > a new project whose
            > typical 1-2 developer lifecyle is anywhere from 3-9
            > months.

            With that system, new projects become customizations
            of the common code base, followed by feature
            enhancements specific to a product.


            =====
            Phlip
            http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces




            __________________________________
            Do you Yahoo!?
            Win a $20,000 Career Makeover at Yahoo! HotJobs
            http://hotjobs.sweepstakes.yahoo.com/careermakeover
          • Dave Moore
            Hey Mike, Deb et. al. Thanks a ton for your comments, I really appreciate it. Regarding 1). I like that approach. I am a little concerned about how to realize
            Message 5 of 29 , May 5, 2004
            • 0 Attachment
              Hey Mike, Deb et. al.
               
              Thanks a ton for your comments, I really appreciate it.
               
              Regarding 1). I like that approach. I am a little concerned about how to realize the colloborative benefits though if the developers are working on the very different projects within the same sprint.  I would imagine that there would be some  backlog items in this "shared" sprint backlog that could facilitate some interaction between developers simply because they stem from the same original product backlog... and hence the same codebase.  I need to think on this a bit more deeply.
               
              Thanks again
              Dave Moore

              Mike Cohn <mike@...> wrote:

              Dave���

              My suggestions are:

               

              1) Consider yourself one team and so have one sprint backlog for the full team. This sounds especially feasible since you say the developers are able to help each other some. You may very likely want to maintain multiple product backlogs (one per product, obviously). At the start of each sprint, create the single sprint backlog from the most important items on the associated product backlogs. That may mean taking some in from each product backlog or taking it all from one product backlog sometimes. That will depend on the business.

               

              2) I���d suggest setting your sprint length so that you can be appropriately responsive to customers without having to add all of their new items into current sprints. For example, if you have 2 week sprints you could say ���new customer requests go into their product backlogs and get prioritized into the next sprint��� and not add customer hot issues into the current sprint. If you do this then the customer will receive a fix within 3 weeks on average. Of course you���ll have a few occasional really hot ���showstopper��� items that you add to a sprint. Live with those and just let them adjust your velocity down a bit.

               

              3) During the sprint, it���s ���we���re all in this together.��� Hopefully each developer can see which work he or she can do that will add great value to the organization during the sprint. But, if nothing from my pet project got prioritized in, I am not allowed to work on ���my��� project and I find other ways to contribute by taking on other sprint backlog items.

               

              Good luck!

               

              --Mike Cohn, Certified ScrumMaster

              Author of User Stories Applied for Agile Software Development

              www.userstories.com

              www.mountaingoatsoftware.com


              From: Dave Moore [mailto:jdmoorejr@...]
              Sent: Tuesday, May 04, 2004 5:46 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] question regarding muliple projects against a small team

               

              Hey All,

               

              I'm working at getting my head around how to start using Scrum in our little organization. I'm beset by a couple of initial challenges that I'm hoping get your feedback/opinions on.

               

              A little info...

              We are a small custom software development shopt and currently have 5 developers each either working on a specific project that they "own", or bouncing around helping on other projects as their time allows.  We have about 10 projects that are in maintenance mode, which is to say that the backlog would be either periodically empty, or filled with some "hot" items... which would hopefully be iterated over in a hurry and the be "patched" to the current working code base.  Each project is with a different customer, represents a different code base, and possibly a different technology.  We also occassionally take on a new project whose typical 1-2 developer lifecyle is anywhere from 3-9 months.

               

              Some of my confusion/problems.

              I think I could figure out how to form a team, create a backlog, and begin a sprint for a new project that has a  considerable amount of backlog directly related to it.

              But, I can't seem to figure out how to organize the maintenance projects into a sprint structure that makes sense. Any ideas?

              Specifically:

              1) Do I create one team and try and divide our time amongst multiple projects and consequently multiple (possibly shorter) sprints?

              2) Do I divide the teams up, having one sort of new project team that can more closely adhere to the Scrum 30day sprint etc guidelines, and another project team that works against several maintenance projects with small sprints/quicker releases?

              3) Do something completely different?

               

              I fear I may not be giving enough information, but I didn't want to make this email too long.

               

              Thank you  for your time!

              Dave


              Do you Yahoo!?
              Win a $20,000 Career Makeover at Yahoo! HotJobs

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






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




              Do you Yahoo!?
              Win a $20,000 Career Makeover at Yahoo! HotJobs

            • Mike Cohn
              Some of the collaborative benefits will come from just discussing the products and prioritizing in the Sprint Planning Meeting. For example, we pull Story A in
              Message 6 of 29 , May 5, 2004
              • 0 Attachment

                Some of the collaborative benefits will come from just discussing the products and prioritizing in the Sprint Planning Meeting. For example, we pull Story A in for your project. During Sprint Planning we discuss it and while breaking it into tasks you say you need to do “xyz.”  When I hear that I tell you that I just finished doing “xyb” and it might help you start. Or, that I need to do “xya” this sprint and their might be something we can solve together.  Even if those opportunities are rare the increased general awareness is useful.

                 

                --Mike Cohn, Certified ScrumMaster

                Author of User Stories Applied for Agile Software Development

                www.userstories.com

                www.mountaingoatsoftware.com


                From: Dave Moore [mailto:jdmoorejr@...]
                Sent: Wednesday, May 05, 2004 7:08 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] question regarding muliple projects against a small team

                 

                Hey Mike, Deb et. al.

                 

                Thanks a ton for your comments, I really appreciate it.

                 

                Regarding 1). I like that approach. I am a little concerned about how to realize the colloborative benefits though if the developers are working on the very different projects within the same sprint.  I would imagine that there would be some  backlog items in this "shared" sprint backlog that could facilitate some interaction between developers simply because they stem from the same original product backlog... and hence the same codebase.  I need to think on this a bit more deeply.

                 

                Thanks again

                Dave Moore

                Mike Cohn <mike@...> wrote:

                Daveb

                My suggestions are:

                 

                1) Consider yourself one team and so have one sprint backlog for the full team. This sounds especially feasible since you say the developers are able to help each other some. You may very likely want to maintain multiple product backlogs (one per product, obviously). At the start of each sprint, create the single sprint backlog from the most important items on the associated product backlogs. That may mean taking some in from each product backlog or taking it all from one product backlog sometimes. That will depend on the business.

                 

                2) Ibd suggest setting your sprint length so that you can be appropriately responsive to customers without having to add all of their new items into current sprints. For example, if you have 2 week sprints you could say bnew customer requests go into their product backlogs and get prioritized into the next sprintb and not add customer hot issues into the current sprint. If you do this then the customer will receive a fix within 3 weeks on average. Of course youbll have a few occasional really hot bshowstopperb items that you add to a sprint. Live with those and just let them adjust your velocity down a bit.

                 

                3) During the sprint, itbs bwebre all in this together.b Hopefully each developer can see which work he or she can do that will add great value to the organization during the sprint. But, if nothing from my pet project got prioritized in, I am not allowed to work on bmyb project and I find other ways to contribute by taking on other sprint backlog items.

                 

                Good luck!

                 

                --Mike Cohn, Certified ScrumMaster

                Author of User Stories Applied for Agile Software Development

                www.userstories.com

                www.mountaingoatsoftware.com


                From: Dave Moore [mailto:jdmoorejr@...]
                Sent: Tuesday, May 04, 2004 5:46 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] question regarding muliple projects against a small team

                 

                Hey All,

                 

                I'm working at getting my head around how to start using Scrum in our little organization. I'm beset by a couple of initial challenges that I'm hoping get your feedback/opinions on.

                 

                A little info...

                We are a small custom software development shopt and currently have 5 developers each either working on a specific project that they "own", or bouncing around helping on other projects as their time allows.  We have about 10 projects that are in maintenance mode, which is to say that the backlog would be either periodically empty, or filled with some "hot" items... which would hopefully be iterated over in a hurry and the be "patched" to the current working code base.  Each project is with a different customer, represents a different code base, and possibly a different technology.  We also occassionally take on a new project whose typical 1-2 developer lifecyle is anywhere from 3-9 months.

                 

                Some of my confusion/problems.

                I think I could figure out how to form a team, create a backlog, and begin a sprint for a new project that has a  considerable amount of backlog directly related to it.

                But, I can't seem to figure out how to organize the maintenance projects into a sprint structure that makes sense. Any ideas?

                Specifically:

                1) Do I create one team and try and divide our time amongst multiple projects and consequently multiple (possibly shorter) sprints?

                2) Do I divide the teams up, having one sort of new project team that can more closely adhere to the Scrum 30day sprint etc guidelines, and another project team that works against several maintenance projects with small sprints/quicker releases?

                3) Do something completely different?

                 

                I fear I may not be giving enough information, but I didn't want to make this email too long.

                 

                Thank you  for your time!

                Dave


                Do you Yahoo!?
                Win a $20,000 Career Makeover at Yahoo! HotJobs

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





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



                Do you Yahoo!?
                Win a $20,000 Career Makeover at Yahoo! HotJobs

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




              • David A Barrett
                Dave, It seems to me that you biggest hurdle is the concept of having each programmer pre-assigned to a particular task and then trying to pull it under a
                Message 7 of 29 , May 6, 2004
                • 0 Attachment
                  Dave,

                  It seems to me that you biggest hurdle is the concept of having each
                  programmer pre-assigned to a particular task and then trying to pull it
                  under a Scrum umbrella.

                  I would suggest you do this; simply collect all of the tasks together,
                  prioritized and call a meeting of the developers. Ask the developers AS A
                  GROUP to commit to completing some quantity of the tasks. After that, let
                  them figure out how they are going to do it. They may decide to work in
                  pairs, they may decide to divide each task into smaller tasks and then
                  divvy them up according to programmer skills. Whatever. The important
                  thing is that they become collectively responsible for all of the tasks in
                  the Sprint backlog.

                  They need to have those three elements: collective control over how much;
                  collective control over how to; and collective responsibility for delivery.


                  Dave Barrett,
                  Lawyers' Professional Indemnity Company
                • Deb
                  With Scrum, don t we always commit, as individuals, to specific work at the beginning of the Sprint? (With the understanding that the team can re-organise this
                  Message 8 of 29 , May 6, 2004
                  • 0 Attachment
                    With Scrum, don't we always commit, as individuals, to specific work
                    at the beginning of the Sprint? (With the understanding that the team
                    can re-organise this as required to meet the Sprint Goal)

                    We work in a similar way to the scenario described... Why is having
                    developers commit to tasks problematic in this scenario? Maybe I
                    missed something...

                    Oh, we did add a "planning worksheet" to our backlog spread to handle
                    workload balancing during Sprint Planning... maybe that's why it
                    still works for us?
                    http://wiki.scrums.org/index.cgi?BacklogSamples

                    Would be interested to hear where you think the problem is.
                    deb

                    --- In scrumdevelopment@yahoogroups.com, David A Barrett
                    <dave.barrett@l...> wrote:
                    > ...
                    > It seems to me that you biggest hurdle is the concept of having each
                    > programmer pre-assigned to a particular task and then trying to
                    pull it
                    > under a Scrum umbrella.
                    > ...
                  • David A Barrett
                    ... Deb, I think this boils down to a chicken and pigs thing, as usual. If you have a set of goals which are individually owned, then basically the entire
                    Message 9 of 29 , May 7, 2004
                    • 0 Attachment
                      >With Scrum, don't we always commit, as individuals, to specific work
                      >at the beginning of the Sprint?

                      Deb,

                      I think this boils down to a chicken and pigs thing, as usual. If you have
                      a set of goals which are individually owned, then basically the entire team
                      becomes a group of chickens for each of goals to which they haven't
                      individually committed.

                      For me, one of the big, big wins we've had with Scrum has been the growth
                      of the team aspect. It took the team members a little while to get used to
                      the idea of not have personal "ownership" of the goals. They do still tend
                      to organize themselves to carve the tasks up between themselves, but their
                      individual commitments to complete the work on time are to the other team
                      members, not to the customers. This seems to be central point of the
                      scrums, the team members are reporting to each other about how they are
                      doing, and they listen to each others reports subjectively from the context
                      of protecting the shared team commitment to the customer. They are happy
                      to reogranize the work, put aside, redefine or modify the appraoch to some
                      goals or whatever it takes to keep things on track without worrying too
                      much about who's actually doing the work (from a point of view that kind of
                      planning).

                      The result, that I've seen, is that the team members are 1000% happier with
                      the way that things work. They are involved at all levels of planning,
                      designing, organizing, programming and testing and problem solving. They
                      make their own (joint) decisions and they are all pumped up about all the
                      stuff that they are producing, even if they as individuals had very little
                      to do with a particular deliverable. At the same time, the stuff they are
                      producing is spectacular, and it is so tightly focused on *actual* customer
                      needs its a little scary.

                      I've looked at your spreadsheet, and I see how it tends to put the focus on
                      the individual team members' performance. Personally, I think that is
                      unnecessary. With shared commitments, the team tends to tacitly put
                      pressure on each team member to excel, and the only real progress indicator
                      that matters is combined burndown for all of the tasks. If the burndown
                      doesn't look good, then it is the team's problem to solve and, in my short
                      experience, they will solve it.

                      One last thing. I noticed that a lot of the stuff that Ken talked about in
                      the ScrumMaster course was very similar to the stuff talked about in the
                      classic book, "The One Minute Manager". I've been on a couple of
                      leadership/mentoring courses since then, and I've been surprised out how
                      nicely these concepts dovetail with the Scrum philosophy on teamwork.

                      Dave Barrett,
                      Lawyers' Professional Indemnity Company
                    • w6rabbit
                      ... Deb, I really like your spreadsheet. Looks like it will be very useful. Where would you like questions regarding it to be posted? Thanks, Brad.
                      Message 10 of 29 , May 7, 2004
                      • 0 Attachment
                        --- In scrumdevelopment@yahoogroups.com, "Deb" <deborah@h...> wrote:
                        > You might find our spreadsheet informative/useful, esp for
                        planning:
                        > http://wiki.scrums.org/index.cgi?BacklogSamples
                        > (might be overkill, but use the features you like)
                        > deb

                        Deb,

                        I really like your spreadsheet.
                        Looks like it will be very useful.

                        Where would you like questions regarding it
                        to be posted?

                        Thanks,
                        Brad.
                      • Dave Moore
                        I agree, thanks for posting it! ... Deb, I really like your spreadsheet. Looks like it will be very useful. Where would you like questions regarding it to be
                        Message 11 of 29 , May 7, 2004
                        • 0 Attachment
                          I agree, thanks for posting it!

                          w6rabbit <bwhite@...> wrote:
                          --- In scrumdevelopment@yahoogroups.com, "Deb" <deborah@h...> wrote:
                          > You might find our spreadsheet informative/useful, esp for
                          planning:
                          > http://wiki.scrums.org/index.cgi?BacklogSamples
                          > (might be overkill, but use the features you like)
                          > deb

                          Deb,

                          I really like your spreadsheet.
                          Looks like it will be very useful.

                          Where would you like questions regarding it
                          to be posted?

                          Thanks,
                          Brad.



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




                          Do you Yahoo!?
                          Win a $20,000 Career Makeover at Yahoo! HotJobs
                        • Deb
                          Discussion on my sample ScrumBacklog spreadsheet is welcome at the bottom on the wiki page - I monitor the wiki s RSS feed, so I ll be notified if you change a
                          Message 12 of 29 , May 8, 2004
                          • 0 Attachment
                            Discussion on my sample ScrumBacklog spreadsheet is welcome at the
                            bottom on the wiki page - I monitor the wiki's RSS feed, so I'll be
                            notified if you change a page.
                            http://wiki.scrums.org/index.cgi?BacklogSamples

                            It would be good to know about what kind of tweaks you discover are
                            useful, too. :-)

                            Anyone who has a useful sample: feel free to update the page with
                            info about your sample, and email me the actual sample or image(s) of
                            it, which I can upload to the wiki for you.
                          • David A Barrett
                            Ok, so now I m a little worried. The more I think about it, the less comfortable I am with Deb s spreadsheet and the way it focuses on the individuals
                            Message 13 of 29 , May 10, 2004
                            • 0 Attachment
                              Ok, so now I'm a little worried.

                              The more I think about it, the less comfortable I am with Deb's spreadsheet
                              and the way it focuses on the individuals' performance. This clashes
                              totally with what I perceived to be key component of the Scrum methodology;
                              the team aspect.

                              In the ScrumMaster course, Ken made a point about ensuring that the daily
                              scrums were about the team members reporting to each other. He advised
                              doing things like avoiding eye contact with the team members in order to
                              avoid having them report *to* the scrummaster. I can think of numerous
                              other examples where he went out of his way to stress that the
                              scrummaster's role was *not* to organize and control the team's activities.
                              The chicken and pig concept, which seems to be a pillar of the methodology,
                              puts the emphasis on the team and shared goals.

                              So why am I worried? Well Deb puts up the spreadsheet which appears to
                              shift the focus from teamwork back onto individually managed people with
                              individual goals which are (probably) assigned by management, and the next
                              thing we see on this list are a whole bunch of posts from people saying
                              they think this is really cool. So then I wonder if people are looking at
                              this and saying to themselves, "Hey, this is the missing link! I can
                              implement Scrum while still keeping my subordinates directly accountable to
                              myself, and I can maintain control on an individual basis".

                              Now the last thing I want to be is dogmatic, but I'm thinking that if you
                              are managing your team with this spreadsheet (and the management style that
                              it implies) then it's not Scrum anymore. It may be effective, it may
                              support iterative and incemental, but it's not Scrum. If it's not Scrum,
                              what does that mean?

                              Perhaps if Mike or Ken could step in at this time and express an opinion it
                              would help to clarify this for me.


                              Dave Barrett,
                              Lawyers' Professional Indemnity Company
                            • Ken Schwaber
                              I haven t looked at the product, so this is a general comment. The sprint backlog is a compromise between management (who is anxious and wants to see
                              Message 14 of 29 , May 10, 2004
                              • 0 Attachment
                                I haven't looked at the product, so this is a general comment. The sprint backlog is a compromise between management (who is anxious and wants to see something, particularly the first sprint) and the team (that needs to manage itself). The sprint backlog sits right between, with team members managing their own work and the spreadsheet reflecting the results and miraculously being demonstrable to management. However, the team manages its own work and any focus on individuals or estimate to actuals removes to focus of self-organizing teams. I continue to be nervous about tools because they implement one procedural vision of the way work should be done, hence limiting self-organization and agility. That said, tools can be helpful.
                                Ken
                                >
                                > From: David A Barrett <dave.barrett@...>
                                > Date: 2004/05/10 Mon AM 09:17:01 CDT
                                > To: scrumdevelopment@yahoogroups.com
                                > Subject: [scrumdevelopment] Re: question regarding muliple projects against a small team
                                >
                                >
                                >
                                >
                                >
                                > Ok, so now I'm a little worried.
                                >
                                > The more I think about it, the less comfortable I am with Deb's spreadsheet
                                > and the way it focuses on the individuals' performance. This clashes
                                > totally with what I perceived to be key component of the Scrum methodology;
                                > the team aspect.
                                >
                                > In the ScrumMaster course, Ken made a point about ensuring that the daily
                                > scrums were about the team members reporting to each other. He advised
                                > doing things like avoiding eye contact with the team members in order to
                                > avoid having them report *to* the scrummaster. I can think of numerous
                                > other examples where he went out of his way to stress that the
                                > scrummaster's role was *not* to organize and control the team's activities.
                                > The chicken and pig concept, which seems to be a pillar of the methodology,
                                > puts the emphasis on the team and shared goals.
                                >
                                > So why am I worried? Well Deb puts up the spreadsheet which appears to
                                > shift the focus from teamwork back onto individually managed people with
                                > individual goals which are (probably) assigned by management, and the next
                                > thing we see on this list are a whole bunch of posts from people saying
                                > they think this is really cool. So then I wonder if people are looking at
                                > this and saying to themselves, "Hey, this is the missing link! I can
                                > implement Scrum while still keeping my subordinates directly accountable to
                                > myself, and I can maintain control on an individual basis".
                                >
                                > Now the last thing I want to be is dogmatic, but I'm thinking that if you
                                > are managing your team with this spreadsheet (and the management style that
                                > it implies) then it's not Scrum anymore. It may be effective, it may
                                > support iterative and incemental, but it's not Scrum. If it's not Scrum,
                                > what does that mean?
                                >
                                > Perhaps if Mike or Ken could step in at this time and express an opinion it
                                > would help to clarify this for me.
                                >
                                >
                                > Dave Barrett,
                                > Lawyers' Professional Indemnity Company
                                >
                                >
                                >
                                >
                                > To Post a message, send it to: scrumdevelopment@...
                                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                > Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >
                                >
                              • Mike Cohn
                                Hi Dave-- I m the wrong Mike but I have similar concerns as you with tracking individual burndown. Deb s spreadsheet did have a disclaimer on it about
                                Message 15 of 29 , May 10, 2004
                                • 0 Attachment
                                  Hi Dave--
                                  I'm the "wrong Mike" but I have similar concerns as you with tracking
                                  individual burndown. Deb's spreadsheet did have a disclaimer on it about
                                  individual numbers not being comparable. But, the need for disclaimer is
                                  evidence that there's risk in tracking things this way.

                                  I used to use an Excel sheet to track burndown and I had little summary
                                  columns where I could see how much each person still had left to do that
                                  they'd planned to do. This would look something like:

                                  Hours HoursLeftInSprint %
                                  Tod 40 60 67%
                                  Mark 60 50 120%

                                  The idea was that each team member could look at the number of hours he or
                                  she had left in the sprint (these could vary based on vacation, etc.), how
                                  many hours they had signed up for that were still to do and get a feel for
                                  whether they'd finish. Clearly in the above Mark is overcommitted. Tod is
                                  probably about right on.

                                  What I found with this is that it really didn't help individuals know if
                                  they were overcommitted--they had a feel for that faster than Excel could do
                                  the math. And, individuals signing up for tasks was a bad idea in general.
                                  What I've been doing the last couple of years is the team commits
                                  collectively to an amount of work. No one signs up for anything. As
                                  individuals need tasks, they take them off the board. There's no signing up
                                  in advance. We don't have a rule about "no more than 2 tasks at a time" but
                                  I try to discourage anyone taking more than that at once. Sometimes it
                                  happens but always with good reasons. (Example: One of my programmers is
                                  adding optimistic locking to a series of screens. Each screen takes 1-2
                                  hours. He signed up last week for 4-5 of them at once since it was still
                                  less than a day of work.)

                                  --Mike Cohn
                                  Author of User Stories Applied for Agile Software Development
                                  www.userstories.com

                                  -----Original Message-----
                                  From: David A Barrett [mailto:dave.barrett@...]
                                  Sent: Monday, May 10, 2004 8:17 AM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: [scrumdevelopment] Re: question regarding muliple projects against
                                  a small team





                                  Ok, so now I'm a little worried.

                                  The more I think about it, the less comfortable I am with Deb's spreadsheet
                                  and the way it focuses on the individuals' performance. This clashes
                                  totally with what I perceived to be key component of the Scrum methodology;
                                  the team aspect.

                                  In the ScrumMaster course, Ken made a point about ensuring that the daily
                                  scrums were about the team members reporting to each other. He advised
                                  doing things like avoiding eye contact with the team members in order to
                                  avoid having them report *to* the scrummaster. I can think of numerous
                                  other examples where he went out of his way to stress that the
                                  scrummaster's role was *not* to organize and control the team's activities.
                                  The chicken and pig concept, which seems to be a pillar of the methodology,
                                  puts the emphasis on the team and shared goals.

                                  So why am I worried? Well Deb puts up the spreadsheet which appears to
                                  shift the focus from teamwork back onto individually managed people with
                                  individual goals which are (probably) assigned by management, and the next
                                  thing we see on this list are a whole bunch of posts from people saying
                                  they think this is really cool. So then I wonder if people are looking at
                                  this and saying to themselves, "Hey, this is the missing link! I can
                                  implement Scrum while still keeping my subordinates directly accountable to
                                  myself, and I can maintain control on an individual basis".

                                  Now the last thing I want to be is dogmatic, but I'm thinking that if you
                                  are managing your team with this spreadsheet (and the management style that
                                  it implies) then it's not Scrum anymore. It may be effective, it may
                                  support iterative and incemental, but it's not Scrum. If it's not Scrum,
                                  what does that mean?

                                  Perhaps if Mike or Ken could step in at this time and express an opinion it
                                  would help to clarify this for me.


                                  Dave Barrett,
                                  Lawyers' Professional Indemnity Company




                                  To Post a message, send it to: scrumdevelopment@...
                                  To Unsubscribe, send a blank message to:
                                  scrumdevelopment-unsubscribe@...
                                  Yahoo! Groups Links
                                • Michael D. Ivey
                                  ... I think I see part of the problem. You ve made an assumption here: individual goals which are (probably) assigned by management If you drop assigned by
                                  Message 16 of 29 , May 10, 2004
                                  • 0 Attachment
                                    On Mon, May 10, 2004 at 10:17:01AM -0400, David A Barrett wrote:
                                    > So why am I worried? Well Deb puts up the spreadsheet which appears
                                    > to shift the focus from teamwork back onto individually managed people
                                    > with individual goals which are (probably) assigned by management, and
                                    > the next thing we see on this list are a whole bunch of posts from
                                    > people saying they think this is really cool. So then I wonder if
                                    > people are looking at this and saying to themselves, "Hey, this is the
                                    > missing link! I can implement Scrum while still keeping my
                                    > subordinates directly accountable to myself, and I can maintain
                                    > control on an individual basis".

                                    I think I see part of the problem. You've made an assumption here:
                                    "individual goals which are (probably) assigned by management"

                                    If you drop "assigned by management" from your thinking, does the
                                    spreadsheet become more useful?

                                    In my experiences with Scrum, the team commits collectively to a goal,
                                    but will naturally divide the work among themselves. This spreadsheet
                                    is one way to do that. The task assignments are fluid and
                                    team-determined, but they still exist.

                                    The ScrumMaster does /not/ make assignments, but merely (?) facilitates
                                    the process, helping the team manage themselves.

                                    Does that help?

                                    --
                                    Michael D. Ivey, Senior Partner | mdi@...
                                    Ivey & Brown, Inc. | http://www.iveyandbrown.com
                                    Process and Technology Consulting | (866) 235-7764
                                  • David A Barrett
                                    ... I wondered if anyone would latch onto that. It s a valid point. First, I figure anyone who s going to go to the trouble of maintaining individual
                                    Message 17 of 29 , May 10, 2004
                                    • 0 Attachment
                                      >I think I see part of the problem. You've made an assumption here:
                                      >"individual goals which are (probably) assigned by management"

                                      I wondered if anyone would latch onto that. It's a valid point.

                                      First, I figure anyone who's going to go to the trouble of maintaining
                                      individual burndowns is probably enough of a control freak to assign the
                                      tasks as well. I guess what I'm saying is that I don't think it's a shakey
                                      assumption, so I'm not that willing to toss it out. Even if you do assume
                                      that the team sets its own goals, this kind of tracking seems specifically
                                      aimed at preventing the team from acting as a team.

                                      Second, what's the purpose of such tracking? I see three good reasons for
                                      maintaining a team burndown graph: 1. To prove to management that you've
                                      got things under control; 2. To assist the team in knowing if they are on
                                      track for their sprint goals; 3. As a learning aid for the team when
                                      setting later sprint backlog lists. These all have value. I don't see how
                                      the individual burn down graphs are going to add any extra value.

                                      Lastly - and I hesitate to mention this one - I wonder how someone's use of
                                      such graphs reflects on the their understanding of Scrum. To me (and I
                                      have to keep on saying that over and over again, "To me"), the idea of
                                      Scrum is point the team in the right direction, wind them up, let them go
                                      and get out of the way. As Reg Braithwaite-Lee said (I'm paraphrasing
                                      now), "Simply bring together talented people and remove the obstructions
                                      for them".


                                      Dave Barrett,
                                      Lawyers' Professional Indemnity Company
                                    • Mike Cohn
                                      Dave-- I think it s a bit of a stretch to question someone s understanding of Scrum because they want to track individual burndown. Like I mentioned in another
                                      Message 18 of 29 , May 10, 2004
                                      • 0 Attachment
                                        Dave--
                                        I think it's a bit of a stretch to question someone's understanding of Scrum
                                        because they want to track individual burndown.

                                        Like I mentioned in another post, I tried tracking individual burndown but I
                                        did it to help programmers who were overcommitting (especially at the start)
                                        to see that they were overcommitting. They signed up for tasks. I assigned
                                        nothing. This was one of those teams that would look at a schedule and
                                        think, "Hmm, 40 hours this week, let's sign up for 3000 hours of coding. I
                                        think we can do that." I just wanted them to see--in a single number--that
                                        they were overcommitting. The individual burndown graphs I did *should have*
                                        had value in this direction but even confronted with such a number this team
                                        kept thinking they could make it. (They never would.)

                                        From what I've seen of Deb's other posts she has a very good understanding
                                        of Scrum and I suspect her individual burndown tracking is presented to them
                                        for their benefit, not hers.

                                        --Mike Cohn
                                        Author of User Stories Applied for Agile Software Development
                                        www.userstories.com


                                        -----Original Message-----
                                        From: David A Barrett [mailto:dave.barrett@...]
                                        Sent: Monday, May 10, 2004 9:59 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: [scrumdevelopment] Re: question regarding muliple projects against
                                        a small team





                                        >I think I see part of the problem. You've made an assumption here:
                                        >"individual goals which are (probably) assigned by management"

                                        I wondered if anyone would latch onto that. It's a valid point.

                                        First, I figure anyone who's going to go to the trouble of maintaining
                                        individual burndowns is probably enough of a control freak to assign the
                                        tasks as well. I guess what I'm saying is that I don't think it's a shakey
                                        assumption, so I'm not that willing to toss it out. Even if you do assume
                                        that the team sets its own goals, this kind of tracking seems specifically
                                        aimed at preventing the team from acting as a team.

                                        Second, what's the purpose of such tracking? I see three good reasons for
                                        maintaining a team burndown graph: 1. To prove to management that you've
                                        got things under control; 2. To assist the team in knowing if they are on
                                        track for their sprint goals; 3. As a learning aid for the team when
                                        setting later sprint backlog lists. These all have value. I don't see how
                                        the individual burn down graphs are going to add any extra value.

                                        Lastly - and I hesitate to mention this one - I wonder how someone's use of
                                        such graphs reflects on the their understanding of Scrum. To me (and I
                                        have to keep on saying that over and over again, "To me"), the idea of
                                        Scrum is point the team in the right direction, wind them up, let them go
                                        and get out of the way. As Reg Braithwaite-Lee said (I'm paraphrasing
                                        now), "Simply bring together talented people and remove the obstructions
                                        for them".


                                        Dave Barrett,
                                        Lawyers' Professional Indemnity Company




                                        To Post a message, send it to: scrumdevelopment@...
                                        To Unsubscribe, send a blank message to:
                                        scrumdevelopment-unsubscribe@...
                                        Yahoo! Groups Links
                                      • Deb
                                        There s some interesting discussion on the individual burndown feature of our spreadsheet here... I m going in to a meeting right now, but I can give you
                                        Message 19 of 29 , May 10, 2004
                                        • 0 Attachment
                                          There's some interesting discussion on the "individual burndown"
                                          feature of our spreadsheet here... I'm going in to a meeting right
                                          now, but I can give you some context when I get back later.

                                          For now:
                                          a) team decides who does what, breaks Product Backlog items down into
                                          tasks and estimates them. Only the team does this - scrummaster plays
                                          scribe.
                                          b) this created as a local response to culture change issues, and
                                          operates within a given context. (Seems related to comment by Ken in
                                          this thread.)

                                          more later
                                          :-)
                                          deb

                                          --- In scrumdevelopment@yahoogroups.com, David A Barrett
                                          <dave.barrett@l...> wrote:
                                          >
                                          >
                                          >
                                          >
                                          > Ok, so now I'm a little worried.
                                          >
                                          > The more I think about it, the less comfortable I am with Deb's
                                          spreadsheet
                                          > and the way it focuses on the individuals' performance...
                                        • Deb
                                          I guess I m responding to different aspects of this post in a couple of sub-threads... Dave, just to be clear, how do you see the Individual Burndown as a way
                                          Message 20 of 29 , May 12, 2004
                                          • 0 Attachment
                                            I guess I'm responding to different aspects of this post in a couple
                                            of sub-threads...

                                            Dave, just to be clear, how do you see the Individual Burndown as a
                                            way to track performance? It seems to be missing so much information
                                            (that Scrum does not record) that it could only serve
                                            to /misinterpret/ performance, and it seems to me that the people
                                            using it would know that... but maybe you are seeing something
                                            different?

                                            deb

                                            PS: people are not necessarily responding to the Individual Burndown
                                            aspect, are they? There are a bunch of worksheets there... My
                                            assumption is: if you are using XP then the Indiv Burndown is
                                            probably extraneous.



                                            --- In scrumdevelopment@yahoogroups.com, David A Barrett
                                            <dave.barrett@l...> wrote:
                                            >
                                            >
                                            >
                                            >
                                            > Ok, so now I'm a little worried.
                                            >
                                            > The more I think about it, the less comfortable I am with Deb's
                                            spreadsheet
                                            > and the way it focuses on the individuals' performance. This
                                            clashes
                                            > totally with what I perceived to be key component of the Scrum
                                            methodology;
                                            > the team aspect.
                                            >
                                            > In the ScrumMaster course, Ken made a point about ensuring that the
                                            daily
                                            > scrums were about the team members reporting to each other. He
                                            advised
                                            > doing things like avoiding eye contact with the team members in
                                            order to
                                            > avoid having them report *to* the scrummaster. I can think of
                                            numerous
                                            > other examples where he went out of his way to stress that the
                                            > scrummaster's role was *not* to organize and control the team's
                                            activities.
                                            > The chicken and pig concept, which seems to be a pillar of the
                                            methodology,
                                            > puts the emphasis on the team and shared goals.
                                            >
                                            > So why am I worried? Well Deb puts up the spreadsheet which
                                            appears to
                                            > shift the focus from teamwork back onto individually managed people
                                            with
                                            > individual goals which are (probably) assigned by management, and
                                            the next
                                            > thing we see on this list are a whole bunch of posts from people
                                            saying
                                            > they think this is really cool. So then I wonder if people are
                                            looking at
                                            > this and saying to themselves, "Hey, this is the missing link! I
                                            can
                                            > implement Scrum while still keeping my subordinates directly
                                            accountable to
                                            > myself, and I can maintain control on an individual basis".
                                            >
                                            > Now the last thing I want to be is dogmatic, but I'm thinking that
                                            if you
                                            > are managing your team with this spreadsheet (and the management
                                            style that
                                            > it implies) then it's not Scrum anymore. It may be effective, it
                                            may
                                            > support iterative and incemental, but it's not Scrum. If it's not
                                            Scrum,
                                            > what does that mean?
                                            >
                                            > Perhaps if Mike or Ken could step in at this time and express an
                                            opinion it
                                            > would help to clarify this for me.
                                            >
                                            >
                                            > Dave Barrett,
                                            > Lawyers' Professional Indemnity Company
                                          • Maurizio Tripi
                                            Dear Deborah, your individual burndown is what I called the personal sprint backlog & burndown graph, and was one of the experiments I tried 3 years ago
                                            Message 21 of 29 , May 13, 2004
                                            • 0 Attachment
                                              Dear Deborah,
                                              your individual burndown is what I called the personal sprint backlog &
                                              burndown graph,
                                              and was one of the experiments I tried 3 years ago during a project. I
                                              can't say it is a good
                                              approach in general. I tried this technique because that team found hard
                                              to self-organize.
                                              The team was not as much collaborative as I was willing, their
                                              estimations were oscillating
                                              and they didn't reach a good rhythm. Hence I tried to help them with
                                              the personal sprint backlog.
                                              I tried to divide the product backlog per person to find the problem but
                                              things didn't get better.
                                              I managed the team, organization didn't emerged and in later sprints the
                                              team was not more
                                              cohesive and the productivity was "normal". I think I missed the point:
                                              a lack of values can't be
                                              avoided introducing new practices, this led to a sort of control that
                                              hindered collaboration.

                                              I think the team should collaborate as it was one single organism. To
                                              show the difference between
                                              productivity (or other metrics) don't help the team to be more cohesive.
                                              They know what is going on. We, as ScrumMasters, should help them to
                                              work better and not to
                                              show them they don't do it, (imho). This is the hard part of the Scrum
                                              method, the tacit knowledge that
                                              Ken cannot to teach us at the certification classes or in his books.

                                              What do you think about it?

                                              Maurizio


                                              Deb ha scritto:

                                              > I guess I'm responding to different aspects of this post in a couple
                                              > of sub-threads...
                                              >
                                              > Dave, just to be clear, how do you see the Individual Burndown as a
                                              > way to track performance? It seems to be missing so much information
                                              > (that Scrum does not record) that it could only serve
                                              > to /misinterpret/ performance, and it seems to me that the people
                                              > using it would know that... but maybe you are seeing something
                                              > different?
                                              >
                                              > deb
                                              >
                                              > PS: people are not necessarily responding to the Individual Burndown
                                              > aspect, are they? There are a bunch of worksheets there... My
                                              > assumption is: if you are using XP then the Indiv Burndown is
                                              > probably extraneous.
                                              >
                                              >
                                              >
                                              > --- In scrumdevelopment@yahoogroups.com, David A Barrett
                                              > <dave.barrett@l...> wrote:
                                              > >
                                              > >
                                              > >
                                              > >
                                              > > Ok, so now I'm a little worried.
                                              > >
                                              > > The more I think about it, the less comfortable I am with Deb's
                                              > spreadsheet
                                              > > and the way it focuses on the individuals' performance. This
                                              > clashes
                                              > > totally with what I perceived to be key component of the Scrum
                                              > methodology;
                                              > > the team aspect.
                                              > >
                                              > > In the ScrumMaster course, Ken made a point about ensuring that the
                                              > daily
                                              > > scrums were about the team members reporting to each other. He
                                              > advised
                                              > > doing things like avoiding eye contact with the team members in
                                              > order to
                                              > > avoid having them report *to* the scrummaster. I can think of
                                              > numerous
                                              > > other examples where he went out of his way to stress that the
                                              > > scrummaster's role was *not* to organize and control the team's
                                              > activities.
                                              > > The chicken and pig concept, which seems to be a pillar of the
                                              > methodology,
                                              > > puts the emphasis on the team and shared goals.
                                              > >
                                              > > So why am I worried? Well Deb puts up the spreadsheet which
                                              > appears to
                                              > > shift the focus from teamwork back onto individually managed people
                                              > with
                                              > > individual goals which are (probably) assigned by management, and
                                              > the next
                                              > > thing we see on this list are a whole bunch of posts from people
                                              > saying
                                              > > they think this is really cool. So then I wonder if people are
                                              > looking at
                                              > > this and saying to themselves, "Hey, this is the missing link! I
                                              > can
                                              > > implement Scrum while still keeping my subordinates directly
                                              > accountable to
                                              > > myself, and I can maintain control on an individual basis".
                                              > >
                                              > > Now the last thing I want to be is dogmatic, but I'm thinking that
                                              > if you
                                              > > are managing your team with this spreadsheet (and the management
                                              > style that
                                              > > it implies) then it's not Scrum anymore. It may be effective, it
                                              > may
                                              > > support iterative and incemental, but it's not Scrum. If it's not
                                              > Scrum,
                                              > > what does that mean?
                                              > >
                                              > > Perhaps if Mike or Ken could step in at this time and express an
                                              > opinion it
                                              > > would help to clarify this for me.
                                              > >
                                              > >
                                              > > Dave Barrett,
                                              > > Lawyers' Professional Indemnity Company
                                              >
                                              >
                                              >
                                              > To Post a message, send it to: scrumdevelopment@...
                                              > To Unsubscribe, send a blank message to:
                                              > scrumdevelopment-unsubscribe@...
                                              >
                                              >
                                              > *Yahoo! Groups Sponsor*
                                              > ADVERTISEMENT
                                              > <http://rd.yahoo.com/SIG=129ul4nbh/M=295196.4901138.6071305.3001176/D=groups/S=1707209021:HM/EXP=1084466640/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com>
                                              >
                                              >
                                              >
                                              > ------------------------------------------------------------------------
                                              > *Yahoo! Groups Links*
                                              >
                                              > * To visit your group on the web, go to:
                                              > http://groups.yahoo.com/group/scrumdevelopment/
                                              >
                                              > * To unsubscribe from this group, send an email to:
                                              > scrumdevelopment-unsubscribe@yahoogroups.com
                                              > <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                                              >
                                              > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                                              > Service <http://docs.yahoo.com/info/terms/>.
                                              >
                                              >
                                            • Marco Abis
                                              Maurizio, ... this make a lot of sense to me! Marco Abis http://agilemovement.it - Italian Agile Movement http://www.agilityspi.com - Agility SPI :: Software
                                              Message 22 of 29 , May 13, 2004
                                              • 0 Attachment
                                                Maurizio,

                                                >a lack of values can't be avoided introducing new practices

                                                this make a lot of sense to me!


                                                Marco Abis
                                                http://agilemovement.it - Italian Agile Movement
                                                http://www.agilityspi.com - Agility SPI :: Software Process Improvement
                                              • Deb
                                                makes sense to me too. however, still leaves the problem of load balancing when there are specialists on the team... I m still mulling this over. deb ...
                                                Message 23 of 29 , May 13, 2004
                                                • 0 Attachment
                                                  makes sense to me too.
                                                  however, still leaves the problem of load balancing when there are
                                                  specialists on the team...

                                                  I'm still mulling this over.
                                                  deb

                                                  --- In scrumdevelopment@yahoogroups.com, Marco Abis <abis@a...> wrote:
                                                  > Maurizio,
                                                  >
                                                  > >a lack of values can't be avoided introducing new practices
                                                  >
                                                  > this make a lot of sense to me!
                                                  >
                                                  >
                                                  > Marco Abis
                                                  > http://agilemovement.it - Italian Agile Movement
                                                  > http://www.agilityspi.com - Agility SPI :: Software Process
                                                  Improvement
                                                • David A Barrett
                                                  ... What I meant by performance was the individuals contribution to the group burndown. ... I can t say it any better. Deb, You cite a case where your own
                                                  Message 24 of 29 , May 14, 2004
                                                  • 0 Attachment
                                                    From Deb:

                                                    > Dave, just to be clear, how do you see the Individual Burndown as a
                                                    > way to track performance? It seems to be missing so much information
                                                    > (that Scrum does not record) that it could only serve
                                                    > to /misinterpret/ performance

                                                    What I meant by "performance" was the individuals' contribution to the
                                                    group burndown.

                                                    From Maurizio:

                                                    >I think the team should collaborate as it was one single organism.

                                                    I can't say it any better.

                                                    Deb,

                                                    You cite a case where your own individual burndown helped you to do better.
                                                    Although I was really only being cheeky when I said, "Now, if the team
                                                    decides to track individual burndowns, that would be a different
                                                    matter...", I guess this really does fall into that category.

                                                    Could explain what the expected benefits or goals are from tracking
                                                    individual burndowns?

                                                    As to load balancing when there are specialists on a team. I have two
                                                    thoughts on this. The first is what Ken always stresses, that the pigs are
                                                    always committed to the team goals and no one says, "That's not my area so
                                                    I'm not going to help". We often have tasks which require some involvement
                                                    from a web designer, but we refuse to make him part of the team because his
                                                    skill set is too narrow to participate fully in the team goals as a pig.
                                                    We treat him as a resource, and the team's Business Analyst is usually the
                                                    one who keeps track of how he's doing and reports back to the team on his
                                                    progress. The Business Analyst, by the way, is the only team member who
                                                    can't program but she's also usually the only team member who actively
                                                    participates in every singe Sprint Backlog item each Sprint. Each of the
                                                    programmers have areas that only they can effectively work in, but these
                                                    areas are often only a small part of the overall work for a sprint. The
                                                    specialist parts of the specialist tasks are done (by necessity) by the
                                                    specialists, but other than that it gets spread around.

                                                    My second thought on load balancing is that it isn't up to the Scrum Master
                                                    to come up with a solution. It is the team's problem, and the team needs
                                                    to find a solution. Let the customer pick the goals, and let the team
                                                    figure out how to meet them. Even specialist based goals are going to have
                                                    areas, such as documentation and testing, which can be done by other people
                                                    so there's always some way to spread a task around. The key point is that
                                                    it is NOT possible for an individual to fail, but one of the goals isn't
                                                    met then the ENTIRE team has failed. If a case should come where Joe
                                                    Specialist was not able to complete a backlog item, the question to ask is,
                                                    "How did the team let that happen?"


                                                    Dave Barrett,
                                                    Lawyers' Professional Indemnity Company
                                                  • Kent J McDonald
                                                    Dave, A couple of questions about your first thought: 1) When you say that the web designer is not part of the team, could you describe how that works. From
                                                    Message 25 of 29 , May 15, 2004
                                                    • 0 Attachment
                                                      Dave, A couple of questions about your first thought:
                                                      1) When you say that the web designer is not part of the team, could you
                                                      describe how that works. From what you wrote about the BA, is it safe to
                                                      assume that the BA actually "volunteers" for the web designer-related tasks
                                                      and then works with the web designer to get them done?

                                                      2) What all does the BA do in your team? What granularity are your Sprint
                                                      Backlog items at? I'm trying to get a feel for how a Business Analyst fits
                                                      into a team using SCRUM.

                                                      Thanks,
                                                      --
                                                      Kent J. McDonald
                                                      kent@...
                                                      Master your instrument, master the music, and then forget all that and just
                                                      play. -- Charlie Parker


                                                      Quoting David A Barrett <dave.barrett@...>:

                                                      >
                                                      >
                                                      >
                                                      >
                                                      > From Deb:
                                                      >
                                                      > > Dave, just to be clear, how do you see the Individual Burndown as a
                                                      > > way to track performance? It seems to be missing so much information
                                                      > > (that Scrum does not record) that it could only serve
                                                      > > to /misinterpret/ performance
                                                      >
                                                      > What I meant by "performance" was the individuals' contribution to the
                                                      > group burndown.
                                                      >
                                                      > From Maurizio:
                                                      >
                                                      > >I think the team should collaborate as it was one single organism.
                                                      >
                                                      > I can't say it any better.
                                                      >
                                                      > Deb,
                                                      >
                                                      > You cite a case where your own individual burndown helped you to do better.
                                                      > Although I was really only being cheeky when I said, "Now, if the team
                                                      > decides to track individual burndowns, that would be a different
                                                      > matter...", I guess this really does fall into that category.
                                                      >
                                                      > Could explain what the expected benefits or goals are from tracking
                                                      > individual burndowns?
                                                      >
                                                      > As to load balancing when there are specialists on a team. I have two
                                                      > thoughts on this. The first is what Ken always stresses, that the pigs are
                                                      > always committed to the team goals and no one says, "That's not my area so
                                                      > I'm not going to help". We often have tasks which require some involvement
                                                      > from a web designer, but we refuse to make him part of the team because his
                                                      > skill set is too narrow to participate fully in the team goals as a pig.
                                                      > We treat him as a resource, and the team's Business Analyst is usually the
                                                      > one who keeps track of how he's doing and reports back to the team on his
                                                      > progress. The Business Analyst, by the way, is the only team member who
                                                      > can't program but she's also usually the only team member who actively
                                                      > participates in every singe Sprint Backlog item each Sprint. Each of the
                                                      > programmers have areas that only they can effectively work in, but these
                                                      > areas are often only a small part of the overall work for a sprint. The
                                                      > specialist parts of the specialist tasks are done (by necessity) by the
                                                      > specialists, but other than that it gets spread around.
                                                      >
                                                      > My second thought on load balancing is that it isn't up to the Scrum Master
                                                      > to come up with a solution. It is the team's problem, and the team needs
                                                      > to find a solution. Let the customer pick the goals, and let the team
                                                      > figure out how to meet them. Even specialist based goals are going to have
                                                      > areas, such as documentation and testing, which can be done by other people
                                                      > so there's always some way to spread a task around. The key point is that
                                                      > it is NOT possible for an individual to fail, but one of the goals isn't
                                                      > met then the ENTIRE team has failed. If a case should come where Joe
                                                      > Specialist was not able to complete a backlog item, the question to ask is,
                                                      > "How did the team let that happen?"
                                                      >
                                                      >
                                                      > Dave Barrett,
                                                      > Lawyers' Professional Indemnity Company
                                                      >
                                                      >
                                                      >
                                                      >
                                                      > To Post a message, send it to: scrumdevelopment@...
                                                      > To Unsubscribe, send a blank message to:
                                                      > scrumdevelopment-unsubscribe@...
                                                      > Yahoo! Groups Links
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >


                                                      -------------------------------------------------
                                                      Mail sent from: 64.136.27.226
                                                    • David A Barrett
                                                      ... tasks ... fits ... 1) Yeah, that s pretty much how it works out. We treat the web designer like any other scarce resourse (like a video projector) and we
                                                      Message 26 of 29 , May 17, 2004
                                                      • 0 Attachment
                                                        >Dave, A couple of questions about your first thought:
                                                        >1) When you say that the web designer is not part of the team, could you
                                                        >describe how that works. From what you wrote about the BA, is it safe to
                                                        >assume that the BA actually "volunteers" for the web designer-related
                                                        tasks
                                                        >and then works with the web designer to get them done?
                                                        >
                                                        >2) What all does the BA do in your team? What granularity are your Sprint

                                                        >Backlog items at? I'm trying to get a feel for how a Business Analyst
                                                        fits
                                                        >into a team using SCRUM.

                                                        1) Yeah, that's pretty much how it works out. We treat the web designer
                                                        like any other scarce resourse (like a video projector) and we book him for
                                                        some time with his boss. It usually works out that the BA is one who
                                                        "volunteers" for the task, but it could be someone else if the task touches
                                                        on, but isn't completely web based, or if the BA is too busy.

                                                        2) We rate our SB items with 4 sizes: Tiny < 1 day; Small = 1 to 2 days;
                                                        Medium = 3 to 5 days; Big > 5 days. Each sprint is different but our
                                                        current sprint has 1 Very Big item (15 days) and 3 Medium Items and a
                                                        pantload of Small and Tiny items.

                                                        Usually, there are one or two Sprint Backlog items that the programmers are
                                                        right on top of and know intimately. For those items, the BA is bugging
                                                        the programmers early in the Sprint to review them with her so that she can
                                                        organize the testing. The remaining items all require some level of
                                                        investigative activity prior to programming, and she proactively gets on
                                                        top of those and makes sure that everyone understands what the issues are,
                                                        how we'll go about testing them, and if things are out of scope. She also
                                                        co-ordinates demo's and meeting with the users, and polices the "big
                                                        picture" aspect of the Sprint.


                                                        Dave Barrett,
                                                        Lawyers' Professional Indemnity Company
                                                      • Nick1616
                                                        I have a question. If you use one team for various projects, don t you have a serious context-switching problem? Every team member has to know every project
                                                        Message 27 of 29 , Jul 28 11:55 AM
                                                        • 0 Attachment
                                                          I have a question. If you use one team for various projects, don't you
                                                          have a serious context-switching problem? Every team member has to
                                                          know every project and they work on different projects and different
                                                          technologies.

                                                          Nicolas
                                                        • Bas Vodde
                                                          Hi Nick, If the whole team works on several projects then they might use one product backlog and one sprint backlog and then there is no difference for the
                                                          Message 28 of 29 , Jul 28 6:07 PM
                                                          • 0 Attachment
                                                            Hi Nick,

                                                            If the whole team works on several projects then they might use one
                                                            product backlog and one sprint backlog and then there is no difference
                                                            for the team members.

                                                            If they are totally separate, then, it might not be a good idea to do
                                                            multiple projects with the same people, so don't do it :)

                                                            Bas

                                                            Nick1616 wrote:
                                                            >
                                                            >
                                                            > I have a question. If you use one team for various projects, don't you
                                                            > have a serious context-switching problem? Every team member has to
                                                            > know every project and they work on different projects and different
                                                            > technologies.
                                                            >
                                                            > Nicolas
                                                            >
                                                            >
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.