How does Scrum work when you have multiple projects?

Question

I'm fairly well read in the benefits and processes of Scrum. I get the ideas on the backlog, burndown charts, iterations, using user stories, and other various concepts of the Scrum "framework".

With that said... I work for a web development firm that manages multiple projects at one time, with six team members that make up the "production team".

How does Scrum work with having multiple projects? Do you still just schedule an iteration for a single project in a certain amount of time and the entire team works on it, and then you move on to the next project with a new iteration when that iteration is completed? Or is there an "agile" way in managing multiple projects with their own iterations with only one team at the same time?

Solution 1

Scrum really doesn't dictate that you have to be working on the one self-contained product. It simply states that there is a bunch of stuff that needs to be done (the product backlog), there is a certain amount of development time available in the next iteration (worked out from the project velocity) and there are items selected by the client/business as having most priority from this pool of issues/tasks that will be done in the next iteration (the sprint backlog).

There is no reason that the product backlog and sprint backlog have to be from the one project - even in a single project there will be discrete units of work that are like separate projects - the UI, the business layer, the database schema, etc. Enterprise software development in particular is like this, where you have a number of code bases that all have to be progressing. The Scrum process - meetings, questions, burn down chart, etc - all work whether it is one project or multiple.

Having said that, in practice it is often good for each iteration to have a major theme - "do the reporting module" or "interface with XYZ system's API" - so that a lot of the issues come from one project or area and at the end of the iteration you can point to a large body of work and place a tick against it.

Solution 2

I think the answer depends on "who will be prioritizing the backlog items" (i.e. decide what needs to be done first). If this is a single person, then this person is the Product Owner for your projects, and you can have a single backlog will all items for all projects - or a backlog per project - and you select the backlog items from all projects when you plan a Sprint. In this case, Scrum "works" fine.

If every project has its responsible, then you're likely to encounter some troubles where each responsible will - more or less consciously - try to favor its project(s). IMHO, you'll need to have one Product Owner only with the authority to settle the priorities by arbitration.

One rule that shall be followed in such a context is to never change the Sprint content during the Sprint. If necessary, you can shorten the iteration to two or three weeks to lower the risk of having to add an urgent item in the current Sprint.

Solution 3

I have to disagree. I think it is key to the process to have a team focused on a single project during a sprint. If you have some specialists that can't contribute to the entire development process (content authors, graphics people, business process analysts, etc.) I would shuffle them off the team when they can no longer contribute. Or better yet, get them trained up on some different tasks so they can contribute to things like testing.

Another thing to keep in mind is that running projects in parallel kills your schedule. Consider this: for simplicities sake, lets say we have 5 projects using the same team and starting on the same date. Each project needs 3 one months of effort, In the best case scenario running parallel, you will finish them all at once and it will take 15 months. Your velocity will get creamed because you can only fit 1/5 of a month of effort in a single sprint. You'll also be doing 5 demo meetings all at the same time. So best case scenario, you deliver your 5 projects in 15 months and your competition will be claiming they could do the same work in 3. Your teams estimating maturity will suffer because they will only be able to consider 20% of their available labor. You may find that you actually are unable to perform some tasks in a single sprint. If you have to change the number of projects being worked from 5, your team will have to adjust their estimating habits which will damage the teams efficiency. Additionally, your team will find it difficult to self-organize when a simple task reassignment may require spinning up a new dev environment before work can begin.

If you were to run the same 5 projects serially, you'd deliver the 5th project in the same 15 months, but you would have educated your client that your team is in such demand that you have a 12 month backlog and that you can use that time to refine your project goals. Or if you have a constant backlog, you know it's time to start hiring another team. Your best project, however, is finished in 3 months with a client that has seen rapid improvements during the active period. You're able to finish that project a year earlier and can put it on your resume. Your sprint velocity will stabilize over that period of time and you may find that hits its stride after a project or two and are able to accomplish more in a given sprint.

I think running projects serially is one of the biggest hurdles an organization attempting to adopt scrum faces. It's a major cultural change associated with deconstructing the project manager role, but the benefits to the scrum process are huge.

Keep in mind that EVERYBODY does not need to be a full team member. They can be engaging your client in the waiting room, preparing for the development process. I keep my business analysts, network architects and graphics design people as domain experts and only attach them to a team as needed. Let them run with sprint 0. You'd be surprised how engaging working on look-and-feel and workflow is. It's also good to prepare your client with the understanding that when development begins in earnest, their level of participation may actually go up and that it is important for them to be available. Let them know the schedule so they have plenty of time to deal with things like vacations and holidays well in advance.

Solution 4

I have been in this precise situation.

If you have one product owner across the projects then Phillipe is absolutely correct; One sprint with one team should work just fine.

If you have more than one product owner, then ideally the business side needs to choose a single 'prioritizer' who is given the responsibility for scheduling the work. This is definitely the best solution.

If (as is probably the case) the business don't want to change how they want to prioritise things (that would be far too convenient) then you can split the team., and run two concurrent sprints. However with a team of six, I wouldn't split it into a more than 3 teams (I wouldn't want to split it at all, but I think 2-3 teams would be workable). Splitting any further as Kenny suggests, and having teams of a single person seems to me somewhat pointless, as then you no longer have a team, just individual programmers.

If you are splitting the team, I haven't found much value in amalgamating the stand-ups, unless you have separate sprints working on very much of the same codebase, but then that may be an argument to amalgamate those teams for the purpose of the sprint.

Solution 5

There is another opinion I have been reading about lately, namely that in an Agile environment the concept of Project might be counterproductive and could be eliminated. According to this line of thinking, the organization should be focusing on Releases instead. This is because Projects are artificial boxes of work that produce no value until they are finished. They are contrary to Agile's goal of frequently delivering shippable value. A Release is more in line with Agile because it is oriented towards delivering value and because its scope can be reduced or expanded based on what teams can deliver before the next Release.

There is a potential middle ground, in which what was formerly called a Project in your company is now repackaged as the common Agile Theme or Feature. The benefit of this approach is that the Theme or Feature can now be implemented in pieces of value, as the product owner sees fit.

There is still the question of one team working on multiple Products, and it is a question because of legitimate concerns about domain knowledge and possible technical skills. But Products built with Agile, even multiple Products built by a single team, are constantly accumulating Release-able value. In contrast, Projects are worth nothing until they finish (and many do not).

Something to think about...

View more solutions