How to handle multiple projects in a small team

Question

We just started to use scrum for our project management. We are a very small team (2 developers, 1 UI/Web-deisgner ) and we have a lot of running projects at once.

How do you handle having multiple projects running at once in the scrum model? Most of the time we have a main projects and some small ones. How do you combine multiple sprints efficiently?

edit: Don't be fixed on scrum. we are a small structure and very flexible with that. Scrum was just my starting point. If you have others systems that worked good for a or your small team i am totally open to any kind of input.

Answer 1

AFAIK the foundation of Scrum is that the team is involved in a single project at a time. Regardless of methodologies, task switching overhead makes it very inefficient to work on multiple projects "in parallel".

What you could do is to try to schedule the different projects into separate sprints, i.e. do a sprint dedicated entirely to project1, then the next sprint entirely on project2 etc. If the projects are of very different scope, you could consider varying the length of sprints, e.g. do a 3-week sprint on a large project, then maybe a 1 week sprint on a small one.

In pure Scrum the length of sprints is carved in stone indeed, but then again, IMO the point is not to get the "pure Scrum implementor" badge, rather a working real-life process for your team.

(disclaimer: I am not a Scrum master :-)

Update based on comment: I see your problem. You need to respond fast to small support (improvement / bug fix) requests from customers of other products, while still need to work on a bigger project in a predictable fashion.

One possibility would be to plan the sprints of the big project in Scrum, but "timebox" some of your time for incoming support tasks. E.g. if on the average you spend 5 days in each monthly sprint supporting other projects, you allocate 5 days' worth of resources (however you count time) for support in each sprint.

Another option may be to consider other methods, like Kanban, where there is no sprint or planning, instead the team works solely (or mainly) based on demand from customers.

Answer 2

If you have a lot of small jobs which have to be done quickly then project management is not the right paradigm. What you are dealing with is operations management which, generally, involves well-defined tried-and-tested off-the-shelf work procedures. I suggest, therefore, that you separate, management-wise, those activities of yours which require project management and those which require operations management. If you do not have the work procedures defined (and tried and tested etc) yet, then you may have to set up a project to develop them (or to codify them if you want to think of them that way).

There is a big difference between the way in which software development projects are (or ought to be) run, and how, say, a help-desk runs. Just because you are a software developer experienced in the project-management paradigm (as I think most of us are) doesn't mean that it is the right approach for everything.

Once you've made the shift, you should find that you can continue to scrum-down (or whatever the term is) on your 1 or 2 projects, and turn the handles on the machine to deliver the rest.

Answer 3

You need 1 week sprints. 1 project only per sprint. It is a fallacy that you can deliver software faster by working on multiple projects at once. The bigger project may take several sprints to develop a release where as with your small ones, you may release after every sprint.

If your projects are for different POs / Clients it is even more important that you only work on one at a time; otherwise your priorities will almost always be in conflict.

Answer 4

How do you handle having multiple projects running at once in the scrum model? Most of the time we have a main projects and some small ones. How do you combine multiple sprints efficiently?

One option is to run multiple sprints in parallel and, even if it's not ideal, to be part of several teams (obviously not 100% dedicated). I'm not sure this would make sense in your context though, I'm not convinced running the small projects with Scrum adds value.

Another (maybe more appropriate) option would be to have an item in your product backlog for the work required by satellite projects/tasks and thus to allocate some time for them. If you need that time, burn it. And if not, just pick up some extra backlog items from the main project at the end of the sprint.

Answer 5

Tricky. Your situation may not be a perfect match for Scrum but I think there are elements in Scrum that are applicable to you situation.

For example, the one thing that I find the most useful in Scrum is the Retrospectives since it is in those sessions where you improve the way you work. However in order to make the Retrospectives useful you need to measure the work you are doing to some set of items that you set out to do. So why not have something similar to sprints and do sprint planning for the items that you intend to do the next 1-2 weeks (shorter weeks seems to be more appropriate for your case). Do a daily Scrum meeting so that all three of you know what the others are up to and can fill in as appropriate. Then after the sprint you can sit down and think about how you can improve. If nothing else, the outcome of the Retrospectives will tell you if this worked for you or not.

I don't believe in trying to adapt a strict Scrum project scheme if that means running sprints in parallel or do shorter sprints with only one project at a time leaving the others untouched every other week.