What is the best way to handle multiple projects when you have a single development team? [closed]

Question

Is Agile/Scrum the answer? How does Scrum handle this?

One Product Owner, One PRoduct Backlog vs Multiple Product Owners and Product Backlogs?

How is it working for you? Please share your success failure stories?

I am trying to put a process together to manage multiple queues of work ranging from Infrastructure projects, simple feature enhancements and then big projects with a small development team of 6-7 developers.

Answer 1

One missing bit is whether this is technically one product (like one codebase, even if large) or not.

If those are completely separate products then using Scrum I'd go in very short sprints (1-2 wks) and sequence development work. So two weeks project A, then project B, then C, then again A - maybe for two sprints, then C etc. In such a situation a single backlog makes no sense, separate backlogs should be kept for A, B and C. I know at least one team that works like this.

Whether you need more POs is rather a function of knowledge about products. Maybe you need someone for each project, maybe you have someone who knows well enough A, B and C to be the PO.

If different products then when you try to do it by taking different stories from different backlogs every sprint what you will end up with is split team. Naturally people will specialize in given project, also it will be very hard to have a good definition of done (are we done if we can ship new increments for A and B but not C this sprint?). If you can't sequence projects with short sprints, then I would look towards Kanban for trying to put some organization into this.

If this is one product/one codebase - then things are much easier. Even if the team will have to touch different areas of the codebase because of different projects they will be still working on the same products so all mechanics of Scrum will apply nicely. One backlog, one PO.

One downside of this to be noted is that people on the team will context-switch and there is a penalty from doing this no matter what process you use. Whatever process you pick should try to minimize this as long as possible (as long as business will be able to hold). Nice thing about Scrum is that it has this built in agreement with the PO that context switches can occur only at sprints border - in other words team will get 1-2 wks to concentrate before having to switch to another project.

Also, don't forget about all technical practices of agile. Unit tests. Automatic builds & tests. Code reviews. Clever use of repos. High standards re. quality. All those are a must in such a challenging environment.

Answer 2

I guess you can do two things:

1. Do one release of one project, when done, do the next
2. Split up your development team

Or a combination of both :)

Agile/Scrum are nice buzzwords, but don't seem very related to your question. Since they apply to the scope of a project, not to a bunch of projects.

I have experience with the second option, up to a level where there are more projects then developers, which isn't what you want. But with decent code review sessions it does seem to work.

Answer 3

A little more detail might help. Is it one big production team, that is sharing lots of projects between them? Is it a small team (5 ish) with lots of projects?

Why do you have lots of projects? Are they working on different time frames, with some being the 'real work' and others being the 'if your not busy do this as a background task'.

I suppose the key here might be the project to developer ratio.

We have a single department of about 15, which runs 3-4 projects at any one time. People generally belong to a project at any one time, but can move between them as projects go through different phases, and as different skills are needed. Test in particular seem to switch projects a lot.

As for a strict process...make the process fit your needs. If we have a better idea of your needs we might be able to make better suggestions.

Answer 4

One critical piece is that the multiple product owners need to be aware of each other and be able to work together outside of the scope of the development. If they're segregated out into their own fiefdoms and each one trying to be louder than the others to get the attention "their product" deserves, then you're going to have problems.

By the time any development work is put before the team, these things should already be straightened out. The developers shouldn't care (or, in some cases, even bother to know) what tasks are for what owners or what projects, etc. They can care and know these things, sure, but it shouldn't be critical.

The product owners and various other high-level roles need to start each sprint with a plan of which stories should be done during that sprint. It doesn't matter how many stories from any given project are included, sorting that out is a scheduling concern for those stakeholders. Working with the architect or senior developer or such, they should simply decide what stories get implemented in the current/next sprint.

(On a side note, I have an Area 51 proposal for just this sort of thing: http://area51.stackexchange.com/proposals/9543/development-methodologies)