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

question regarding muliple projects against a small team

Expand Messages
  • Dave Moore
    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
    Message 1 of 29 , May 4, 2004
    • 0 Attachment
      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
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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 28 of 29 , Jul 28, 2007
                                                          • 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 29 of 29 , Jul 28, 2007
                                                            • 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.