There’s a number of factors to consider like due dates for projects, visibility to management, impact on the business, etc.

Generally though, I worked effectively with some rules I used:

• Break it down by feature/bug we’ll call them tasks. This implies that you’re using some kind of task tracking mechanism, which you must due to the hopping from project-to-project. You need to know where you were and where you were going as soon as you get onto the project in order to minimize the context-switch overhead as much as possible.
• Obviously, work through your tasks in priority order per-project.
• Work a task to completion. Even if a priority 1 task for project A would normally take you longer than you allocate per-project, do it anyway. You’ll have to re-figure out what you were trying to do when you get back to the project if you leave early.
• If you have tasks given to you by management, create a priority queue, and make it available. If it’s just a whiteboard, tell management that all tasks you’re given go to the bottom of the pile. If they want it at the top, they have to see the tasks that they’re pre-empting/interrupting.
• Allocate a general amount of time per-project. If it’s a day, a half-day, a week, whatever makes sense for your environment and try to stick to it (with the exception of finishing tasks as mentioned above). If you can fit 2 tasks in a morning for Project A, then do that. Don’t split the projects up too much. As previously, if you’re given a task for Project B and you’re on Project A now, you can say something like: “Great, I’m on Project B tomorrow morning, and I’ll take a look at it first thing in the morning.”
• Even if you do the same project back-to-back, keep it in your head that you have 2 work-sessions (periods of time to work on a project) that you’re allocating for 1 project.
• Split sessions up using effective separators: end-of-day, lunch, coffee break. Anything where your mind stops working 100%. The context-switch will be natural and you’d have to do it anyway even if you didn’t switch projects.

The goal is to have a clearly defined schedule to manage wacky amounts of work/projects. If you stick to the schedule like:

        Mon Tues Wed Thurs Fri
Morn    A   B    A   B     A
Aft     A   C    C   C     C

… then your metrics will be more accurate and predictable. If you are using burn-down charts for development/delivery dates, they’ll be more accurate and predictable. It might take time creating a schedule that takes into account availability of certain managers, QA, other devs, software/hardware resources, whatever, but once you’ve got one down, it’ll be business as usual and you won’t get so flustered.

My initial response is that if you have a team, why are you working like you don’t?

Certainly, there may be a reason, but I am not sure it is stated.

Limiting Factors

My suggestion is that you organize work to field as much product as early as possible and with the greatest possible profit margin. How you do this may depend on your business model and a variety of factors, including some that limit what you can do.

• Responsiveness: Can we do one project until it is done? Or do we need to spend time with stakeholders for each project in a way that shows we respond to their needs?
• Focus: We can only accelerate to our maximum velocity on a task if we have blocks of time to focus on the work.
• Communication/Consultation: Do we need to communicate early and often, perhaps consult on decisions, thereby introducing delays into the work? What is the minimum we must do to use prototypes and round robin switching between projects to accomplish our needs in this category?
• Division of labor: Does one person do several kinds of work? Could we divide the projects so repetitive work of the same kind is done by someone who builds expertise that much faster because they do more of it?
• Capital/cash flow: Do we get paid at the end, as we reach milestones, or for time and materials? Does working multiple projects in parallel give us multiple payments or just delay projects that could complete in series?
• Competition: Is the market for our product such that early entry would let us sell more because we would have fewer competitors?
• Adoption: If we get there early, is the market too immature for us to have strong sales until the market starts to adopt our product? Is there an advantage to wait for someone else to be the pioneer?
• Revenue stream: Do we get paid once on completion, or does completing the project permit the sale of a product in constant or growing quantities? Are there maintenance or subscription fees our customer will pay to us once the product is fielded?

A Few Hypothetical Scenarios

If you charge time and materials, but only get paid at the end, your limiting factor is project duration. If you have four projects, if you assign everyone one each job doing the jobs in sequence from shortest to longest. You have the profit from the first job to reduce the borrowed resources for the second job, or to hire more help to finish the second job faster.

If you make a product that once completed creates a market with constant or increasing sales every month, you have a compounding revenue increase with each project completed. If you take a strictly round robin approach, this will happen later, rather than sooner.

If you prioritize your longest duration job, every other job will wait and the small jobs will start to have the longest duration, which is a particular problem in the eyes of those customers.

If you are selling something for which being first to market weights revenue in your favor, you can afford to sacrifice something to be early.

If you work only your highest priority, you may have one happy customer and the remaining customers unhappy or going elsewhere.

A Naive Example

Many years ago, I worked at a company where it was considered efficient and empowering to have each of the four software developers work as a lead on their own project which typically took nine to twelve months each. This went on a couple years, we added a few more people organizing in the same way. Then, we had a bigger project and made a four person team instead. With the team we took on a much larger project, and when it released about 12 months later, we had the best year in the company’s history.

Shortly afterward, a colleague and I had a conversation about the idea that our future projects might make more money if we stopped doing the one project per person per year. Here is a sketch:

Method 1: Project per developer
Four developers, four projects of 12 months duration, that sell 500K/quarter.

                           Project 1    Project 2   Project 3   Project 4   Total
Q1:     
Labor (man months):        3            3           3           3           12
Net Income:                0            0           0           0           0   

Q2:     
Labor (man months):        3            3           3           3           12
Net Income:                0            0           0           0           0   

Q3:     
Labor (man months):        3            3           3           3           12
Net Income:                0            0           0           0           0   

Q4:     
Labor (man months):        3            3           3           3           12
Net Income:                0            0           0           0           0   

Q5:     
Labor (man months):        0            0           0           0           0
Net Income:                500K         500K        500K        500K        2000K

Y1 Income: $0
Total Income for 15 months: $2000K


Method 2: Four developers working as a team.
Four developers, four projects of 12 months duration, that sell 500K/quarter.

                           Project 1    Project 2   Project 3   Project 4   Total
Q1:     
Labor (man months):        12           0           0           0           12
Net Income:                0            0           0           0           0   

Q2:     
Labor (man months):        0            12          0           0           12
Net Income:                500K         0           0           0           500K   

Q3:     
Labor (man months):        0            0           12          0           12
Net Income:                500K         500K        0           0           1000

Q4:     
Labor (man months):        3            3           3           3           12
Net Income:                500K         500K        500K        0           1500K   

Q5:     
Labor (man months):        0            0           0           0           0
Net Income:                500K         500K        500K        500K        2000K


Y1 Income: $3000
Total Income for 15 months: $5000K

This example is simpler than any real work environment would be. But hopefully it illustrates that if we are multitasking, we are delaying and reducing our rewards as compared to single focus and teamwork.

What SnOrfus suggests will work well with smaller, well defined projects if you are disciplined. With larger, more exploratory projects, programmer multitasking is largely a management myth. Joel Spolsky says never let people work on more than one thing at once. The more often you switch projects, the less you accomplish.

I had a boss who insisted that I “multitask.” My strategy was always to prioritize across projects and do the highest priority thing first, sticking with a single project for as long as possible. Sometimes I would hold off reporting progress on one thing so that I could stagger my progress reports to make it look like I was switching back and forth. Then I would lie and say “Yes” I was multitasking. Sometimes you can do all the really quick projects first so you can concentrate on a longer one (and report a shorter one done each day while you concentrate on the longer one). I was always very productive this way and my boss was very happy (if a little misinformed). For the record, I tried reasoning with him first, and only lied when that failed.

One exception to this rule is interruptions to handle tech support requests. Nothing is more important to a programmer than an intimate understanding of the needs of the customer. The benefit of that understanding is worth the cost of breaking concentration (within reason).

Good luck!