Multiple Projects, Multiple Clients, Same Dev Team... Advice appreciated

> ...how best to tackle the issue of adopting a scrum approach
> for multiple projects simultaneously, using the same development team? 

Scrum has a product rather than a project focus. A team must be able to commit to Sprint Goals for the delivery of successive product increments. Team members can only work on multiple products simultaneously if their ability to make these commitments will not be compromised.

Sometimes it is possible to combine the work for multiple products into a single product backlog. This requires the existence of an aggregate product which can be represented by a single Product Owner. The problem of managing any competing interests can then be reduced to a matter of prioritization.

If the products are indeed separate, then you might consider interleaving sprints so that each product is worked on in rotation. The sprints would have to be short enough to ensure that each product is worked on at least once per month and a potentially shippable increment is delivered.

Its a priority call really. Create a single backlog. Each product can be broken into features - release MMF per product per sprint according to priority order.

Hi Dan,

I fully agree with Ian. One further point:

One purpose of Scrum is to protect the Development Team from e.g. too many meetings. If you practice a "Multi-Project-Scrum" where every "Project" gets its own meetings within the same Sprint, one can easily understand that you're running out of development time...

Are there more Scrum Teams on your company? If yes, perhaps you can redistribute the tasks so you can go with Ian's advice and create a single Product Backlog for each Scrum Team.

Thank you for the input.

I should have added in my original post, we only have one scrum team.

I am looking into the idea of a single backlog, and we already do this (to an extent) on our kanban board at a very high level.

Hey Dan,

As an agile coach for my company, I had to get several teams like yours into agile as well. The main thing is to get everything under roof. That is the key. If you want the team to work productively and then you need to make it visible to management the business value for each item your dev team is working on.

These are two approaches that finally worked, one is using a fast paced scrum process and the other is a Kanban process. I will explain the scrum process.



1. Create a single backlog with all projects items (you can use a shared Excel here). This backlog contains all the items that your team is aware that they will have to work on in the next couple of weeks or months.

2. Get the business to prioritize these items in an order or importance to the company. When I mean business here, it has to be the personal who can decide what is more important at a given time. Any new item coming in goes to this backlog and needs to get prioritized.

3. Plan for a weekly sprint. Have the prioritized list and plan with the team the items the team would plan for the -coming week (we did this every Thursday).

4. Get the team to give efforts / estimate etc.. and identify how much your team can do for the week. (don't worry about story points yet, just go with hours as much as possible and not days)

5. Commit this to business and make sure that you and the team delivers on it's commitments. Initially the item list will be less, but as the team realizes their capacity, it will increase

6. While the sprint is going if you get any new items coming, plan them for the next sprint. If these are severity level 1 items, then you will need to discuss with business and show the disruption to the whole sprint by this item.
Most of the time when the actual cost is shown, business tends to push back the item. For instance, if we stop and start an item due to anything, then the cost for that would actually double then what it was originally estimated.

7. Keep monitoring and improving on how the team is meeting it's commitments (do a retrospective at the end of every sprint). I am sure there will be challenges as you are changing the mindset of people, but keep monitoring the scrum process and improving.

8. You can slowly then get to a sustainable pace and slowly move to two weeks sprints and bring sanity to the situation. But it will take time.

It sounds like team is part of other teams to get projects done. Sounds like stuffing projects by skills not needs.

There are many ways how to show it - e.q. you can count hours spend on different projects during work - it should be obvious to see negative results of such actions. You can find many resources in internet about multitasking and scientific effects of it. I heard once about company having several dozens of projects running theoretically and only few in reality. Showing work-in-progress + plans could also bring attention.

Sometimes starting project sound more important than having it done - it may come from times where scheduling money on starting initiative meant being sure something (maybe very late) will be delivered. Sounds stupid but shows reality when you need to budget in long horizon. Of course it's huge organisational dysfunction.