One team, multiple projects

Hi David,

I highly recommend reading up on the subject of context switching and understanding the impact it has on productivity & motivation.

Something else to realize - there is only 1 team, so the output will stay the same. Working on 2 projects at the same time may not have the effect you're looking for. Instead of taking 6 months to finish project A and then 6 months to finish project B, it will take you 12 -18 months to finish both. That is 12 month of not delivering any value.

I recommend viewing the team as a doorway and that the project work flows through the doorway. You must then understand that only a certain amount can flow through the doorway (the team) at one time.

I highly recommend working on the highest priority product first and then going back to the other project.
If the team works on 2 things at the same time it will generally slow them down and you will also have the overhead of 2 sets of meetings, further reducing the amount of time the team can actually spend doing work.

Remind the stakeholders there can only be one top priority and that all time & money should be spent on delivering that which is most valuable.

Just my 2 cents.

Good luck!

Hi,

Just a small addition to the subject of context switching. Here are a few links you can follow to read more about it:

http://www.infoq.com/articles/multitasking-problems
http://blog.codinghorror.com/the-multi-tasking-myth/
http://brodzinski.com/2012/03/myth-of-100-utilization.html

As you can see, the estimates of how much time gets wasted varies, but the bottom line is, teams works best if they can concentrate on one project at a time.

But if you MUST take on two projects and there's no way around it: is your dev team large enough to turn it into two independent teams? If not, can you add a developer or two?

Cheers.

Thanks for the responses so far. I have the same question as David, but I have resource constraints that make it impossible to add developers, and external pressures (customer, compliance, regulatory, etc.) that make it dangerous to focus on a single project for each sprint. I have myself filling both the SM and PO roles, 3 developers, and dozens of simultaneous projects. It seems to me that the defnition of "project" might be the issue. Rather than define a project as a single product or feature, can Scrum still work if "project" is more broadly defined? Can a Scrum project be just a recurring category of work, like "Support Tickets" or "System Upgrades" rather than a specific thing like "New Lab Requisition Document" or "Medication File Update"?

Thanks!
Greg

> Rather than define a project as a single product or
> feature, can Scrum still work if "project" is more
> broadly defined? Can a Scrum project be just a recurring
> category of work, like "Support Tickets" or "System Upgrades"

Scrum can be applied to BAU (Business As Usual) work as long as meaningful Sprint Goals can be agreed.

The crafting of good Sprint Goals can be particularly challenging when most of the work consists of support tickets. Part of the problem is that the barrier for change for support and maintenance is generally considered to be lower than it is for development work. A Product Owner or customer representative is more likely to value a rapid turnaround than for tickets to be ordered and batched around the attainment of Sprint Goals. This may or may not be reasonable...much depends upon organizational circumstances.

I generally coach Scrum Teams to adopt the following philosophy. Support tickets that arise in-Sprint can be viewed as unplanned work and therefore as indicators of waste. Their occurrence should be minimized and this is a valid topic for retrospective consideration. Their impact on the current Sprint Goal should also be minimized. They should be triaged and handled in a way that increases the chances of meeting the Goal. Critical fixes may need to be handled in the current Sprint if the Product and its goals are to survive at all. From a Development Team perspective, this work can be seen in the context of the replanning that must occur during a Sprint if the Sprint Goal is to be met. If support tickets do not articulate into the current Goal then they may reasonably be added to the Product Backlog and organized and planned into a future Sprint.