How to Handle Many Simultaneous Projects

Agile software development methods, like Scrum and Lean, tell you how to run your projects. But they all do that from a single-project perspective. What if your organization runs multiple projects at the same time? Do the agile practices still hold in such a case?

Our organization consists of 220 people, spread over two locations. We specialize in doing small fixed-price projects, most of them web-based. At any time we have at least fifty different projects running simultaneously, with lots of other projects in "sleep-mode" (either waiting for resources, waiting for customer input, or waiting for a Windows server to reboot). Handling fifty different projects creates a lot of communication overhead. (Noise might be a more fitting word.) There are always conflicting resources, conflicting constraints, and conflicting planning requirements.

So, the question is: What do Scrum and Lean say about such a multi-project situation?

Well, the answer is: Nothing! (But maybe they don't need to…)

Let's see… 220 people are working on fifty different projects. But is that so much different from other organizations where they have 220 people working on just one big project?

Many Small Projects = One Big Project
I could claim that working on many small projects is similar to working on one big project. In both cases there are simply different teams working on different feature sets. And in either case the teams don't know much about the details of the code being produced in the other teams. Therefore, it seems to me that running many small projects is similar to simultaneously developing many parts of just one big project.

Many Small Projects != One Big Project
However, I could also claim that working on many small projects is different from working on one big project. With many small projects you don't have just one troublesome customer to talk to. You have fifty of them! The horror! It is easy to agree on a sprint backlog with one customer. But it's much harder to have fifty customers agree on the allocation of your resources. (In fact, decorating our customers with bells, painting them red, and making them sing merry X-mas songs is easier than getting them to agree on our schedules.)

Optimize the Organization, not the Project
Lean Software Development has taught us an important lesson: don't focus on local optimization! Optimization should take place at the project level, not at the level of individual people, processes or components. But as I said, running many small projects is similar to simultaneously developing many parts of one big project. You should not try to optimize the development of the individual parts in a project. You should optimize the entire project. And in our case, with fifty small projects, the entire project = the entire organization. Therefore, I believe we should optimize the organization, and not the individual projects.

Get it? I hope you do. Because it took me five years to figure this out…

It's the same with traffic regulation on a busy road. By trying to make all cars adhere to a speed limit, the throughput can be increased significantly for everyone. But car drivers often try to optimize only for themselves. And then the system breaks down and everyone finds himself caught in a traffic jam, which could have been prevented by synchronization of the participants.

Picture by n-o-m-a-d

Synchronize All Projects
How can you perform optimization on the organizational level?

• Perform the sprint planning meetings on the same day for all projects (Mondays, in our case).
• Let all projects adapt to the same sprint length (weekly, in our case).
• Collect up-to-date project performance stats every week for the organizational resource planning.

A little (mandatory) synchronization can go a long way in speeding up all the participants. There is much less noise about resources, constraints and planning requirements across our projects when every single project is required to step in phase with the others. Sure, this might not be optimal for some of the individual projects. But we're not trying to speed up individual projects to their highest velocity. We're trying to speed up the entire organization, so we can improve velocity for all projects simultaneously.

The Organization is the Project
I believe that you can solve some resource planning challenges by treating the entire organization as one big project. When planning your resources, it shouldn't matter whether your people are working on many small projects or on many parts in one big project. This means that you can apply the agile and lean principles to the organization as a whole, and let them solve your problems at the appropriate level.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Fixed Price Contracts in Agile Projects
Simple vs. Complicated vs. Complex vs. Chaotic
Adaptation vs. Anticipation