You might end up in situations when you have to be part of a team that has to handle several projects at a time. This can rarely work well. And only if the team’s ability to commit to delivering successive product increments is not compromised. Or, if the team brings the first project to a stabilized version, they can then start on the second one.
Although some companies still rely on this approach, and some manage eventually to deliver valuable functionality when required, a scrum team should always focus on one project at a time. What matters besides shipping working functionality in a timely manner in scrum, is the team’s state of mind. And shifting between different contexts all the time can harm the team and lead to chaos.
Even though it can work in some cases, it’s preferred in scrum to allow the Development Team to have all of their attention directed to just one thing. It takes a lot of effort for the Product Owner to organize such an amount of work as well. Both the Development Team’s and Product Owner’s efforts could be directed towards finalizing the first project and bring value early to the business.
Why is it not a good idea in a Scrum project
It is inefficient for team members to often switch the project context.
They will often shuffle between different projects, and the more you switch the context you are working in, the more you lose focus on the current activity. And it takes some time to get back into that focused state of mind after you switched your attention to a different activity.
When the Development Team starts working on a project, all of their attention should be directed to it. Once they start looking into other projects, it’s clear that their work is not as effective as it would be if they’d finish one thing at a time. You cannot put 100% in what you do if you split your work into running unit tests for one project and writing lines of code for the other project or researching some technical details in parallel.
The skill sets and expertise of the team may not be available for different types of projects.
When a new team is put together, the team members are selected in a way that ensures that the necessary skill sets to develop the required functionality are covered. They will need knowledge about specific frameworks, tools, or libraries. Maybe experience in certain areas of the project such as Life Science or Banking projects is needed as well. Some projects can be heavy frontend and others might need much more work from backend engineers.
If the projects require different skill sets, it’s very difficult to organize the work in such a manner for everyone to work on the right things at the right moment and ensure that everyone will constantly have what to work on. Of course, it’s not impossible but, it requires much more attention and delays are easier to happen in this context.
You might need to continuously bring new people into the team, or take out others from the project. For example, if your main project is a backend heavy one and all your backend engineers are allotted there. The frontend engineers working on the secondary project might need to wait for someone from the backend project to finish their work, so that they can clear the path for the feature development. Meanwhile, the frontend engineers will probably take other tasks from the Product Backlog into the Sprint Backlog, but they might deliver no valuable functionality at the end of the sprint.
Split effort leads to slower delivery.
You will work on two or multiple things in parallel and either one might not be finished in time. Say you have a list of three projects that you have to deliver in a quarter and you start the development on all of them at the same time. You might end up having none of them ready because one is missing the integration testing, one still needs some development and one needs bug fixing.
But what if you start with the first project and you take it to the point where it’s shippable and then you focus on the next one? It’s always better to have some working functionality delivered to the customer than having nothing to show.
It may work but in very few cases
Even if there are some cases where this applies, it will not be as productive as working on one single project at a time.
There is one Product Owner that controls prioritization for all projects.
Many Product Owners have ownership of multiple projects and one team to work with. In situations like this, it’s necessary to know very well what’s the top priority for each one of the projects and how you can combine them. Also, even if the projects are different, make sure there are no or very few dependencies between projects.
Multiple Product Owners, each having their own projects, should never work with only one team. Imagine how the Scrum Events will go for that team. Not to add that will be difficult to reach a consensus on what should the teamwork on.
I’ve seen such cases, where Product Owners were in charge of a product that wasn’t considered as valuable for the business as the other products. Do you want to guess what happens? The Product Owner is preparing the stories before each Backlog Grooming and Sprint Planning. He ends up at the end of these events to be the last one talking about his requirements, or having no more room in the sprint to add any of their tasks. Not a situation you would like to be in if you are a Product Owner.
So if the Development Team has to work with more than one Product Owner, as a great Scrum Master that you are, make sure that you raise these concerns.
There is only one Product Backlog and one Sprint Backlog.
There should be only one Product Owner who works with the team on several projects. And all the items should be added to only one Product Backlog which should feed only one Sprint Backlog.
When choosing this approach of working with one team on several projects, thoroughly organizing and structuring the work is key. For a team that is jumping from one activity to another, having multiple Sprint Backlogs, opens the door to mistakes. And inefficiency nonetheless.
This is not beneficial for the Development Team only, but for the Product Owner as well. It’s difficult to follow different Product Backlogs. Instead, have one very well organized that will have on top, detailed, the most important features from each project. Then as you move to the bottom of the Product Backlog, you can have items that are less described. But it will help if those items are somewhat grouped based on priorities.
The team works on the main project and has a secondary project dedicated to bugs.
This would be the best scenario when multiple projects are assigned to one Development Team. That’s because bugs are usually generated by work that was finished, and the Development Team knows what they’ve worked on. So there’s not that much unknown territory they have to handle as it would be with a completely different project.
I worked in environments where my teams had to work simultaneously on different projects. What I’ve noticed is that teams usually become defensive when it happens. I wasn’t keen on this approach either, but what helped us a lot was the very well-organized Product Backlog.
Do you have more projects for one team? How is that working for you? You can leave a comment down below and share your experience. Maybe some tips about how you manage to handle it as well.
