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

21794Re: Multiple Projects & Sprints

Expand Messages
  • Alan Shalloway
    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
      > the forming stages of getting development kicked off on several
      > 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
      > 6 developers and a few ancillary staff members (dbas, QA, etc)
      > will be involved in the projects, so that increases our total team
      > 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
      > projects into the product backlog. This appeals to me because it
      > 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
      > such a small team, and breaking into multiple teams seems bad at
      > current size.
      > We will be growing, so we will eventually be able to split into
      > than one team, but that isn't going to happen for a few more
      > What advise can I get?

      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

      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
      going-agile-part-1/ and

      Alan Shalloway
      CEO, Net Objectives
    • Show all 11 messages in this topic