Problems for Teams planning with Shared Resources

Recently I’ve been seeing a growing number of cases where the use of shared resources by several teams becomes a real nightmare, especially if the resource is working simultaneously in two or more teams.

One of the most common causes that I see is the lack of definition and planning of the shared resource’s availability. Additionally, there’s also the fact that each team leader will try to maximise the usage of the shared resource taking into account the project needs, completely ignoring other projects priorities (we can't blame them, can we?).

I've been observing that the lack of definition/organisation originates, most of the times, an over-commitment by the shared resource, since she’s not in control of her own availability. As a consequence, the teams that she’s part of will suffer because of that, since she will not be able to provide the necessary contribution that she committed to.

Now, before continuing, I think it’s important to ensure that the concept of shared resource used in throughout this article is clearly understood by the reader.

The Specialist

The Specialist is the type of resource that, although not being part of the core team, has an important role in certain moments, as her specific skills are required by the team to develop/optimise the solution.

This type of resources cooperate with teams in very specific moments and for a limited period of time, during which they execute a set of very specific tasks. These resources are, by nature, shared by the several teams and usually have a limited impact when planning the team activities.

Core Team Member

As the name mentions, she’s part of the core team. This means that, without her, the team will struggle to deliver the solution. This type of resources are part of the day-to-day life of the team, contributing with their work to execute the several tasks and ultimately, to deliver the final solution.

Changes to the availability of the Core Team Member have a direct impact on the team’s capacity to reach the iteration goal. As such, sharing Core Team Members adds a high degree of risk to the project, contributing decisively for a number problems and difficulties. It’s precisely about the sharing of Core Team Members that this article is all about.

Now that we’ve set our common ground, let’s try to understand the origin of this problem and how the side effects can be minimized (it's important to mention that I don’t support the sharing of Core Team Resources).

Lack of Strategic Planning

As strange it may seem, in most of the cases I've seen, the shared resource is not directly responsible for the problem. After all, if she’s shared by two or more teams, there has to be someone that has the responsibility to establish the priorities of the different projects and teams in order to be aligned with the context and strategy of the organisation. Without this strategic vision, it’s becomes very difficult (if not impossible) to properly allocate the shared resource. Only with a clearly defined strategy, the shared resource will be able to define her availability accordingly and make adequate commitments for the teams she’s part of. 

Incorrect Capacity Assessment

One of the most important aspects for a team during an iteration is their initial planning. It’s during the iteration planning meeting that the team will determine their capacity to implement and commit with a set of PBI’s (Commitment Driven Planning – as described by Mike Cohn). With an incorrect capacity assessment, the shared resource doesn’t have a clear picture of her real availability for the team, leading to a commitment that most of the time is either under or above her real capacity. As such, consequences are obvious and they jeopardize team’s success in the context of the iteration. This is especially true (and painful!) when the shared resource over-commits. This becomes more or less serious depending on the size of the commitment, the criticality of the project, etc.

How to tackle

As a first step, I believe it’s very important to ensure that there is a shared resources strategy, with a clear vision defined on the priorities. It may be that the prioritisation is simply based on a first in, first serve approach when it comes to the availability of the shared resources. Or that a resource cannot be allocated to more than two teams at the same time or even a mix of both. Whatever the strategy or the prioritisation approach is, it must exist, be clear and visible for everyone, which is precisely the subject of the second step described below.

In a nutshell, the second step is to guarantee that the strategy is visible to everyone, including its outcomes. In other words, if someone is not happy with the availability of a shared resource, she has the possibility to check the “why” and/or challenge it next to her managers, suggesting changes and demonstrating that the current status doesn’t serve the interests of a particular team and/or project.

Finally, during an iteration planning meeting, the shared resource should rely on the allocation strategy defined and the corresponding prioritisation to clearly and unequivocally state is availability to the team during the next couple of weeks. This availability will be used by the team to analyse how far they can commit to the implementation of the PBI’s that contribute to the iteration goal defined.

Final Considerations

As a final note, I would like to mention that solving the planning problem of the shared resource’s activities may not be enough. Although by solving this problem you may have a more clear vision on the resources’ availability – which obviously makes planning and committing more reliable, I've seen that other (more complex) challenges usually surface. As an example, the constant switch between teams that each shared resource has to go through. This approach creates an overhead, not only because of the waste generated by the context switching but also due to the frequent barriers originated by daily availability of the shared resource. For instance, if a shared resource is working with a team in a specific moment and her collaboration is needed by another team, a dependency situation is created which will affect at least one of the teams and will eventually jeopardise its normal progress.

Because of this, and although I’m writing about possible ways to minimize the impact of shared resources (Core Team Resources), I don’t recommend this approach! A core team should remain a core team for as long as possible, without being interrupted as described here.