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.
Give teams an entry point, or first point of contact
Your first goal should be to make sure there’s a logical and consistent entry point to the team – often a manager or a triager – so that new work requests are given some kind of assessment.
This person is the first point of contact for work coming to the team.
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.
Why a contact person is beneficial
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.
First line of defence
The contact 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.
It’s important to watch out for the type of work that should jump the queue. A request could present a big benefit to the business. There might be some kind of legal deadline you need to meet, or a project that will unblock some other work.
A good, collaborative relationship
It’s 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 know enough about the work the team is doing, so that they are doing more than passing information back and forth. If they don’t know enough, they can learn about what the team does.
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.
Once you have a contact person, 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, consider the following:
- 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.
- 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.
- 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.
- 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.
How many projects should a team work on at a time?
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