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

Re: Multiple Projects & Sprints

Expand Messages
  • Alan Shalloway
    ... in ... large ... we are ... only ... that ... size ... all ... means ... with ... our ... more ... months. ... Casey: Although I would try to follow agile
    Message 1 of 11 , Jun 2 9:41 PM
    • 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 2 of 11 , Jun 3 6:55 AM
      • 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.