21794Re: Multiple Projects & Sprints
- Jun 2, 2007--- In firstname.lastname@example.org, "Casey Manus"
> My company has committed to using Scrum as our methodology and are
> the forming stages of getting development kicked off on severallarge
> projects. This comes after a technology shift in the company sowe are
> starting from scratch on all the projects.only
> We have some staffing concern, at least 4 projects with currently
> 6 developers and a few ancillary staff members (dbas, QA, etc)that
> will be involved in the projects, so that increases our total teamsize
> to maybe 8 or 9 at maximum.all
> 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 itmeans
> we have high visibility into items which are similiar enough to bewith
> 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 atour
> current size.more
> 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 moremonths.
> 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
CEO, Net Objectives
- << Previous post in topic Next post in topic >>