Multi-tasking is shown to be at least 15% less productive than dedicating people to a project (from Mythical Man Month), however in some cases it seems unavoidable.
Part of the agile way is to build trust with your customer/team by delivering on time and rarely blowing your iteration schedules. This is difficult when multiple projects can have competing priorities/deadlines.
Can you do agile when you're trying to juggle multiple teams and priorities?
I think you certainly can. Any variation in availability should average out as you perform iterations and get a stable velocity.
I should note however, that this will work as long as there is some priority to do the work for all involved.
Also, If you use commitment based iteration planning, each person should be able to commit to doing their work each iteration. They should know how much time they can really spend on work for the next iteration, and should commit accordingly. If someone's not pulling their weight, it will show up here too.
Committment based planning is explained to some extent here.
-- Steve
I don't think you can do any sort of reliable development (agile or not) if your team's resources are shared amongst multiple projects. What happens when you have critical issues in two projects at the same time for which the same resources is required? Context switches are costly not only in terms of software, but in terms of developer's minds.
Great question.
I work in a (too) small team with a LOT of projects on the go at once. It would be hard to say we had any process at the moment. We(I) am investigating what we can do to formalise our structures. However the multiple projects we work on through the day don't seem to lend themselves to agile methods out of the box. However I think there is even more reason to be carefully tracking the various parts of a project and have them ranked importance/dev time.
Currently we feel like we are fire fighting and the squeaky wheel definitely gets the oil. With a bit of planning we should be able to see what is important (over multiple projects) and what requires solid chunk of time to work with.
I would be interested in hearing from other people with the same problems.
It's possible (and done), but by no means ideal
You basically can end up with a much lower velocity on each iteration, and you need to make sure your iteration planning takes that into account. However, if sharing is required, I've seen "Lean" methods (Kanban in this case) do a better job as they aren't iteration focused.
The biggest thing you need to do (pretty much MUST do) is maintain a single backlog and stand-up meeting. No matter how many projects, you only have one team with one set of capacity. This removes a good bit of the multi-project overhead from the developers/testers/etc and places it on the managers and customers where it belongs.
In my experience, some of the big problems to be looked for are:
Prioritization: If project 1 has a high-priority item and so does project 2, which is actually to be done first? What if project 2 is higher priority, but people will be waiting on the task for project 1? If you have two separate project managers and/or "customers" this can get contentious.
Small-task waste. Having smaller tasks actually becomes an issue because of context switching from one project to another more often. Larger tasks make agile less effective.
Trying to separate. See above - Trying to maintain two separate backlogs is going to make agile near impossible. If you can't manage the team and all it's backlog in one stand-up meeting, you're going to find people hate "agile" (because you're not doing it).
You can if you adopt a strict "once allocated, cannot be deallocated" approach. So you plan ahead if you have a lot of pressure on your top developers' time, load them at say 75% of their time on any key project and stick to that loading come what may. That way the schedules can be stuck to, but you still have 25% slack for panics. If their are less panics, then you bring the project in early.
Using the scrum approach of short - say 3 weeks - sprints with customer demos makes it easy to fix developers time for short periods, whilst allowing their allocation to be frequently rejuggled without affecting pre-defined loadings.
I would say that agile, unless you are talking about a specific methodology like Scrum or XP, is really more of a mindset coupled with the practices that make the actions that flow out of that mindset practical for developing software. While you can't probably do straight Scrum or XP in a highly (or even moderately) multiproject environment, you can apply practices common to agile methodologies and "roll your own" agile methology, so to speak.
This is, in fact, how I work. I'm a single developer in a University IT shop who works with a group of other developers but with each of us responsible for several of our own projects. At any given time 2 or more of these can be in active development. I use practices such as story tests, test-driven development, short iterations, frequent releases, "embedded" customer (where possible), customer-driven feature selection, etc. as much as I can. While a Scrum or XP purist may not agree with me, I feel that I'm following an agile methodology.
It depends on your management. When sharing resources it should be clear which project should be finished first. If you have a clear statement on what the priorities are it doesn't really matter which method you use to complete it.
Another piece of advise is to not mix up the projects. I'm assuming that not all of the developers are shared on projects, which means you have some dedicated resources. Don't spam them with information about the projects they're not working on. They probably don't care and will get bored during team meetings.