Does Scrum lend itself to multi-project environments?

Question

I will be moving workplace in the near future and I believe they will be very interested in my experience of Scrum and how it may relate to their business. I am trying to understand if it will work in their environment.

My current place of work we have a 2 products/2 backlogs/2 separate teams. These backlogs are obviously prioritised based on what the business thinks it most needs for a platform that we develop. The place I will be moving to however has many projects on the go all at the same time with (2/3 individuals working on each), small bits of work come in and are fixed on a daily basis and I imagine all the customer deliverables are roughly equally as important.

So I'm wondering if anyone has experience of Scrum in a similar environment, what real examples have you got of things that worked? What didn't work? What considerations need to there for Scrum to work in this situation?

There are a few aspects that I'm not sure how would work out well:

1. I believe people in teams will work across projects, and therefore potentially across scrum teams if broken down.
2. How do you go about handling priority on so many moving parts which are probably changing frequently and have their own timescales?
3. If you have a scrum team that works on several projects (some many only require 1 Dev) then how do you understand the context of the stand-up?

Answer 1

I work as a Development Manager in exactly this environment, and have inplemented Scrum extremely successfully with a team of 4 over the past year, from what was a horrible mess. It took a bit of time to get to where we are now, but it works great. I will try to summarise the most important actions, but feel free to enquire further.

1. I acted as both Product Owner and Scrum Master. I worked to create a backlog for each product, with the associated stakeholder.

2. I then prioritised across ALL of the backlogs, so I efectively had my own backlog spanning projects. This was using Fogbugz, so I could filter to each one by project for that stakeholder to work with me and shuffle items.

3. Plan sprints from this, encapsulating all projects and all team members, so some team members will be working on their own specific tasks, but encourage cross functional working and learning. All stand up discussions are useful, because if someone is talking about something no-one else knows, they had to elaborate enough for us to understand. This aided the learning.

   • At this point, the team was lacking cohesion, but we were at least getting things done on all projects, keeping the business happy, and improving quality by adding source control / automated tests. It was a HUGE improvement of the mess that was before, but it was also hard to maintain focus, with no goal other than completing the sprint. We also didn't have demo's as they would not be particularly relevant to any one stakeholder. Because I was both PO and SM, I was relatively gentle on comitting the team to too much. It's worth noting we were still delivering a LOT more than prior to my arrival.

4. I then tried to slowly shift focus of sprints more to a single product, so we would have a sprint say 60% on one product, but still with other tasks. Eventually, sprints were 90% focussed on one task, and stakeholders learnt to 'wait their turn' - after all, we were still achieving a whole lot more than they ever got before. This made Demo's possible for one product at a time.

5. Once the sprints were focussed, I began to train the stakeholders in Scrum, and turn some of them into Product Owners. This is the stage I am at now, I work with 3 product owners, and still have 2 products I effectively own. Sprints may have 1 or 2 tasks for 'other' projects, but we have a enough focus for a sprint demo with the main stakeholders of the sprint demonstrating only their products new features.

I hope this helps, this is the journey I have been on with my current employer, and so far the Dev team, business units, and (most importantly) my boss are very happy.

Answer 2

I'm currently working as part as a 4-person scrum team that is responsible, to one degree or another, for everyone of our company's products. Totaling at roughly 16 products, plus a mess of semi-connected one-off's, I can tell you from experience that scrum doesn't endear itself to a multi-project environment. As stated above, it is tough to build team synergy when you're constantly working individually on different things. Furthermore, it is tough to cross-relate to the working details of your teammates' assignments, since your focus is on a completely different assignment, in a completely different project.

Moreover, 'falling-in-love' or even unassigned analysis with a particular product is nearly impossible due to the rate of assignment turnover, which can lead to code rot, among other things.

If you find yourself in a position where you can't escape multiple projects assigned to your team, I wouldn't recommend SCRUM.

Answer 3

The accepted answer addresses the question quite, but allow me to share my experiences. I've been in two different situations where members of a SCRUM team had to handle multiple projects. A SCRUM team can handle multiple projects, but only under certain conditions.

In the first case, the multiple projects presented a significant challenge. My employer had yet to adopt Agile methodologies as a whole. I was part of a pilot where we used SCRUM for a single project.

The problem is that the project management team favored having many concurrent, long running projects over short, focused ones. As a result, my team constantly was assigned more projects than we had developers; it was typical for the team of four to be juggling six to ten projects! This was exacerbated by the fact we had to handle a considerable amount of operational and support responsibilities as well.

What we found was because the team only had a small fraction of their time dedicated to the SCRUM team, we could not establish a reliable velocity and were limiting the amount of work for each Sprint out of fear of not making our Sprint commitments. Incorporating all of the work from other projects into our planning may have helped, but those projects had fixed dates and scopes, making unlikely that we could have done SCRUM properly.

In the second case, the entire company had long since embraced Agile and had developed a means by which multiple projects could be tackled by a SCRUM team. It was so effective that, as an Engineer, I didn't even know what half the projects were! Product Owners would work with Project Managers to identify the work needed; using the estimates provided by us Engineers and the team's established velocity, the Product Owners could make reasonable predictions as to when a particular item would be completed. As long as the team consistently meet their commitments, we didn't need to worry about the due dates for most deliverable.

It did help, though, that we were all working on the same small set of applications. The teams were aligned with the products, making it easier to know understand what your colleagues were working on as well as making it easier to shift the focus from one project to the next as needed.

In short, SCRUM can readily be adapted to handle multiple concurrent processes, if the proper planning and organization is done.

Answer 4

I'm not sure I understand, if you have "2/3 individuals working on each" then isn't that the same as having several teams, each working on a project.

They may change projects regularly, rather than having a 'product' they continually work on, but that's not much of a difference. Some places even expect teams to work on different parts of a product and change to work on something else after each project is complete - mainly to ensure a good spread of knowledge.