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.

Trafficjam

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

  • Looking for Leading Developers (or Arno 2.0)
  • Joel on Software: Book(s) Review
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • http://blog.sanzenbacher.com/ Scott Sanzenbacher

    Yet another great post. You’ve got some really useful information. Thanks!

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    Thanks, Scott! It’s the compliments that keep me going… 😉

  • http://www.vyass.org Murty BVNS

    Yes, many small projects is not only equal to a big project, it is going to be a highly complex stressful job for the organization. Particularly if you have multi-location office with added spice of multi-timezones. Best of the collaborative tools and communication networks today are still immature to handle these situations.

  • Sonja

    Interesting post!
    I’m very curious to which tools, methods and ideas you’d find suitable to optimize your organisation.

  • http://www.lefdal.cc/info Alf Kåre Lefdal

    Great post, which is relevant for the company I work for.
    All agile methods emphasize the Team (“Empower the team”). How do you organize your 220 employees? Do you have more or less permanent teams? What is the team size? How do you handle sales, presales, estimating, etc.?

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    @Sonja + Alf: That’s a lot of questions, too much to answer with just one comment or blog post, I’m afraid!
    But these are the kinds of subjects that I like to talk about in future blog posts. So I hope you’ll just keep reading. 🙂

  • http://johnhunter.com/ John Hunter

    Interesting post. I have a very similar problem, many simultaneous projects with different “customers.”
    The challenge of deciding what to prioritize with many competing customers is a hard part of such a setup. If resources were dedicated to projects that could be eliminated (I figure): if each project got to prioritize their resources. But in my case we have a somewhat common shared infrastructure and then different requirements from each project and the resources for each project are not clearly defined. It makes the process challenging, but we persist with an attempt to use agile principles – though far from a textbook implementation of agile.

How to Change the World - free Workout - free
CLOSE