I know it's preferred that a developer on a scrum team be completely devoted to that single project, but most of our projects are smaller in scale with single developers (or at least, one Dev on the UI, one Dev on the backend/APIs), and we're implementing code review and thus want multiple developers assigned to these smaller projects.

The outcome of this is developers will often have to work on more than one project at a time.

What are the risks of this and how can we work towards mitigating them?

3 Answers 3


There are multiple parts to your question so let's group them;

The downsides

A developer will be forced to attend all ceremonies for each project

If your developer is split across multiple projects (let's assume all are Scrum) then they will be attending multiple stand-ups, sprint planning, retrospectives and reviews. That is not an efficient use of the time and it's unlikely the ceremonies will be in synch, they may even overlap forcing the developer to miss critical project context

Context switching

Miller's Law states we have the ability to hold onto 7 +- 2 items in short term memory. These memories can last for up to 18 seconds and are refreshed by the original context. Any distraction will affect short term memory from stress, noise to music and loud conversations.

Now imagine you’re a programmer, trying to solve a problem what requires you to hold multiple items critical to both understanding and solving the problem. Next Imagine a PM, running over to your desk and asking the following.

“I need to show you this bug on the test environment as the client sees it and is wondering if it will be in the release next week”.

Suddenly the developer is forced to operating in a different context and is to recall multiple different items to answer the question, that in truth doesn’t need to be answered anyway. Also, the more complex the question and the longer it takes to answer the more short term memory is used on this new task.

For a developer to return to the original state depends on its complexity. Which can require anything from 5 to 30 minutes? Now imagine multiple interruptions and you can easily see how productivity will flatline.

With two or more projects you just doubled the context switching...more people, more risk of context penalties.

Lack of Cross-Functionality

Without being dedicated to a single Scrum it is unlikely the developer will have the time to cross-skill into new technologies and conversely, will have almost no time to be able to cross-skill or pair program with anyone else to coach them into a cross-skilled state

Developer Confusion

The developer will waste valuable cycle time wondering who takes precedence over their time - Product Owner A or Product Owner B. It is likely to change from Sprint to Sprint.


Developer has a poor appraisal

With his/her time split across multiple teams it is unlikely that either team will be able to give honest feedback to the developer and the very real risk is that both teams feel unsupported and the developer is provided with negative feedback which is reflected in performance related appraisals, bonuses etc.

It is not a sustainable working practice

Working across dual teams is not sustainable and is in direct contravention of the Scrum idea of "sustainable working." In addition it is likely to make cross-team working acceptable and will encourage further time splitting from other developers, testers and even the Product Owner. Disastrous for an Agile transformation and indicative of organisational dysfunction.

Team ethos and Developer morale is destroyed

When you are a part of two teams, you are a part of no team. The Scrum teams become ever closer and the switching developer is just considered "that person they need to include".

The Developer is increasingly stressed and pressured and tacitly encouraged to "find the time" to offer full capacity to both teams. It takes a special character to be able to say "no" and simply leave their work at the door.

Planning becomes inconsistent and impossible

Without being able to dedicate themselves to a project the velocity of the team will become inconsistent as stories forecast at the start of the Sprint are left undone lowering the velocity to an artificial level to cope with an absent team member

Both teams are crippled by absence

Should the developer leave or go absent you have now crippled two teams, rather than one. The risk is not shared; it is doubled. Especially with no cross-skilling.

The Developer becomes a bottleneck

The WIP limits of the teams are impaired because stories are blocked by a single developer and the time they can devote back to original team to progress a story.

The Organisation refuses to tackle a resourcing problem

A shared resource is indicative of poor management not investing in cross-functional training, not hiring needed resource, not incentivising staff to remain in the company, not promoting people to the roles they are aspiring to or not accurately forecasting the book of work for the year (or possibly all five).

It is important to realise this symptom may be the start of a death spiral.

As resource bottlenecks arise, the resource/trade is piled with more and more pressure which forces them to leave making the bottleneck worse increasing the demands which means more resource leaves...

...a blight which affected the British Army for Combat Medics from 2000 until present. As the staff left and were not replaced, the remaining medics were sent on more frequent combat tours increasing their rate of sign-off leading to even MORE frequent tours for remaining Medics until the system collapsed and economic intervention was required at massive expense to the Government.

Quality Control

Thanks to @MrHinsch for adding this as a risk. A developer split across two teams is likely to sacrifice quality for speed leading to a poorer overall product.

It is closely tied to the behaviour of drive-by ticket tracking where developers are more focussed on getting the story ticket into Done than they are about actually getting the story Done Done.


Overall, the effectiveness of both teams are at risk and the developer can feel overworked, isolated and professionally penalised leading to real-world economic consequences.

  • 1
    I would add that Quality of the product(s) suffer significantly as focus is on juggling the tasks and not quality. Commented Feb 25, 2017 at 4:41
  • this is a pretty good list. The aspects that seem most important from my experience are the lack of cross-functionality resulting in queues, unnecessary latency, software inventory i.e. increase, systemic waste. That's on an efficiency level. Beyond that, lack of focus will cause priority confusion and a disconnect between the valuable reasons the work is being done in the first place. Commented Feb 27, 2017 at 19:58

In a word: Multi-tasking.

Working on multiple projects at once will encourage the situation where a Developer is working on multiple tasks at once, which incurs massive losses due to task-switching.

If a developer works on Project A, finishes it, then works on Project B, and finishes it, s/he will be much more productive than if s/he starts on Project A, gets distracted by Project B, works on Project B, gets distracted with Project A, wastes 30 minutes trying to remember things about Project A, gets distracted by Project B, wastes 30 minutes trying to remember things about Project B, gets distracted by a 1-hour meeting about why no progress is being made on either Project, wastes 2 hours trying to figure out what to do...

You need to prioritize projects and reduce lead-time. Pick which project is the most important, and get it done. Then pick which project is the new most important, and then get it done. Repeat ad infinitum.


Risk is that progress of both projects will be slower (so you should not consider splitting up 100% of the developer's time, like 50-50%, because of the overload of task switching, it will be more like 40-40%, with the remaining time wasted). It also may impact quality negatively.

Also, it can be that the developer is not best suited to this kind of work - prefers continuous, uninterrupted activity; struggles with task switching; frustrated by conflicting priorities - this may lead to burnout.

Risk mitigation can be simple - avoid assigning multiple projects to the same developer, but unfortunately, this cannot always be done. If you really must do things this way, i suggest to communicate your expectations clearly:

  • Split time between projects consistently (for example, project 1 before lunch, project 2 after lunch). This may impact rituals schedule, live with it.
  • Let the developer know that you understand that it will lower velocity, and this is OK with you
  • Help them if they have any problems with priorities, resolve conflicts for them if they need - of course, they should let you know about any problem as soon as possible
  • If the dev really hates this kind of split assignment, try to put him into a position where he can work on a single project continuously. If you don't have this kind of flexibility, prepare for him burning out

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.