How to manage working on multiple projects simultaneously?

Can we 'be' agile like this?

An agile anti-pattern that I see, all too often, is when a single team is working on multiple projects (or for multiple clients) simultaneously and switching between them frequently. This usually comes in the form of: “how do we manage our workload and show progress to our clients when we are working on more than one project?”. But you are missing the point when you ask me this question. You shouldn’t be working on multiple projects in the first place - and stop telling me that you need to. You don’t - you just don’t know how to a) say no, or b) plan your work.

When multi-tasking like this, there are a lot of negative outcomes that occur for everyone. From a team perspective, it’s going to be hard to keep the momentum going on either project. From a client perspective, neither client is going to get the focus and productivity they expect - and thus will not be happy. And from a management perspective, it’s very difficult to measure productivity and value. In short, both projects will take twice as long (or more) than they should.

In keeping with the agile principles of limiting WIP, the obvious answer is to focus, and complete, the first project before starting on the second. The second customer won’t be any less happy (they get it as soon as they were going to anyway, but the first client will be ecstatic). You also need to make your team and organisation aware of the issues and the negative impact the they are causing by working in this way.

But what about ...

But this would be a very short article if that’s all it took. Sometimes multi-tasking can be acceptable. For example if a team is working on a primary project, but are also accountable for operational and production issues. This is a very simple DevOps model. The problem here is two-fold.

1. development and maintenance have different cadences, and maintenance cannot usually wait until the next sprint to be resolved.
2. Adding work into an active sprint is one if the biggest causes of failure for an agile project.

Off hand, I can think of three ways you can address this - from least to most preferred.

1. Split your team by moving 1-2 people out of the development team and dedicate them to maintenance activities. They should not be assigned to the sprint. While this is an option, this would be my least preferred.
2. Allocate a fixed block of time in each sprint for maintenance. For example 2-4 story points of effort is allocated to unknown maintenance tasks. Of course, this will reduce the available capacity, or velocity, of your team per sprint.
3. Move to a continuous delivery model by setting your delivery cadence to the fastest - in this case the maintenance activities. I generally recommend a Kanban approach for these situations as they are generally more effective than a Scrum approach. Your team should move away from incremental delivery (and timeboxed sprints) and start operating under a continuous delivery model with a single, managed, backlog. This backlog contains all activities (both new features and maintenance work) and is kept up-to-date and ranked in the intended order of delivery. The team can then always work on the next most important task, regardless of what it is. This also helps to answer the question; “when will X be done?” By measuring lead time* and cycle time** metrics, it is a simple matter of extrapolating how long until X. You can also use cumulative flow diagrams and statistical run charts to visualise your work.

*Lead time - the time it takes for an activity to go from the initial request to done

**Cycle time - the time it takes for an activity to go from start to done