Strictly speaking, Agile methodologies assume that everyone assigned to a project is assigned to it full time, much in the same way as Agile assumes everyone is working in the same room. While certainly the ideal situation, often it's not possible, practical, or cost-effective to have everyone on the team assigned only to one project. When people are assigned to multiple projects we have to become adept at juggling. There are a few different ways to handle multiple Agile project assignments reasonably effectively. The strategies differ based on the company, the project, and the people involved, but they all attempt to deal with the realities of software development. In general, other than alternating sprints, these strategies can be used with any projects having team members part-time.
Agile project managers and/or Scrum-masters (although typically organizations using Scrum are adhering to a very specific set of process requirements so would not generally see this issue) are often assigned several projects.Many of the strategies that will work with other team members will not work well for project managers - there's too much risk involved in assigning large blocks of time to a single project.Even if the iterations of projects are alternated, there are still issues arising during the 'down' iteration time for any given project.
There are, however, a few effective ways to keep multiple projects on track:
- Offset the times of daily stand-up meetings of the various projects. This is a good strategy when any team member is working on more than one project. It's most effective if the time difference is at least an hour so that the project manager can follow up any issues or questions from a stand-up meeting immediately. Removing blockers, resolving issues, and answering questions immediately will both help progress of the project and keep the project manager from being distracted during subsequent meetings.
- Schedule smaller blocks of time especially for each project - no more than an hour. These would be open office hours and time for the project manager to work on tasks and issues particularly for that project
- Tune up your time management system so nothing gets lost. Set reminders, capture tasks and action items, set follow-up alarms, color code activities, and be sure to have a daily to-do list.
- Begin or continue to use the Eisenhower matrix on a daily basis to be sure that you're identifying and handling critical issues and recognizing items that are really just noise.
The most common multi-project agile situation is when a technical expert, for example a DBA, is working on more than one project. It's not practical for the expert to be assigned full time to a single project - there's not usually enough work on a single project for the expert and there's not enough budget to have more than one specialist in any case.
If not carefully managed the expert's time becomes skewed in the direction of whichever project has members showing up at the expert's desk more often. It's hard to turn someone away, cut someone off, or feel as if you're the roadblock on a project. Team members of the project getting less attention become frustrated, the specialist becomes frustrated, and at least one of the projects suffers. Long term the attention tends to see-saw between the projects - sacrificing predictability for all of the projects and causing confusion and frustration with all the teams as well as the expert.
The easiest answer, although quite non-agile, is to formally split/schedule at least some of the expert's time. One option is to work every other day on a project (assuming just two projects). The last day of the week could be an open day or split into half days. The benefits of this scheme are that it is very predictable and therefore enforceable, and that the expert can focus on a single project for an entire day. The drawbacks are that the expert is unavailable to remove blockers from one project each day, which may delay that project, and that the expert will only be in one daily stand-up (showing up to both while devoting the entire day to only one usually ends up with team members from the non-day project lining up at or after the stand-up for questions). Additionally, there may only be enough work for part of the day on the project scheduled.
Another option is to split the scheduled time into half-days. This has the added benefit of allowing the expert to attend multiple stand-up meetings (assuming there is some coordination and the meetings aren't at the same time) and of allowing work on more than one project in a single day, while still providing large blocks of time devoted to one project. The downside is that this is harder to manage - people will 'forget' the times of day that they can stop by, or will feel that if they have something else scheduled they can just come by when it's convenient.
Finally, the expert can schedule office hours when people can stop by to ask questions for a particular project. If it can be managed (make no mistake, most specialists really want to help people so will have trouble turning people away outside of office hours), this is really the most effective way to manage the time. It makes time for all projects, allows the expert to attend stand-up meetings, and makes blocks of time unavailable for questions but available for working on the part of the expert. To make this work, office hours need to be posted at the entry to the expert's work area, the expert needs to use a timer or alarm of some sort that's prominently posted, and management and project management need to provide support (sometimes in the form of actually showing up to shoo people away outside of office hours).
The Whole Team
Sometimes in small companies there are several products and everyone works on all the products.In small companies people are often hired specifically for their background/expertise so it's very difficult to split out teams per product.
Fortunately, unless the products are part of a suite there are usually some reasonable options for agile.
In general, the option of designated days or half-days is still available. The problem is that for whole teams it's just not very effective - there's too much context-switching. With a very senior and experienced team, though, it does work.
The option of alternating iterations - one for each application - is a bit more appealing, at least for developers and quality engineers. (Product management, management, and other folks may not find this a reasonable distribution of their time, but it does keep everyone from having to attend multiple stand-ups per day). Keep the iterations short - since you'll be switching context anyway, there's not really that much more overhead to having one week iterations. Much more than a week and the team will encounter endless 'emergencies' while other teams get anxious about the lack of forward motion. Short iterations allow the team to concentrate on one project without having to switch context, and then allows the whole team to change at once. Scheduled stand-up meetings can be at the same time all the time. Close to release time, it's not too hard to swap out an iteration and wait just that one more week to work on the other project - it's what would happen anyway and this way it's planned and controlled.
It's often just not realistic for all members of an agile team to be assigned only to one project. It's possible to effectively juggle multiple projects - but as with any kind of juggling, you have to concentrate, focus, and plan for the next move.