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

Multiple Projects & Sprints

Expand Messages
  • Casey Manus
    All, My company has committed to using Scrum as our methodology and are in the forming stages of getting development kicked off on several large projects.
    Message 1 of 11 , May 9, 2007
    • 0 Attachment
      All,

      My company has committed to using Scrum as our methodology and are in
      the forming stages of getting development kicked off on several large
      projects. This comes after a technology shift in the company so we are
      starting from scratch on all the projects.

      We have some staffing concern, at least 4 projects with currently only
      6 developers and a few ancillary staff members (dbas, QA, etc) that
      will be involved in the projects, so that increases our total team size
      to maybe 8 or 9 at maximum.

      How do we handle this situation...I see a couple scenarios

      1. One Sprint Team, running 1 sprint at time...putting items from all
      projects into the product backlog. This appeals to me because it means
      we have high visibility into items which are similiar enough to be
      shared between projects.
      2. Run concurrent sprints for each project. I worry about this with
      such a small team, and breaking into multiple teams seems bad at our
      current size.


      We will be growing, so we will eventually be able to split into more
      than one team, but that isn't going to happen for a few more months.


      What advise can I get?
    • Casey Manus
      Another big concern is reporting, how do we show our sprint burndown to the stakeholders of project1 without the noise of project2? This alone may drive us to
      Message 2 of 11 , May 9, 2007
      • 0 Attachment
        Another big concern is reporting, how do we show our sprint burndown
        to the stakeholders of project1 without the noise of project2?

        This alone may drive us to running multiple sprints with the same
        team members, but that feels awkward.

        -Casey


        --- In scrumdevelopment@yahoogroups.com, "Casey Manus"
        <caseymanus@...> wrote:
        >
        > All,
        >
        > My company has committed to using Scrum as our methodology and are
        in
        > the forming stages of getting development kicked off on several
        large
        > projects. This comes after a technology shift in the company so we
        are
        > starting from scratch on all the projects.
        >
        > We have some staffing concern, at least 4 projects with currently
        only
        > 6 developers and a few ancillary staff members (dbas, QA, etc) that
        > will be involved in the projects, so that increases our total team
        size
        > to maybe 8 or 9 at maximum.
        >
        > How do we handle this situation...I see a couple scenarios
        >
        > 1. One Sprint Team, running 1 sprint at time...putting items from
        all
        > projects into the product backlog. This appeals to me because it
        means
        > we have high visibility into items which are similiar enough to be
        > shared between projects.
        > 2. Run concurrent sprints for each project. I worry about this
        with
        > such a small team, and breaking into multiple teams seems bad at
        our
        > current size.
        >
        >
        > We will be growing, so we will eventually be able to split into
        more
        > than one team, but that isn't going to happen for a few more months.
        >
        >
        > What advise can I get?
        >
      • dnicolet99
        I think you will find that by working through your project portfolio one at a time (per team) you will actually get through all the work in a shorter time than
        Message 3 of 11 , May 9, 2007
        • 0 Attachment
          I think you will find that by working through your project portfolio
          one at a time (per team) you will actually get through all the work in
          a shorter time than you would by running multiple projects
          concurrently. That approach also eliminates the problem of
          cross-project "noise" when you report status to management.

          The team size you mention sounds good. If it grows beyond about 12
          altogether you might consider dividing it into two. Depending on the
          scope of individual projects, you could divide it into two before
          that; you could even do it now, and have 2 to 4 developers on each
          team. I can't say for sure because I don't know what your portfolio
          looks like.

          Dave

          --- In scrumdevelopment@yahoogroups.com, "Casey Manus"
          <caseymanus@...> wrote:
          >
          > Another big concern is reporting, how do we show our sprint burndown
          > to the stakeholders of project1 without the noise of project2?
          >
          > This alone may drive us to running multiple sprints with the same
          > team members, but that feels awkward.
          >
          > -Casey
          >
          >
          > --- In scrumdevelopment@yahoogroups.com, "Casey Manus"
          > <caseymanus@> wrote:
          > >
          > > All,
          > >
          > > My company has committed to using Scrum as our methodology and are
          > in
          > > the forming stages of getting development kicked off on several
          > large
          > > projects. This comes after a technology shift in the company so we
          > are
          > > starting from scratch on all the projects.
          > >
          > > We have some staffing concern, at least 4 projects with currently
          > only
          > > 6 developers and a few ancillary staff members (dbas, QA, etc) that
          > > will be involved in the projects, so that increases our total team
          > size
          > > to maybe 8 or 9 at maximum.
          > >
          > > How do we handle this situation...I see a couple scenarios
          > >
          > > 1. One Sprint Team, running 1 sprint at time...putting items from
          > all
          > > projects into the product backlog. This appeals to me because it
          > means
          > > we have high visibility into items which are similiar enough to be
          > > shared between projects.
          > > 2. Run concurrent sprints for each project. I worry about this
          > with
          > > such a small team, and breaking into multiple teams seems bad at
          > our
          > > current size.
          > >
          > >
          > > We will be growing, so we will eventually be able to split into
          > more
          > > than one team, but that isn't going to happen for a few more months.
          > >
          > >
          > > What advise can I get?
          > >
          >
        • Nicholas Cancelliere
          Casey, Can you briefly describe these projects in terms of product owners and stakeholders? Do the 4 different projects have 4 different product owners? Do
          Message 4 of 11 , May 9, 2007
          • 0 Attachment
             
            Casey,
             
            Can you briefly describe these projects in terms of product owners and stakeholders?  Do the 4 different projects have 4 different product owners?  Do they have 4 different set of stakeholders?
             
            Knowing this would help in my reply to you.
             
            You are right to be concerned about having such a small team pulled in 4 different directions.  It will not prove to be productive.  Has the company considered it's taking on too much by having 4 different projects with such a small team?  I wouldn't split up the team.  Make sure they're focused on one sprint backlog (which can be derived from various product backlogs). 
             
            If the projects themselves are small is there just one Product Owner organizing the requirements?  If so then I'd suggest having a single backlog and the team works on the features in priority order set by the Product Owner.  Even if there are 4 different Product Owners, see if you can't get just *one* person to be the "last word" and setter of priorities. 
             
            If there are 4 competing product owners (who don't agree on priority) then create 4 backlogs and have the team pick from the top of each in their sprint planning.   This way each Product Owner gets a little something and can also have a realistic expectation of the velocity of the team (for "their stuff").  It will be likely 1/4 of what it would be if they had the whole team dedicated to their backlog.
             
            You can track the progress of the product backlogs using a burndown, and then the sprint using it's own (for a total of 5).  This way each Product Owner will be able to see how fast his stuff is getting done, and the team of course needs to track their progress daily in the sprint.
             
            I think what will happen is that your company will quickly realize it either needs to a) focus on just one project at a time or b) hire more developers.
             
            Not understanding the size or nature of the projects though means my interpretation/advice may or may not be relevant. 
             
            Good luck!
            Nicholas

             
            On 5/9/07, Casey Manus <caseymanus@...> wrote:

            All,

            My company has committed to using Scrum as our methodology and are in
            the forming stages of getting development kicked off on several large
            projects. This comes after a technology shift in the company so we are
            starting from scratch on all the projects.

            We have some staffing concern, at least 4 projects with currently only
            6 developers and a few ancillary staff members (dbas, QA, etc) that
            will be involved in the projects, so that increases our total team size
            to maybe 8 or 9 at maximum.

            How do we handle this situation...I see a couple scenarios

            1. One Sprint Team, running 1 sprint at time...putting items from all
            projects into the product backlog. This appeals to me because it means
            we have high visibility into items which are similiar enough to be
            shared between projects.
            2. Run concurrent sprints for each project. I worry about this with
            such a small team, and breaking into multiple teams seems bad at our
            current size.

            We will be growing, so we will eventually be able to split into more
            than one team, but that isn't going to happen for a few more months.

            What advise can I get?




            --
            Nicholas Cancelliere, Austin TX
            "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
          • Casey Manus
            My projects are large state goverment contracts and must be worked on concurrently due to the timelines already committed to by prior management. Again, its
            Message 5 of 11 , May 9, 2007
            • 0 Attachment
              My projects are large state goverment contracts and must be worked on
              concurrently due to the timelines already committed to by prior
              management. Again, its the "when can you have this done by Friday"
              mentality. My hope is that Scrum will help us figure out early
              enough what the real timeline will be so we can adjust resources as
              needed to make our line in the sand for each project. There is a lot
              of overlap between these projects as they are the same type of
              system, meaning you could probably share alot of the work from one
              project to the next. We are in a sense building our "core" product
              while fulfilling the state contracts.

              Since we are an ISV, our product owner isn't really clear, we have a
              project manager that manages the relationship with each state, so
              they contribute items to the backlog, but I guess for now the
              development manager is acting as the product owner. I want us to
              define that person more, the leader of the PMO seems like a likely
              candidate. We have this weird environment because we have a mix of
              agile and other processes that are forced upon us by the contracts
              that have been signed. Our commitment is that we are an agile
              development team and they PMO is to manage all the noise around that,
              including the fluff that is required by the contracts.


              I am probably mixing alot of information in that description of our
              environments.



              --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
              <nickaustin74@...> wrote:
              >
              > Casey,
              >
              > Can you briefly describe these projects in terms of product owners
              and
              > stakeholders? Do the 4 different projects have 4 different product
              owners?
              > Do they have 4 different set of stakeholders?
              >
              > Knowing this would help in my reply to you.
              >
              > You are right to be concerned about having such a small team pulled
              in 4
              > different directions. It will not prove to be productive. Has the
              company
              > considered it's taking on too much by having 4 different projects
              with such
              > a small team? I wouldn't split up the team. Make sure they're
              focused on
              > one sprint backlog (which can be derived from various product
              backlogs).
              >
              > If the projects themselves are small is there just one Product Owner
              > organizing the requirements? If so then I'd suggest having a
              single backlog
              > and the team works on the features in priority order set by the
              Product
              > Owner. Even if there are 4 different Product Owners, see if you
              can't get
              > just *one* person to be the "last word" and setter of priorities.
              >
              > If there are 4 competing product owners (who don't agree on
              priority) then
              > create 4 backlogs and have the team pick from the top of each in
              their
              > sprint planning. This way each Product Owner gets a little
              something and
              > can also have a realistic expectation of the velocity of the team
              (for
              > "their stuff"). It will be likely 1/4 of what it would be if they
              had the
              > whole team dedicated to their backlog.
              >
              > You can track the progress of the product backlogs using a
              burndown, and
              > then the sprint using it's own (for a total of 5). This way each
              Product
              > Owner will be able to see how fast his stuff is getting done, and
              the team
              > of course needs to track their progress daily in the sprint.
              >
              > I think what will happen is that your company will quickly realize
              it either
              > needs to a) focus on just one project at a time or b) hire more
              developers.
              >
              > Not understanding the size or nature of the projects though means my
              > interpretation/advice may or may not be relevant.
              >
              > Good luck!
              > Nicholas
              >
              >
              > On 5/9/07, Casey Manus <caseymanus@...> wrote:
              > >
              > > All,
              > >
              > > My company has committed to using Scrum as our methodology and
              are in
              > > the forming stages of getting development kicked off on several
              large
              > > projects. This comes after a technology shift in the company so
              we are
              > > starting from scratch on all the projects.
              > >
              > > We have some staffing concern, at least 4 projects with currently
              only
              > > 6 developers and a few ancillary staff members (dbas, QA, etc)
              that
              > > will be involved in the projects, so that increases our total
              team size
              > > to maybe 8 or 9 at maximum.
              > >
              > > How do we handle this situation...I see a couple scenarios
              > >
              > > 1. One Sprint Team, running 1 sprint at time...putting items from
              all
              > > projects into the product backlog. This appeals to me because it
              means
              > > we have high visibility into items which are similiar enough to be
              > > shared between projects.
              > > 2. Run concurrent sprints for each project. I worry about this
              with
              > > such a small team, and breaking into multiple teams seems bad at
              our
              > > current size.
              > >
              > > We will be growing, so we will eventually be able to split into
              more
              > > than one team, but that isn't going to happen for a few more
              months.
              > >
              > > What advise can I get?
              > >
              > >
              > >
              >
              >
              >
              > --
              > Nicholas Cancelliere, Austin TX
              > "The wide world is all about you: you can fence yourselves in, but
              you
              > cannot for ever fence it out." -Gildor, Fellowship of the Ring
              (Lord of the
              > Rings)
              >
            • George Dinwiddie
              ... Note that running the projects concurrently does not get them done faster. It merely delays them all and delivers them about the time that the lastest one
              Message 6 of 11 , May 9, 2007
              • 0 Attachment
                Casey Manus wrote:
                > My projects are large state goverment contracts and must be worked on
                > concurrently due to the timelines already committed to by prior
                > management.

                Note that running the projects concurrently does not get them done
                faster. It merely delays them all and delivers them about the time that
                the lastest one would be delivered if worked on serially.

                > Again, its the "when can you have this done by Friday"
                > mentality. My hope is that Scrum will help us figure out early
                > enough what the real timeline will be so we can adjust resources as
                > needed to make our line in the sand for each project. There is a lot
                > of overlap between these projects as they are the same type of
                > system, meaning you could probably share alot of the work from one
                > project to the next. We are in a sense building our "core" product
                > while fulfilling the state contracts.

                If they're really one project with different aspects, I would definitely
                treat them together. It may be that it's important to get certain
                stories done early--spread among the different aspects, and other
                stories can be deferred until later.

                I definitely would NOT treat them as separate projects run concurrently
                by the same developers. That will push the priority conflicts between
                them down to the developer level--out of the business' control. Not
                only does this not serve the business well, but it will create a lot of
                pain for the developers.

                - George
                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • Nicholas Cancelliere
                ... With a date already set you have to say Okay, by date X we will have these features ready. I d meet with them to make sure that the backlog is in the
                Message 7 of 11 , May 9, 2007
                • 0 Attachment


                  On 5/9/07, Casey Manus <caseymanus@...> wrote:

                  > My projects are large state goverment contracts and must be worked on
                  > concurrently due to the timelines already committed to by prior
                  > management. Again, its the "when can you have this done by Friday"
                   
                  With a date already set you have to say "Okay, by date X we will have these features ready."  I'd meet with them to make sure that the backlog is in the proper priority.  Try to get them to admit to what the minimum set is to release then use that as your release backlog.  Develop your sprints around that and iterate every 2 weeks.  The management will be able to see the progress of the release backlog (burndown) and continue to make choices to remove more features or slim them down to make the deadline.
                   
                  > mentality. My hope is that Scrum will help us figure out early
                  > enough what the real timeline will be so we can adjust resources as
                  > needed to make our line in the sand for each project. There is a lot
                   
                  Scrum doesn't do well to "adjust resources," nor does any Agile project.  In an Agile project your constraints are resources and schedule - features are what are negotiated.  (This is the opposite of waterfall projects where features are fixed and you negotiate schedule and resources). 
                   
                  What you need to understand is what the most critical features are.  Decide on what the team can do between now and then, committ to that - and manage to that plan.  This will create predictability sprint after sprint, which is what helps in planning -- you establish a velocity.  If you constantly adjust resources you'll never have a good sense of the velocity and likewise never know where you truely are in terms of the burndown of the product backlog.
                   
                  > of overlap between these projects as they are the same type of
                  > system, meaning you could probably share alot of the work from one
                  > project to the next. We are in a sense building our "core" product
                  > while fulfilling the state contracts.
                   
                  It sounds like then you should have one backlog, prioritized.  The team should be working on the core features and building the base functionality of the system and then start to iterate over that enhancing the system with each release.  Remember you want to provide value to your users as soon as possible then iterate over that.
                   
                  You might be in a bad place though given that agreements were made with a prior manager and now you're stuck with whatever committments he's made.  You might do good to investigate if it's possible to renegotiate.  Again I cannot stress (for you to be successful with Scrum) you need to get your head around "the most important features" and focus on what is priority, and work on that. 

                  > Since we are an ISV, our product owner isn't really clear, we have a
                  > project manager that manages the relationship with each state, so
                  > they contribute items to the backlog, but I guess for now the
                  > development manager is acting as the product owner. I want us to
                  > define that person more, the leader of the PMO seems like a likely
                  > candidate. We have this weird environment because we have a mix of
                  > agile and other processes that are forced upon us by the contracts
                  > that have been signed. Our commitment is that we are an agile
                  > development team and they PMO is to manage all the noise around that,
                  > including the fluff that is required by the contracts.
                   
                  It sounds like a challenge. To understand the priority you want a good user proxy - so mabye your project manager is the best person?  Try to get your management to realize they can't have everything by Friday, so ask them what is the most improtant thing for them to have by Friday.  Once you start delivering consistently you hopefully will begin to gain more trust.
                   
                  If your company has signed away their life in these contracts and have to deliever all said features by unrealistic dates -- nothing is going to help you there Scrum, waterfall or otherwise.  If this is the case then they'll need to hire a whole heck of a lot more developers to meet whatever deadlines.
                   
                  In the end you cannot escape the project triangle:  features, time, resources; pick one - better, faster, cheaper.
                   
                   
                  > I am probably mixing alot of information in that description of our
                  > environments.
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
                  >
                  > <nickaustin74@...> wrote:
                  > >
                  > > Casey,
                  > >
                  > > Can you briefly describe these projects in terms of product owners
                  > and
                  > > stakeholders? Do the 4 different projects have 4 different product
                  > owners?
                  > > Do they have 4 different set of stakeholders?
                  > >
                  > > Knowing this would help in my reply to you.
                  > >
                  > > You are right to be concerned about having such a small team pulled
                  > in 4
                  > > different directions. It will not prove to be productive. Has the
                  > company
                  > > considered it's taking on too much by having 4 different projects
                  > with such
                  > > a small team? I wouldn't split up the team. Make sure they're
                  > focused on
                  > > one sprint backlog (which can be derived from various product
                  > backlogs).
                  > >
                  > > If the projects themselves are small is there just one Product Owner
                  > > organizing the requirements? If so then I'd suggest having a
                  > single backlog
                  > > and the team works on the features in priority order set by the
                  > Product
                  > > Owner. Even if there are 4 different Product Owners, see if you
                  > can't get
                  > > just *one* person to be the "last word" and setter of priorities.
                  > >
                  > > If there are 4 competing product owners (who don't agree on
                  > priority) then
                  > > create 4 backlogs and have the team pick from the top of each in
                  > their
                  > > sprint planning. This way each Product Owner gets a little
                  > something and
                  > > can also have a realistic expectation of the velocity of the team
                  > (for
                  > > "their stuff"). It will be likely 1/4 of what it would be if they
                  > had the
                  > > whole team dedicated to their backlog.
                  > >
                  > > You can track the progress of the product backlogs using a
                  > burndown, and
                  > > then the sprint using it's own (for a total of 5). This way each
                  > Product
                  > > Owner will be able to see how fast his stuff is getting done, and
                  > the team
                  > > of course needs to track their progress daily in the sprint.
                  > >
                  > > I think what will happen is that your company will quickly realize
                  > it either
                  > > needs to a) focus on just one project at a time or b) hire more
                  > developers.
                  > >
                  > > Not understanding the size or nature of the projects though means my
                  > > interpretation/advice may or may not be relevant.
                  > >
                  > > Good luck!
                  > > Nicholas
                  > >
                  > >
                  >
                  > > On 5/9/07, Casey Manus <caseymanus@...> wrote:
                  > > >
                  > > > All,
                  > > >
                  > > > My company has committed to using Scrum as our methodology and
                  > are in
                  > > > the forming stages of getting development kicked off on several
                  > large
                  > > > projects. This comes after a technology shift in the company so
                  > we are
                  > > > starting from scratch on all the projects.
                  > > >
                  > > > We have some staffing concern, at least 4 projects with currently
                  > only
                  > > > 6 developers and a few ancillary staff members (dbas, QA, etc)
                  > that
                  > > > will be involved in the projects, so that increases our total
                  > team size
                  > > > to maybe 8 or 9 at maximum.
                  > > >
                  > > > How do we handle this situation...I see a couple scenarios
                  > > >
                  > > > 1. One Sprint Team, running 1 sprint at time...putting items from
                  > all
                  > > > projects into the product backlog. This appeals to me because it
                  > means
                  > > > we have high visibility into items which are similiar enough to be
                  > > > shared between projects.
                  > > > 2. Run concurrent sprints for each project. I worry about this
                  > with
                  > > > such a small team, and breaking into multiple teams seems bad at
                  > our
                  > > > current size.
                  > > >
                  > > > We will be growing, so we will eventually be able to split into
                  > more
                  > > > than one team, but that isn't going to happen for a few more
                  > months.
                  > > >
                  > > > What advise can I get?
                  > > >
                  > > >
                  > > >
                  > >
                  > >
                  > >
                  > > --
                  > > Nicholas Cancelliere, Austin TX
                  > > "The wide world is all about you: you can fence yourselves in, but
                  > you
                  > > cannot for ever fence it out." -Gildor, Fellowship of the Ring
                  > (Lord of the
                  > > Rings)
                  > >
                  >
                  >
                  >
                  >



                  --
                  Nicholas Cancelliere, Austin TX
                  "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
                • Casey Manus
                  Thanks for all the input. You guys are re-enforcing what I already knew is that the methodology alone isn t going to fix the current situation in regards to
                  Message 8 of 11 , May 10, 2007
                  • 0 Attachment
                    Thanks for all the input. You guys are re-enforcing what I already
                    knew is that the methodology alone isn't going to fix the current
                    situation in regards to the commitments that the company has made. I
                    can only hope to make the problems visible, Scrum will do that for me.

                    -Casey
                  • swanson_brad
                    ... Have you considered having each sprint limited to a single project, but rotating through the projects with each sprint? In other words, sprint 1 is for
                    Message 9 of 11 , May 10, 2007
                    • 0 Attachment
                      --- In scrumdevelopment@yahoogroups.com, "Casey Manus"
                      <caseymanus@...> wrote:
                      >
                      > My projects are large state goverment contracts and must be worked on
                      > concurrently due to the timelines already committed to by prior
                      > management.

                      Have you considered having each sprint limited to a single project,
                      but rotating through the projects with each sprint? In other words,
                      sprint 1 is for Project A, sprint 2 is for project B, etc.? With
                      short enough sprints, this might be the best of both worlds, allowing
                      the team to focus on 1 project at a time, but without delaying the
                      start of any 1 project too long.

                      I agree with others in this thread who have suggested that trying to
                      do all of them in parallel may be take longer than doing the projects
                      serially.

                      --Brad Swanson
                      http://agileadvocate.blogspot.com
                    • Alan Shalloway
                      ... in ... large ... we are ... only ... that ... size ... all ... means ... with ... our ... more ... months. ... Casey: Although I would try to follow agile
                      Message 10 of 11 , Jun 2, 2007
                      • 0 Attachment
                        --- In scrumdevelopment@yahoogroups.com, "Casey Manus"
                        <caseymanus@...> wrote:
                        >
                        > All,
                        >
                        > My company has committed to using Scrum as our methodology and are
                        in
                        > the forming stages of getting development kicked off on several
                        large
                        > projects. This comes after a technology shift in the company so
                        we are
                        > starting from scratch on all the projects.
                        >
                        > We have some staffing concern, at least 4 projects with currently
                        only
                        > 6 developers and a few ancillary staff members (dbas, QA, etc)
                        that
                        > will be involved in the projects, so that increases our total team
                        size
                        > to maybe 8 or 9 at maximum.
                        >
                        > How do we handle this situation...I see a couple scenarios
                        >
                        > 1. One Sprint Team, running 1 sprint at time...putting items from
                        all
                        > projects into the product backlog. This appeals to me because it
                        means
                        > we have high visibility into items which are similiar enough to be
                        > shared between projects.
                        > 2. Run concurrent sprints for each project. I worry about this
                        with
                        > such a small team, and breaking into multiple teams seems bad at
                        our
                        > current size.
                        >
                        >
                        > We will be growing, so we will eventually be able to split into
                        more
                        > than one team, but that isn't going to happen for a few more
                        months.
                        >
                        >
                        > What advise can I get?
                        >

                        Casey:
                        Although I would try to follow agile practices, they in and of
                        themselves probably won't give you enough insights to manage
                        things. The issue you have to deal with when you have multiple
                        projects that force people to work on more than one project is that
                        your teams will thrash. Thrashing is a kind of waste and is
                        exaserbated by delays of people waiting for each other. See my blog
                        (http://blogs.netobjectives.com/) on "Challenging Why (not if) Scrum
                        Works".

                        I would learn a little about Lean Software Development (see Mary and
                        Tom Poppendieck's excellent Lean Software Development: From Concept
                        to Cash. Lean gives many ideas regarding pipeline management. Not
                        unlike Type C Scrum a la Jeff Sutherland (who is the best
                        practitioner of Lean Software Development that I know of).

                        One way to think about it is to try to deliver smaller, but
                        functionally useful pieces of each project. Then stop working on
                        that project, go to another, deliver a small chunk and come back to
                        the first one. Focus on increasing total throughput of the team by
                        working on fewer, smaller projects at any one time.

                        I talk a little about this in my podcast a few months ago. You can
                        find it at
                        http://netobjectivesblogs.com/2006/12/01/lean-and-the-reasons-for-
                        going-agile-part-1/ and
                        http://netobjectivesblogs.com/2006/12/07/lean-and-the-reasons-for-
                        going-agile-part-2/

                        Alan Shalloway
                        CEO, Net Objectives
                      • Ken Schwaber
                        Although I would try to follow agile practices, they in and of themselves probably won t give you enough insights to manage things. The issue you have to deal
                        Message 11 of 11 , Jun 3, 2007
                        • 0 Attachment

                          Although I would try to follow agile practices, they in and of
                          themselves probably won't give you enough insights to manage
                          things. The issue you have to deal with when you have multiple
                          projects that force people to work on more than one project is that
                          your teams will thrash. Thrashing is a kind of waste and is
                          exaserbated by delays of people waiting for each other. See my blog
                          (http://blogs. netobjectives. com/) on "Challenging Why (not if) Scrum
                          Works".

                           

                          Not true, Alan. I’ve had a lot of experience working with enterprises that manage all development using a Scrum model, from CEO down. This requires consisten engineering, integration, management, and people practices. I wrote about the techniques in an upcoming book, “The Enterprise and Scrum.” Using Scrum practices throughout the enterprise provides a uniform set of thought patterns and terminology that provide cohesion. Learning lean to provide another way of viewing the results of Scrum is tremendously helpful. However, introducing lean as another set of practices that is unbound just increases confusion.

                           

                          I expect that we’ll see more service offerings around Lean as consulting companies attempt to differentiate themselves. The thing to watch out for is whether this builds on previous efforts or adds another completely new effort.

                          Ken


                          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alan Shalloway
                          Sent: Sunday, June 03, 2007 12:41 AM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: [scrumdevelopment] Re: Multiple Projects & Sprints

                           

                          --- In scrumdevelopment@ yahoogroups. com, "Casey Manus"
                          <caseymanus@ ...> wrote:

                          >
                          > All,
                          >
                          > My company has committed to using Scrum as our methodology and are
                          in
                          > the forming stages of getting development kicked off on several
                          large
                          > projects. This comes after a technology shift in the company so
                          we are
                          > starting from scratch on all the projects.
                          >
                          > We have some staffing concern, at least 4 projects with currently
                          only
                          > 6 developers and a few ancillary staff members (dbas, QA, etc)
                          that
                          > will be involved in the projects, so that increases our total team
                          size
                          > to maybe 8 or 9 at maximum.
                          >
                          > How do we handle this situation... I see a couple scenarios
                          >
                          > 1. One Sprint Team, running 1 sprint at time...putting items from
                          all
                          > projects into the product backlog. This appeals to me because it
                          means
                          > we have high visibility into items which are similiar enough to be
                          > shared between projects.
                          > 2. Run concurrent sprints for each project. I worry about this
                          with
                          > such a small team, and breaking into multiple teams seems bad at
                          our
                          > current size.
                          >
                          >
                          > We will be growing, so we will eventually be able to split into
                          more
                          > than one team, but that isn't going to happen for a few more
                          months.
                          >
                          >
                          > What advise can I get?
                          >

                          Casey:
                          Although I would try to follow agile practices, they in and of
                          themselves probably won't give you enough insights to manage
                          things. The issue you have to deal with when you have multiple
                          projects that force people to work on more than one project is that
                          your teams will thrash. Thrashing is a kind of waste and is
                          exaserbated by delays of people waiting for each other. See my blog
                          (http://blogs. netobjectives. com/) on "Challenging Why (not if) Scrum
                          Works".

                          I would learn a little about Lean Software Development (see Mary and
                          Tom Poppendieck' s excellent Lean Software Development: From Concept
                          to Cash. Lean gives many ideas regarding pipeline management. Not
                          unlike Type C Scrum a la Jeff Sutherland (who is the best
                          practitioner of Lean Software Development that I know of).

                          One way to think about it is to try to deliver smaller, but
                          functionally useful pieces of each project. Then stop working on
                          that project, go to another, deliver a small chunk and come back to
                          the first one. Focus on increasing total throughput of the team by
                          working on fewer, smaller projects at any one time.

                          I talk a little about this in my podcast a few months ago. You can
                          find it at
                          http://netobjective sblogs.com/ 2006/12/01/ lean-and- the-reasons- for-
                          going-agile- part-1/ and
                          http://netobjective sblogs.com/ 2006/12/07/ lean-and- the-reasons- for-
                          going-agile- part-2/

                          Alan Shalloway
                          CEO, Net Objectives

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