I recently posted on LinkedIn, asking for suggestions for post ideas. This one comes from James Nowell:

I would love to know what your thoughts are around the maximum number of projects a team should be working on at any point in time. The ideal number is one for pure focus time however I don’t see that as realistic in an agile, fast changing world. What do you think is optimal?

In my view, it’s not so much about a specific number, but about how your pipeline of work is managed. However, I’ll come back to numbers a bit later on.

Your first goal should be to make sure there’s a logical and consistent entry point to the team – a manager or a triager – so that new work requests are given some kind of assessment. Teams can work on many things at once – but as time is precious and you probably have a backlog you’ll never reach the end of, it’s essential to prioritise.

Without checks on new work coming into the team, a team can quickly become overwhelmed. It’s easy to say “yes” to every request. It’s easy to get distracted by the latest shiny thing – whether it’s a cool technical tool, or simply a bloody good idea from one of your stakeholders. But if you try to accommodate every request, or you keep getting distracted by new things, the output of the team will grind to a halt.

The “entry point” person – let’s call them the triager – is essentially a first line of defence, to protect the team from interruptions – as it will take longer to complete a task if you keep context-switching than if you do the task from start to finish.

The triager can also be the face of the team and give requestors a consistent message about what work can be taken on. It’s fine to say no to things. It’s also fine to say yes, but not until projects A, B and C are done. And it’s important to watch out for the type of work that should jump the queue – where there’s a big benefit to the business, where there’s some kind of legal deadline you need to meet, or where there’s a project you can work on to unblock some other work.

It’s also really vital for the triager to have a good relationship with the team, which means not accepting every request and telling the team they just need to do it. The triager should either know enough about the work the team is doing, or be able to learn about it, so that they are doing more than passing information back and forth. Being able to answer questions about whether something is practical can be useful too. But it’s not essential for all teams. The triager role works best if they can collaborate with the team to find out how they can be helpful and useful, and not simply add an extra layer of bureaucracy to the process.

OK, so that’s quite a bit about prioritising. The next thing to look at is how to organise the work you do want to do, and spread it around the team. The target number of “how many projects should we work on” has a cop-out answer here – “it depends” – but it really does. For each project, or block of related tasks, you should consider the following:

  1. Is it important for everyone to understand the work that’s being done? For projects that will deliver something that becomes central to a lot of your future work, you may want to get everyone working on the project – or at least set some time aside to talk through what’s happening, whether that’s before/during/after the work is done.
  2. How many people have the expertise to do the work? If one person is an expert, you’re definitely going to need them involved. It could be worthwhile to share their knowledge around. But if you have, say, 6 people in the team and only 1 has the knowledge to do most of the work on a project, it might be better to get 1 or 2 other people to learn alongside the expert, and have the other 3 people working on other things in parallel. They can always pick up the skills later.
  3. Is there enough work to share across the whole team? If you have a big team and not a lot of distinct work on a single project, you might not want to have the whole team working on one thing. However, you could pair people up, especially if points 1 or 2 apply.
  4. Is it possible, or practical, to do the work in parallel? You might not want to put 5 people on separate tasks if they need to be done in sequence.

There’s plenty to bear in mind with this.

So, what’s the maximum number of projects you can – or should – work on at a time?

In theory, the maximum number of tasks you can work on at a time is equal to the number of people in the team. But if each task is for a totally different project, that’s not really teamwork – you’ve just got a group of people each with their own tasks.

It can be really valuable for a team to “swarm” around a common goal, rather than having each person working on something totally different. It aids collaboration between team members. And I’d argue it’s better to have one thing “done” than 5 things in progress. You can read more about this in my post: Getting things done.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021