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

How to plan and schedule multiple projects

Expand Messages
  • Allen Bierbaum
    Hello all: I am looking for some feedback and best practices for planning, scheduling, and allocated resources to multiple agile projects in parallel. Imagine
    Message 1 of 12 , Feb 2, 2008
    • 0 Attachment
      Hello all:

      I am looking for some feedback and best practices for planning,
      scheduling, and allocated resources to multiple agile projects in
      parallel.

      Imagine that you have a development team and that you have a backlog
      for multiple projects. Your management wants to see the projects
      completed but your team needs to provide them with a proposed
      schedule, budget, external dependencies, and resource needs (ie. hire
      more people, bring in contractors, hardware needs, etc).

      What are the best practices for pulling this information together in
      an agile way? In what forms do people do this?

      To keep with the agile idea of doing the minimal overhead needed, I
      would like to put this is a simple spreadsheet that is easy to keep
      up-to-date, but I can't come up with a good form for it. I am looking
      for a good "agile way" to do it.

      For example, in traditional planning you would sit down with MS
      project or some other gnatt based tool, put up all the tasks to bring
      the project to completion, allocate resources, show what budget is
      needed, and rebalance projects against each other based on available
      people and external dependencies. We know this type of method is very
      non-agile and is likely to overrun and lead to less valuable software.

      But how should we handle project scheduling/allocation with Agile?

      Most agile references talk from a perspective of a single project that
      already has money and resources allocated to it. They talk about
      going from iteration to iteration developing the project from the
      backlog with prioritized backlog items and always able to deliver
      valuable functionality.

      This works well if you only have one group of people and one project
      to manage and are doing only internal development on your own
      projects. But what are the recommended practices for multiple
      projects, limited resources, and external projects with the need to
      fix milestones and deliveries? (note: delivery times are decided by
      your team, but they need to be decided up front so you can tell the
      customer when they are going to get their delivery)

      I am sure other people deal with this all the time, so there are
      probably references out there that I am missing. I am looking for
      some concrete guidance about how to handle these types of situations.
      Please help me find my way. :)

      Thanks,
      Allen
    • woynam
      My easiest recommendation would be to avoid working on too many projects in parallel, and thus giving the illusion that you re making progress across the
      Message 2 of 12 , Feb 4, 2008
      • 0 Attachment
        My easiest recommendation would be to avoid working on too many
        projects in parallel, and thus giving the illusion that you're making
        progress across the board.

        If you execute 2 one-month projects serially, then the first project
        is done after one month, and provides business value at that time. The
        2nd project is completed at the end of the 2nd month, and provides its
        value at that point.

        If you execute the projects in parallel by splitting the team across
        the 2 projects, both will be finished at the end of 2 months. Thus,
        you'll lose the business benefit of getting the highest priority
        project into production one month earlier.

        This may seem trivial, but it is very difficult to achieve in many
        organizations. Product owners do *not* want to be told that their
        project has lower priority, and thus is sitting in the backlog. IT
        generally tries to throw everyone a bone by starting work on anything
        and everything, and thus winds up with a less than optimal solution.

        Mark


        --- In scrumdevelopment@yahoogroups.com, "Allen Bierbaum"
        <abierbaum@...> wrote:
        >
        > Hello all:
        >
        > I am looking for some feedback and best practices for planning,
        > scheduling, and allocated resources to multiple agile projects in
        > parallel.
        >
        > Imagine that you have a development team and that you have a backlog
        > for multiple projects. Your management wants to see the projects
        > completed but your team needs to provide them with a proposed
        > schedule, budget, external dependencies, and resource needs (ie. hire
        > more people, bring in contractors, hardware needs, etc).
        >
        > What are the best practices for pulling this information together in
        > an agile way? In what forms do people do this?
        >
        > To keep with the agile idea of doing the minimal overhead needed, I
        > would like to put this is a simple spreadsheet that is easy to keep
        > up-to-date, but I can't come up with a good form for it. I am looking
        > for a good "agile way" to do it.
        >
        > For example, in traditional planning you would sit down with MS
        > project or some other gnatt based tool, put up all the tasks to bring
        > the project to completion, allocate resources, show what budget is
        > needed, and rebalance projects against each other based on available
        > people and external dependencies. We know this type of method is very
        > non-agile and is likely to overrun and lead to less valuable software.
        >
        > But how should we handle project scheduling/allocation with Agile?
        >
        > Most agile references talk from a perspective of a single project that
        > already has money and resources allocated to it. They talk about
        > going from iteration to iteration developing the project from the
        > backlog with prioritized backlog items and always able to deliver
        > valuable functionality.
        >
        > This works well if you only have one group of people and one project
        > to manage and are doing only internal development on your own
        > projects. But what are the recommended practices for multiple
        > projects, limited resources, and external projects with the need to
        > fix milestones and deliveries? (note: delivery times are decided by
        > your team, but they need to be decided up front so you can tell the
        > customer when they are going to get their delivery)
        >
        > I am sure other people deal with this all the time, so there are
        > probably references out there that I am missing. I am looking for
        > some concrete guidance about how to handle these types of situations.
        > Please help me find my way. :)
        >
        > Thanks,
        > Allen
        >
      • Peter Bell
        ... I don¹t really see the difference between one project and many. Providing the context switching costs weren¹t unbearably high, I¹d just throw all of the
        Message 3 of 12 , Feb 4, 2008
        • 0 Attachment
          Re: [scrumdevelopment] Re: How to plan and schedule multiple projects > But how should we handle project scheduling/allocation with Agile?
          > Most agile references talk from a perspective of a single project that
          > already has money and resources allocated to it.  They talk about
          > going from iteration to iteration developing the project from the
          > backlog with prioritized backlog items and always able to deliver
          > valuable functionality.
          > This works well if you only have one group of people and one project
          > to manage and are doing only internal development on your own
          > projects.  But what are the recommended practices for multiple
          > projects, limited resources, and external projects with the need to
          > fix milestones and deliveries?  (note: delivery times are decided by
          > your team, but they need to be decided up front so you can tell the
          > customer when they are going to get their delivery)

          I don’t really see the difference between one project and many. Providing the context switching costs weren’t unbearably high, I’d just throw all of the backlog items onto a single chart, find the highest priority items and work down them – possibly tweakng the order slightly to ensure you were delivering some value to each project during every measurement period.

          As for fixing milestones and deliveries and deciding them upfront, you’ll be as able to do that for multiple projects are for a single project. The estimation problems are really no different whether all of the stories are for a single client or whether they’re spread across multiple projects.

          Best Wishes,
          Peter  



          --- In scrumdevelopment@yahoogroups.com <mailto:scrumdevelopment%40yahoogroups.com> , "Allen Bierbaum"
          <abierbaum@...> wrote:
          >
          > Hello all:
          >
          > I am looking for some feedback and best practices for planning,
          > scheduling, and allocated resources to multiple agile projects in
          > parallel.
          >
          > Imagine that you have a development team and that you have a backlog
          > for multiple projects.  Your management wants to see the projects
          > completed but your team needs to provide them with a proposed
          > schedule, budget, external dependencies, and resource needs (ie. hire
          > more people, bring in contractors, hardware needs, etc).
          >
          > What are the best practices for pulling this information together in
          > an agile way?  In what forms do people do this?
          >
          > To keep with the agile idea of doing the minimal overhead needed, I
          > would like to put this is a simple spreadsheet that is easy to keep
          > up-to-date, but I can't come up with a good form for it.  I am looking
          > for a good "agile way" to do it.
          >
          > For example, in traditional planning you would sit down with MS
          > project or some other gnatt based tool, put up all the tasks to bring
          > the project to completion, allocate resources, show what budget is
          > needed, and rebalance projects against each other based on available
          > people and external dependencies.  We know this type of method is very
          > non-agile and is likely to overrun and lead to less valuable software.
          >
          > But how should we handle project scheduling/allocation with Agile?
          >
          > Most agile references talk from a perspective of a single project that
          > already has money and resources allocated to it.  They talk about
          > going from iteration to iteration developing the project from the
          > backlog with prioritized backlog items and always able to deliver
          > valuable functionality.
          >
          > This works well if you only have one group of people and one project
          > to manage and are doing only internal development on your own
          > projects.  But what are the recommended practices for multiple
          > projects, limited resources, and external projects with the need to
          > fix milestones and deliveries?  (note: delivery times are decided by
          > your team, but they need to be decided up front so you can tell the
          > customer when they are going to get their delivery)
          >
          > I am sure other people deal with this all the time, so there are
          > probably references out there that I am missing.  I am looking for
          > some concrete guidance about how to handle these types of situations.
          > Please help me find my way. :)
          >
          > Thanks,
          > Allen
          >

           
              

        • Clarke Ching
          Peter, I m just rushing out the door so forgive my brevity here: there s a huge difference between single projects and multiprojects and the switching costs
          Message 4 of 12 , Feb 4, 2008
          • 0 Attachment
            Peter,

            I'm just rushing out the door so forgive my brevity here: there's a
            huge difference between single projects and multiprojects and the
            switching costs are only a tiny part of it. If you work on three
            projects at once then you're diluting your effort on all three and
            each is taking (roughly) three and a bit times longer, delaying the
            cashflow on each.

            Take a look at pages 6 - 12 of this presentation about Goldratt's TOC
            which I gave to xpday in 2004 (run it as a presentation because the
            animation helps considerably). It shows the costs of dilution caused
            by unnecessary multi-tasking. From a business p.o.v. they are
            devastating.

            http://www.clarkeching.com/files/clarke_ching_goldratt_toc_xpday_2004.ppt

            Clarke

            On Feb 4, 2008 3:34 PM, Peter Bell <pbell@...> wrote:
            >
            >
            > > But how should we handle project scheduling/allocation with Agile?
            > > Most agile references talk from a perspective of a single project that
            > > already has money and resources allocated to it. They talk about
            > > going from iteration to iteration developing the project from the
            > > backlog with prioritized backlog items and always able to deliver
            > > valuable functionality.
            > > This works well if you only have one group of people and one project
            > > to manage and are doing only internal development on your own
            > > projects. But what are the recommended practices for multiple
            > > projects, limited resources, and external projects with the need to
            > > fix milestones and deliveries? (note: delivery times are decided by
            > > your team, but they need to be decided up front so you can tell the
            > > customer when they are going to get their delivery)
            >
            > I don't really see the difference between one project and many. Providing
            > the context switching costs weren't unbearably high, I'd just throw all of
            > the backlog items onto a single chart, find the highest priority items and
            > work down them – possibly tweakng the order slightly to ensure you were
            > delivering some value to each project during every measurement period.
            >
            > As for fixing milestones and deliveries and deciding them upfront, you'll
            > be as able to do that for multiple projects are for a single project. The
            > estimation problems are really no different whether all of the stories are
            > for a single client or whether they're spread across multiple projects.
            >
            > Best Wishes,
            > Peter
            >
            >
            >
            >
            > --- In scrumdevelopment@yahoogroups.com
            > <mailto:scrumdevelopment%40yahoogroups.com> , "Allen Bierbaum"
            >
            >
            > <abierbaum@...> wrote:
            > >
            > > Hello all:
            > >
            > > I am looking for some feedback and best practices for planning,
            > > scheduling, and allocated resources to multiple agile projects in
            > > parallel.
            > >
            > > Imagine that you have a development team and that you have a backlog
            > > for multiple projects. Your management wants to see the projects
            > > completed but your team needs to provide them with a proposed
            > > schedule, budget, external dependencies, and resource needs (ie. hire
            > > more people, bring in contractors, hardware needs, etc).
            > >
            > > What are the best practices for pulling this information together in
            > > an agile way? In what forms do people do this?
            > >
            > > To keep with the agile idea of doing the minimal overhead needed, I
            > > would like to put this is a simple spreadsheet that is easy to keep
            > > up-to-date, but I can't come up with a good form for it. I am looking
            > > for a good "agile way" to do it.
            > >
            > > For example, in traditional planning you would sit down with MS
            > > project or some other gnatt based tool, put up all the tasks to bring
            > > the project to completion, allocate resources, show what budget is
            > > needed, and rebalance projects against each other based on available
            > > people and external dependencies. We know this type of method is very
            > > non-agile and is likely to overrun and lead to less valuable software.
            > >
            > > But how should we handle project scheduling/allocation with Agile?
            > >
            > > Most agile references talk from a perspective of a single project that
            > > already has money and resources allocated to it. They talk about
            > > going from iteration to iteration developing the project from the
            > > backlog with prioritized backlog items and always able to deliver
            > > valuable functionality.
            > >
            > > This works well if you only have one group of people and one project
            > > to manage and are doing only internal development on your own
            > > projects. But what are the recommended practices for multiple
            > > projects, limited resources, and external projects with the need to
            > > fix milestones and deliveries? (note: delivery times are decided by
            > > your team, but they need to be decided up front so you can tell the
            > > customer when they are going to get their delivery)
            > >
            > > I am sure other people deal with this all the time, so there are
            > > probably references out there that I am missing. I am looking for
            > > some concrete guidance about how to handle these types of situations.
            > > Please help me find my way. :)
            > >
            > > Thanks,
            > > Allen
            > >
            >
            >
            >
            >
            >
            >
            >



            --
            Clarke Ching
            www.clarkeching.com
            +44(0)7920114893
          • Peter Bell
            Hi Clark, That assumes you can only deliver business value by completing a project. It also seems to assume that web projects are ever completed whereas in
            Message 5 of 12 , Feb 4, 2008
            • 0 Attachment
              Hi Clark,

              That assumes you can only deliver business value by completing a project. It
              also seems to assume that web projects are ever "completed" whereas in my
              experience it is more a matter of continuing to add/refine stories as
              time/budget allows.

              Lets say you have three web initiatives. Each has a list of stories and all
              are using the same core technology stack, framework and architectural
              approach to minimize (but not remove) switching costs. Let's say each
              initiative is comprised of six stories where the highest value stories are
              way more important than the lowest value stories for each project, but the
              business value of each of the initiatives is roughly similar.

              Assuming sufficiently low deployment costs to deploy at the end of each user
              story being accepted, surely there are some cases where it might make sense
              to add the most important stories to all three projects rather than
              completing all the stories for the first project and then moving onto the
              next one.

              There are a lot of variables here that would be situation specific, but I
              can absolutely see situations where it would make sense to add the most
              valuable stories to multiple projects and then to work down the priority
              list providing the switching costs are manageable and the deployment costs
              are low enough to allow for easy deployment of individual stories to start
              getting business value from each story ASAP.

              Best Wishes,
              Peter


              On 2/4/08 10:53 AM, "Clarke Ching" <clarke.ching@...> wrote:

              > Peter,
              >
              > I'm just rushing out the door so forgive my brevity here: there's a
              > huge difference between single projects and multiprojects and the
              > switching costs are only a tiny part of it. If you work on three
              > projects at once then you're diluting your effort on all three and
              > each is taking (roughly) three and a bit times longer, delaying the
              > cashflow on each.
              >
              > Take a look at pages 6 - 12 of this presentation about Goldratt's TOC
              > which I gave to xpday in 2004 (run it as a presentation because the
              > animation helps considerably). It shows the costs of dilution caused
              > by unnecessary multi-tasking. From a business p.o.v. they are
              > devastating.
              >
              > http://www.clarkeching.com/files/clarke_ching_goldratt_toc_xpday_2004.ppt
              >
              > Clarke
              >
              > On Feb 4, 2008 3:34 PM, Peter Bell <pbell@...> wrote:
              >>
              >>
              >>> But how should we handle project scheduling/allocation with Agile?
              >>> Most agile references talk from a perspective of a single project that
              >>> already has money and resources allocated to it. They talk about
              >>> going from iteration to iteration developing the project from the
              >>> backlog with prioritized backlog items and always able to deliver
              >>> valuable functionality.
              >>> This works well if you only have one group of people and one project
              >>> to manage and are doing only internal development on your own
              >>> projects. But what are the recommended practices for multiple
              >>> projects, limited resources, and external projects with the need to
              >>> fix milestones and deliveries? (note: delivery times are decided by
              >>> your team, but they need to be decided up front so you can tell the
              >>> customer when they are going to get their delivery)
              >>
              >> I don't really see the difference between one project and many. Providing
              >> the context switching costs weren't unbearably high, I'd just throw all of
              >> the backlog items onto a single chart, find the highest priority items and
              >> work down them ­ possibly tweakng the order slightly to ensure you were
              >> delivering some value to each project during every measurement period.
              >>
              >> As for fixing milestones and deliveries and deciding them upfront, you'll
              >> be as able to do that for multiple projects are for a single project. The
              >> estimation problems are really no different whether all of the stories are
              >> for a single client or whether they're spread across multiple projects.
              >>
              >> Best Wishes,
              >> Peter
              >>
              >>
              >>
              >>
              >> --- In scrumdevelopment@yahoogroups.com
              >> <mailto:scrumdevelopment%40yahoogroups.com> , "Allen Bierbaum"
              >>
              >>
              >> <abierbaum@...> wrote:
              >>>
              >>> Hello all:
              >>>
              >>> I am looking for some feedback and best practices for planning,
              >>> scheduling, and allocated resources to multiple agile projects in
              >>> parallel.
              >>>
              >>> Imagine that you have a development team and that you have a backlog
              >>> for multiple projects. Your management wants to see the projects
              >>> completed but your team needs to provide them with a proposed
              >>> schedule, budget, external dependencies, and resource needs (ie. hire
              >>> more people, bring in contractors, hardware needs, etc).
              >>>
              >>> What are the best practices for pulling this information together in
              >>> an agile way? In what forms do people do this?
              >>>
              >>> To keep with the agile idea of doing the minimal overhead needed, I
              >>> would like to put this is a simple spreadsheet that is easy to keep
              >>> up-to-date, but I can't come up with a good form for it. I am looking
              >>> for a good "agile way" to do it.
              >>>
              >>> For example, in traditional planning you would sit down with MS
              >>> project or some other gnatt based tool, put up all the tasks to bring
              >>> the project to completion, allocate resources, show what budget is
              >>> needed, and rebalance projects against each other based on available
              >>> people and external dependencies. We know this type of method is very
              >>> non-agile and is likely to overrun and lead to less valuable software.
              >>>
              >>> But how should we handle project scheduling/allocation with Agile?
              >>>
              >>> Most agile references talk from a perspective of a single project that
              >>> already has money and resources allocated to it. They talk about
              >>> going from iteration to iteration developing the project from the
              >>> backlog with prioritized backlog items and always able to deliver
              >>> valuable functionality.
              >>>
              >>> This works well if you only have one group of people and one project
              >>> to manage and are doing only internal development on your own
              >>> projects. But what are the recommended practices for multiple
              >>> projects, limited resources, and external projects with the need to
              >>> fix milestones and deliveries? (note: delivery times are decided by
              >>> your team, but they need to be decided up front so you can tell the
              >>> customer when they are going to get their delivery)
              >>>
              >>> I am sure other people deal with this all the time, so there are
              >>> probably references out there that I am missing. I am looking for
              >>> some concrete guidance about how to handle these types of situations.
              >>> Please help me find my way. :)
              >>>
              >>> Thanks,
              >>> Allen
              >>>
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >
              >
            • Clarke Ching
              Hey Peter, Sounds good. So long as someone is thinking of how to make cash flow best, as a whole, then I m happy. cheers, Clarke ... -- Clarke Ching
              Message 6 of 12 , Feb 4, 2008
              • 0 Attachment
                Hey Peter,

                Sounds good. So long as someone is thinking of how to make cash flow
                best, as a whole, then I'm happy.

                cheers, Clarke

                On Feb 4, 2008 4:15 PM, Peter Bell <pbell@...> wrote:
                > Hi Clark,
                >
                > That assumes you can only deliver business value by completing a project. It
                > also seems to assume that web projects are ever "completed" whereas in my
                > experience it is more a matter of continuing to add/refine stories as
                > time/budget allows.
                >
                > Lets say you have three web initiatives. Each has a list of stories and all
                > are using the same core technology stack, framework and architectural
                > approach to minimize (but not remove) switching costs. Let's say each
                > initiative is comprised of six stories where the highest value stories are
                > way more important than the lowest value stories for each project, but the
                > business value of each of the initiatives is roughly similar.
                >
                > Assuming sufficiently low deployment costs to deploy at the end of each user
                > story being accepted, surely there are some cases where it might make sense
                > to add the most important stories to all three projects rather than
                > completing all the stories for the first project and then moving onto the
                > next one.
                >
                > There are a lot of variables here that would be situation specific, but I
                > can absolutely see situations where it would make sense to add the most
                > valuable stories to multiple projects and then to work down the priority
                > list providing the switching costs are manageable and the deployment costs
                > are low enough to allow for easy deployment of individual stories to start
                > getting business value from each story ASAP.
                >
                > Best Wishes,
                > Peter
                >
                >
                >
                > On 2/4/08 10:53 AM, "Clarke Ching" <clarke.ching@...> wrote:
                >
                > > Peter,
                > >
                > > I'm just rushing out the door so forgive my brevity here: there's a
                > > huge difference between single projects and multiprojects and the
                > > switching costs are only a tiny part of it. If you work on three
                > > projects at once then you're diluting your effort on all three and
                > > each is taking (roughly) three and a bit times longer, delaying the
                > > cashflow on each.
                > >
                > > Take a look at pages 6 - 12 of this presentation about Goldratt's TOC
                > > which I gave to xpday in 2004 (run it as a presentation because the
                > > animation helps considerably). It shows the costs of dilution caused
                > > by unnecessary multi-tasking. From a business p.o.v. they are
                > > devastating.
                > >
                > > http://www.clarkeching.com/files/clarke_ching_goldratt_toc_xpday_2004.ppt
                > >
                > > Clarke
                > >
                > > On Feb 4, 2008 3:34 PM, Peter Bell <pbell@...> wrote:
                > >>
                > >>
                > >>> But how should we handle project scheduling/allocation with Agile?
                > >>> Most agile references talk from a perspective of a single project that
                > >>> already has money and resources allocated to it. They talk about
                > >>> going from iteration to iteration developing the project from the
                > >>> backlog with prioritized backlog items and always able to deliver
                > >>> valuable functionality.
                > >>> This works well if you only have one group of people and one project
                > >>> to manage and are doing only internal development on your own
                > >>> projects. But what are the recommended practices for multiple
                > >>> projects, limited resources, and external projects with the need to
                > >>> fix milestones and deliveries? (note: delivery times are decided by
                > >>> your team, but they need to be decided up front so you can tell the
                > >>> customer when they are going to get their delivery)
                > >>
                > >> I don't really see the difference between one project and many. Providing
                > >> the context switching costs weren't unbearably high, I'd just throw all of
                > >> the backlog items onto a single chart, find the highest priority items and
                > >> work down them ­ possibly tweakng the order slightly to ensure you were
                > >> delivering some value to each project during every measurement period.
                > >>
                > >> As for fixing milestones and deliveries and deciding them upfront, you'll
                > >> be as able to do that for multiple projects are for a single project. The
                > >> estimation problems are really no different whether all of the stories are
                > >> for a single client or whether they're spread across multiple projects.
                > >>
                > >> Best Wishes,
                > >> Peter
                > >>
                > >>
                > >>
                > >>
                > >> --- In scrumdevelopment@yahoogroups.com
                > >> <mailto:scrumdevelopment%40yahoogroups.com> , "Allen Bierbaum"
                > >>
                > >>
                > >> <abierbaum@...> wrote:
                > >>>
                > >>> Hello all:
                > >>>
                > >>> I am looking for some feedback and best practices for planning,
                > >>> scheduling, and allocated resources to multiple agile projects in
                > >>> parallel.
                > >>>
                > >>> Imagine that you have a development team and that you have a backlog
                > >>> for multiple projects. Your management wants to see the projects
                > >>> completed but your team needs to provide them with a proposed
                > >>> schedule, budget, external dependencies, and resource needs (ie. hire
                > >>> more people, bring in contractors, hardware needs, etc).
                > >>>
                > >>> What are the best practices for pulling this information together in
                > >>> an agile way? In what forms do people do this?
                > >>>
                > >>> To keep with the agile idea of doing the minimal overhead needed, I
                > >>> would like to put this is a simple spreadsheet that is easy to keep
                > >>> up-to-date, but I can't come up with a good form for it. I am looking
                > >>> for a good "agile way" to do it.
                > >>>
                > >>> For example, in traditional planning you would sit down with MS
                > >>> project or some other gnatt based tool, put up all the tasks to bring
                > >>> the project to completion, allocate resources, show what budget is
                > >>> needed, and rebalance projects against each other based on available
                > >>> people and external dependencies. We know this type of method is very
                > >>> non-agile and is likely to overrun and lead to less valuable software.
                > >>>
                > >>> But how should we handle project scheduling/allocation with Agile?
                > >>>
                > >>> Most agile references talk from a perspective of a single project that
                > >>> already has money and resources allocated to it. They talk about
                > >>> going from iteration to iteration developing the project from the
                > >>> backlog with prioritized backlog items and always able to deliver
                > >>> valuable functionality.
                > >>>
                > >>> This works well if you only have one group of people and one project
                > >>> to manage and are doing only internal development on your own
                > >>> projects. But what are the recommended practices for multiple
                > >>> projects, limited resources, and external projects with the need to
                > >>> fix milestones and deliveries? (note: delivery times are decided by
                > >>> your team, but they need to be decided up front so you can tell the
                > >>> customer when they are going to get their delivery)
                > >>>
                > >>> I am sure other people deal with this all the time, so there are
                > >>> probably references out there that I am missing. I am looking for
                > >>> some concrete guidance about how to handle these types of situations.
                > >>> Please help me find my way. :)
                > >>>
                > >>> Thanks,
                > >>> Allen
                > >>>
                > >>
                > >>
                > >>
                > >>
                > >>
                > >>
                > >>
                > >
                > >
                >
                >
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                > Yahoo! Groups Links
                >
                >
                >
                >
                >



                --
                Clarke Ching
                www.clarkeching.com
                +44(0)7920114893
              • Tom Hume
                Peter We re pretty new to Scrum (in our sixth 2-week sprint right now), but we work on multiple projects and have recently been looking at the impact of
                Message 7 of 12 , Feb 4, 2008
                • 0 Attachment
                  Peter

                  We're pretty new to Scrum (in our sixth 2-week sprint right now), but
                  we work on multiple projects and have recently been looking at the
                  impact of context switching.

                  For our first 4 sprints we had a team of 8 working on 4-6 projects per
                  sprint. In sprint 5 we reduced this down to 2-3 projects and seemed to
                  get much better throughput; I've written about our experiences at http://www.tomhume.org/2008/01/scrum-sprint-5.html
                  . It's not rigorously scientific, but I have noticed a sharp
                  difference - and my hope when we first adopted Scrum was that multiple
                  projects would have no impact, for precisely the reasons you describe.

                  FWIW Our projects aren't identical technically, but they all sit
                  within the same domain (client/server software for mobile phones) and
                  we have significant amounts of IP (proprietary UI toolkit and in-house
                  server-side platform) shared across them.

                  Tom

                  On 4 Feb 2008, at 15:34, Peter Bell wrote:

                  > I don’t really see the difference between one project and many.
                  > Providing the context switching costs weren’t unbearably high, I’d
                  > just throw all of the backlog items onto a single chart, find the
                  > highest priority items and work down them – possibly tweakng the
                  > order slightly to ensure you were delivering some value to each
                  > project during every measurement period.
                  >
                  > As for fixing milestones and deliveries and deciding them upfront,
                  > you’ll be as able to do that for multiple projects are for a single
                  > project. The estimation problems are really no different whether all
                  > of the stories are for a single client or whether they’re spread
                  > across multiple projects.

                  --
                  Future Platforms Ltd
                  e: Tom.Hume@...
                  t: +44 (0) 1273 819038
                  m: +44 (0) 7971 781422
                  company: www.futureplatforms.com
                  personal: tomhume.org
                • Peter Bell
                  I think 4-6 projects per sprint would be a lot of context switching. If I had (for example) a team of 8 working on two week sprints, I might be tempted to
                  Message 8 of 12 , Feb 4, 2008
                  • 0 Attachment
                    I think 4-6 projects per sprint would be a lot of context switching. If I
                    had (for example) a team of 8 working on two week sprints, I might be
                    tempted to break that into two teams of four working on one week sprints
                    that were project specific as I'd then get four targeted one week, 4 person
                    sprints while still showing progress on four projects in two weeks without
                    having any context switching with a given week for a given team.


                    Best Wishes,
                    Peter



                    On 2/4/08 1:27 PM, "Tom Hume" <Tom.Hume@...> wrote:

                    > Peter
                    >
                    > We're pretty new to Scrum (in our sixth 2-week sprint right now), but
                    > we work on multiple projects and have recently been looking at the
                    > impact of context switching.
                    >
                    > For our first 4 sprints we had a team of 8 working on 4-6 projects per
                    > sprint. In sprint 5 we reduced this down to 2-3 projects and seemed to
                    > get much better throughput; I've written about our experiences at
                    > http://www.tomhume.org/2008/01/scrum-sprint-5.html
                    > . It's not rigorously scientific, but I have noticed a sharp
                    > difference - and my hope when we first adopted Scrum was that multiple
                    > projects would have no impact, for precisely the reasons you describe.
                    >
                    > FWIW Our projects aren't identical technically, but they all sit
                    > within the same domain (client/server software for mobile phones) and
                    > we have significant amounts of IP (proprietary UI toolkit and in-house
                    > server-side platform) shared across them.
                    >
                    > Tom
                    >
                    > On 4 Feb 2008, at 15:34, Peter Bell wrote:
                    >
                    >> I don¹t really see the difference between one project and many.
                    >> Providing the context switching costs weren¹t unbearably high, I¹d
                    >> just throw all of the backlog items onto a single chart, find the
                    >> highest priority items and work down them ­ possibly tweakng the
                    >> order slightly to ensure you were delivering some value to each
                    >> project during every measurement period.
                    >>
                    >> As for fixing milestones and deliveries and deciding them upfront,
                    >> you¹ll be as able to do that for multiple projects are for a single
                    >> project. The estimation problems are really no different whether all
                    >> of the stories are for a single client or whether they¹re spread
                    >> across multiple projects.
                    >
                    > --
                    > Future Platforms Ltd
                    > e: Tom.Hume@...
                    > t: +44 (0) 1273 819038
                    > m: +44 (0) 7971 781422
                    > company: www.futureplatforms.com
                    > personal: tomhume.org
                    >
                    >
                    >
                    >
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to:
                    > scrumdevelopment-unsubscribe@...
                    > Yahoo! Groups Links
                    >
                    >
                    >
                  • Patrick Mee
                    Would you keep the 2 teams intact going forward or merge/split as required? Do you worry that you would not be able to measure a velocity helps with future
                    Message 9 of 12 , Feb 4, 2008
                    • 0 Attachment
                      Would you keep the 2 teams intact going forward or merge/split as required?

                      Do you worry that you would not be able to measure a velocity helps with future planning?

                      Patrick

                      Peter Bell <pbell@...> wrote:
                      I think 4-6 projects per sprint would be a lot of context switching. If I
                      had (for example) a team of 8 working on two week sprints, I might be
                      tempted to break that into two teams of four working on one week sprints
                      that were project specific as I'd then get four targeted one week, 4 person
                      sprints while still showing progress on four projects in two weeks without
                      having any context switching with a given week for a given team.

                      Best Wishes,
                      Peter

                      On 2/4/08 1:27 PM, "Tom Hume" <Tom.Hume@futureplat forms.com> wrote:

                      > Peter
                      >
                      > We're pretty new to Scrum (in our sixth 2-week sprint right now), but
                      > we work on multiple projects and have recently been looking at the
                      > impact of context switching.
                      >
                      > For our first 4 sprints we had a team of 8 working on 4-6 projects per
                      > sprint. In sprint 5 we reduced this down to 2-3 projects and seemed to
                      > get much better throughput; I've written about our experiences at
                      > http://www.tomhume. org/2008/ 01/scrum- sprint-5. html
                      > . It's not rigorously scientific, but I have noticed a sharp
                      > difference - and my hope when we first adopted Scrum was that multiple
                      > projects would have no impact, for precisely the reasons you describe.
                      >
                      > FWIW Our projects aren't identical technically, but they all sit
                      > within the same domain (client/server software for mobile phones) and
                      > we have significant amounts of IP (proprietary UI toolkit and in-house
                      > server-side platform) shared across them.
                      >
                      > Tom
                      >
                      > On 4 Feb 2008, at 15:34, Peter Bell wrote:
                      >
                      >> I don¹t really see the difference between one project and many.
                      >> Providing the context switching costs weren¹t unbearably high, I¹d
                      >> just throw all of the backlog items onto a single chart, find the
                      >> highest priority items and work down them ­ possibly tweakng the
                      >> order slightly to ensure you were delivering some value to each
                      >> project during every measurement period.
                      >>
                      >> As for fixing milestones and deliveries and deciding them upfront,
                      >> you¹ll be as able to do that for multiple projects are for a single
                      >> project. The estimation problems are really no different whether all
                      >> of the stories are for a single client or whether they¹re spread
                      >> across multiple projects.
                      >
                      > --
                      > Future Platforms Ltd
                      > e: Tom.Hume@futureplat forms.com
                      > t: +44 (0) 1273 819038
                      > m: +44 (0) 7971 781422
                      > company: www.futureplatforms .com
                      > personal: tomhume.org
                      >
                      >
                      >
                      >
                      >
                      > To Post a message, send it to: scrumdevelopment@ eGroups.com
                      > To Unsubscribe, send a blank message to:
                      > scrumdevelopment- unsubscribe@ eGroups.com
                      > Yahoo! Groups Links
                      >
                      >
                      >



                      Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

                    • Tom Hume
                      This is very similar to the model we ve moved to - using release planning to ensure we only have 2-3 projects for an 8 person team in a 2-week sprint. In
                      Message 10 of 12 , Feb 4, 2008
                      • 0 Attachment
                        This is very similar to the model we've moved to - using release
                        planning to ensure we only have 2-3 projects for an 8 person team in a
                        2-week sprint. In practice so far this has meant the team subdivide as
                        they wish, then recombine efforts at the end to collaborate on any
                        remaining work...

                        On 4 Feb 2008, at 19:34, Peter Bell wrote:

                        > I think 4-6 projects per sprint would be a lot of context switching.
                        > If I
                        > had (for example) a team of 8 working on two week sprints, I might be
                        > tempted to break that into two teams of four working on one week
                        > sprints
                        > that were project specific as I'd then get four targeted one week, 4
                        > person
                        > sprints while still showing progress on four projects in two weeks
                        > without
                        > having any context switching with a given week for a given team.

                        --
                        Future Platforms Ltd
                        e: Tom.Hume@...
                        t: +44 (0) 1273 819038
                        m: +44 (0) 7971 781422
                        company: www.futureplatforms.com
                        personal: tomhume.org
                      • Peter Bell
                        Good questions, and I probably don¹t have enough recent experience to be the right person to ask (although I¹m sure many others on the list would have more
                        Message 11 of 12 , Feb 4, 2008
                        • 0 Attachment
                          Re: [scrumdevelopment] Re: How to plan and schedule multiple projects Good questions, and I probably don’t have enough recent experience to be the right person to ask (although I’m sure many others on the list would have more relevant experience . . .).

                          Personally I’d play it by ear. If I could keep two four person teams productive and allow them to get into a groove, I’d keep the two teams fixed as that would allow me to have useful velocity measurements for each team (not comparative, but for each individual teams estimating) and to get them into flow. Personally, I’d also play with a little bit of very light hearted competition (“winning” team would get a silly perk every month based on a varying but plausible metric of value added) and co-operation (one day a month pair programming across team boundaries, shared weekly brown bag teaching lunches and monthly drinks together) to get the right balance of a little bit of competitive pressure balanced with an overriding commitment to our overall group of 8.

                          That said, I may well switch around the teams of four for the first few sprints to get the right team dynamics working. It’s not always easy to guess the subtle team dynamics in a group upfront, so I might do some exercises upfront to find the most likely balanced teams, but I’d probably still have to do some switching around to get the teams just right.

                          Best Wishes,
                          Peter

                          On 2/4/08 2:46 PM, "Patrick Mee" <paddymee@...> wrote:


                          Would you keep the 2 teams intact going forward or merge/split as required?

                          Do you worry that you would not be able to measure a velocity helps with future planning?
                           
                          Patrick

                          Peter Bell <pbell@...> wrote:
                                      
                                       
                          I think 4-6 projects per sprint would be a lot of context switching. If I
                           had (for example) a team of 8 working on two week sprints, I might be
                           tempted to break that into two teams of four working on one week sprints
                           that were project specific as I'd then get four targeted one week, 4 person
                           sprints while still showing progress on four projects in two weeks without
                           having any context switching with a given week for a given team.
                           
                           Best Wishes,
                           Peter
                           
                           On 2/4/08 1:27 PM, "Tom Hume" <Tom.Hume@... <mailto:Tom.Hume%40futureplatforms.com> > wrote:
                           
                           > Peter
                           >
                           > We're pretty new to Scrum (in our sixth 2-week sprint right now), but
                           > we work on multiple projects and have recently been looking at the
                           > impact of context switching.
                           >
                           > For our first 4 sprints we had a team of 8 working on 4-6 projects per
                           > sprint. In sprint 5 we reduced this down to 2-3 projects and seemed to
                           > get much better throughput; I've written about our experiences at
                           > http://www.tomhume.org/2008/01/scrum-sprint-5.html
                           >   . It's not rigorously scientific, but I have noticed a sharp
                           > difference - and my hope when we first adopted Scrum was that multiple
                           > projects would have no impact, for precisely the reasons you describe.
                           >
                           > FWIW Our projects aren't identical technically, but they all sit
                           > within the same domain (client/server software for mobile phones) and
                           > we have significant amounts of IP (proprietary UI toolkit and in-house
                           > server-side platform) shared across them.
                           >
                           > Tom
                           >
                           > On 4 Feb 2008, at 15:34, Peter Bell wrote:
                           >
                           >> I don’t really see the difference between one project and many.
                           >> Providing the context switching costs weren’t unbearably high, I’d
                           >> just throw all of the backlog items onto a single chart, find the
                           >> highest priority items and work down them – possibly tweakng the
                           >> order slightly to ensure you were delivering some value to each
                           >> project during every measurement period.
                           >>
                           >> As for fixing milestones and deliveries and deciding them upfront,
                           >> you’ll be as able to do that for multiple projects are for a single
                           >> project. The estimation problems are really no different whether all
                           >> of the stories are for a single client or whether they’re spread
                           >> across multiple projects.
                           >
                           > --
                           > Future Platforms Ltd
                           > e: Tom.Hume@... <mailto:Tom.Hume%40futureplatforms.com>
                           > t: +44 (0) 1273 819038
                           > m: +44 (0) 7971 781422
                           > company: www.futureplatforms.com
                           > personal: tomhume.org
                           >
                           >
                           >
                           >
                           >
                           > To Post a message, send it to:   scrumdevelopment@... <mailto:scrumdevelopment%40eGroups.com>
                           > To Unsubscribe, send a blank message to:
                           > scrumdevelopment-unsubscribe@... <mailto:scrumdevelopment-unsubscribe%40eGroups.com>
                           > Yahoo! Groups Links
                           >
                           >
                           >
                           
                           
                               
                                      


                            

                          Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now. <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ >
                           
                              

                        • Roy Morien
                          I find it very interesting to consider this question of finishing a system. It seems that this is the nub of project management practices ... to neatly wrap
                          Message 12 of 12 , Feb 4, 2008
                          • 0 Attachment
                            I find it very interesting to consider this question of 'finishing' a system. It seems that this is the nub of project management practices ... to neatly wrap up the development activity into a neat parcel called 'the project', and at the start you stipulate an end point when it will be 'finished' and you state a cost, nominally called an estimate, and you have a clear idea of exactly what it is that you will deliver by that end date and at that cost. The fact that probably 75% or more of the lifetime cost of that system will occur after 'the project' has been completed, and there will almost inevitably be substantial changes to the outcomes of 'the project', do not deter people from continuing with this, in reality, fiction about 'completing a project'.
                             
                            The end point to a system development activity is the day that the system is switched off. Not the day that the first cut of the system is delivered.

                            I am sure that many or most of our concerns about project failure would disappear if we saw the reality of systems development being a continuing, on-going activity. Obviously more time and effort will be required at the beginning of the lifetime of the system, and will peter off as the system becomes more mature, and more people have had the opportunity to have their useful suggestions included (and these useful suggestion invariably and inevitably come from hands-on use and experience). Of course, this 'education' aspect of system use is something that should be capitalised on right from the very first in the system development activity. This is why the iterative approach to development is necessarilly superior as a way to elicit requirements.
                             
                            So 'STOP the Project Mentality' ... enhance the 'System Evolution over its Lifetime'thinking.
                             
                            Regards,
                            Roy Morien




                            To: scrumdevelopment@yahoogroups.com
                            From: pbell@...
                            Date: Mon, 4 Feb 2008 11:15:57 -0500
                            Subject: Re: [scrumdevelopment] Re: How to plan and schedule multiple projects

                            Hi Clark,

                            That assumes you can only deliver business value by completing a project. It
                            also seems to assume that web projects are ever "completed" whereas in my
                            experience it is more a matter of continuing to add/refine stories as
                            time/budget allows.

                            Lets say you have three web initiatives. Each has a list of stories and all
                            are using the same core technology stack, framework and architectural
                            approach to minimize (but not remove) switching costs. Let's say each
                            initiative is comprised of six stories where the highest value stories are
                            way more important than the lowest value stories for each project, but the
                            business value of each of the initiatives is roughly similar.

                            Assuming sufficiently low deployment costs to deploy at the end of each user
                            story being accepted, surely there are some cases where it might make sense
                            to add the most important stories to all three projects rather than
                            completing all the stories for the first project and then moving onto the
                            next one.

                            There are a lot of variables here that would be situation specific, but I
                            can absolutely see situations where it would make sense to add the most
                            valuable stories to multiple projects and then to work down the priority
                            list providing the switching costs are manageable and the deployment costs
                            are low enough to allow for easy deployment of individual stories to start
                            getting business value from each story ASAP.

                            Best Wishes,
                            Peter

                            On 2/4/08 10:53 AM, "Clarke Ching" <clarke.ching@ gmail.com> wrote:

                            > Peter,
                            >
                            > I'm just rushing out the door so forgive my brevity here: there's a
                            > huge difference between single projects and multiprojects and the
                            > switching costs are only a tiny part of it. If you work on three
                            > projects at once then you're diluting your effort on all three and
                            > each is taking (roughly) three and a bit times longer, delaying the
                            > cashflow on each.
                            >
                            > Take a look at pages 6 - 12 of this presentation about Goldratt's TOC
                            > which I gave to xpday in 2004 (run it as a presentation because the
                            > animation helps considerably) . It shows the costs of dilution caused
                            > by unnecessary multi-tasking. From a business p.o.v. they are
                            > devastating.
                            >
                            > http://www.clarkech ing.com/files/ clarke_ching_ goldratt_ toc_xpday_ 2004.ppt
                            >
                            > Clarke
                            >
                            > On Feb 4, 2008 3:34 PM, Peter Bell <pbell@freshstartsof tware.com> wrote:
                            >>
                            >>
                            >>> But how should we handle project scheduling/allocati on with Agile?
                            >>> Most agile references talk from a perspective of a single project that
                            >>> already has money and resources allocated to it. They talk about
                            >>> going from iteration to iteration developing the project from the
                            >>> backlog with prioritized backlog items and always able to deliver
                            >>> valuable functionality.
                            >>> This works well if you only have one group of people and one project
                            >>> to manage and are doing only internal development on your own
                            >>> projects. But what are the recommended practices for multiple
                            >>> projects, limited resources, and external projects with the need to
                            >>> fix milestones and deliveries? (note: delivery times are decided by
                            >>> your team, but they need to be decided up front so you can tell the
                            >>> customer when they are going to get their delivery)
                            >>
                            >> I don't really see the difference between one project and many. Providing
                            >> the context switching costs weren't unbearably high, I'd just throw all of
                            >> the backlog items onto a single chart, find the highest priority items and
                            >> work down them ­ possibly tweakng the order slightly to ensure you were
                            >> delivering some value to each project during every measurement period.
                            >>
                            >> As for fixing milestones and deliveries and deciding them upfront, you'll
                            >> be as able to do that for multiple projects are for a single project. The
                            >> estimation problems are really no different whether all of the stories are
                            >> for a single client or whether they're spread across multiple projects.
                            >>
                            >> Best Wishes,
                            >> Peter
                            >>
                            >>
                            >>
                            >>
                            >> --- In scrumdevelopment@ yahoogroups. com
                            >> <mailto:scrumdevelo pment%40yahoogro ups.com> , "Allen Bierbaum"
                            >>
                            >>
                            >> <abierbaum@. ..> wrote:
                            >>>
                            >>> Hello all:
                            >>>
                            >>> I am looking for some feedback and best practices for planning,
                            >>> scheduling, and allocated resources to multiple agile projects in
                            >>> parallel.
                            >>>
                            >>> Imagine that you have a development team and that you have a backlog
                            >>> for multiple projects. Your management wants to see the projects
                            >>> completed but your team needs to provide them with a proposed
                            >>> schedule, budget, external dependencies, and resource needs (ie. hire
                            >>> more people, bring in contractors, hardware needs, etc).
                            >>>
                            >>> What are the best practices for pulling this information together in
                            >>> an agile way? In what forms do people do this?
                            >>>
                            >>> To keep with the agile idea of doing the minimal overhead needed, I
                            >>> would like to put this is a simple spreadsheet that is easy to keep
                            >>> up-to-date, but I can't come up with a good form for it. I am looking
                            >>> for a good "agile way" to do it.
                            >>>
                            >>> For example, in traditional planning you would sit down with MS
                            >>> project or some other gnatt based tool, put up all the tasks to bring
                            >>> the project to completion, allocate resources, show what budget is
                            >>> needed, and rebalance projects against each other based on available
                            >>> people and external dependencies. We know this type of method is very
                            >>> non-agile and is likely to overrun and lead to less valuable software.
                            >>>
                            >>> But how should we handle project scheduling/allocati on with Agile?
                            >>>
                            >>> Most agile references talk from a perspective of a single project that
                            >>> already has money and resources allocated to it. They talk about
                            >>> going from iteration to iteration developing the project from the
                            >>> backlog with prioritized backlog items and always able to deliver
                            >>> valuable functionality.
                            >>>
                            >>> This works well if you only have one group of people and one project
                            >>> to manage and are doing only internal development on your own
                            >>> projects. But what are the recommended practices for multiple
                            >>> projects, limited resources, and external projects with the need to
                            >>> fix milestones and deliveries? (note: delivery times are decided by
                            >>> your team, but they need to be decided up front so you can tell the
                            >>> customer when they are going to get their delivery)
                            >>>
                            >>> I am sure other people deal with this all the time, so there are
                            >>> probably references out there that I am missing. I am looking for
                            >>> some concrete guidance about how to handle these types of situations.
                            >>> Please help me find my way. :)
                            >>>
                            >>> Thanks,
                            >>> Allen
                            >>>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >
                            >




                            Join Lavalife for free. What are you waiting for?
                          Your message has been successfully submitted and would be delivered to recipients shortly.