The invisible cost of double jobbing for shared resources in Agile

The stated ‘best practise’ of Scrum-flavoured Agile software development (and therefore the target state of many transitioning environments) is a self-organising, cross-functional collection of individual resources capable of delivering whatever they agree to deliver, within a time window and within the resources (including skills) they have available to them, along with someone to coordinate and facilitate their activities and someone to ensure they are working on the next most useful bits of work. All very fine and all generally very achievable. We see this setup everywhere.

In many Agile software development environments, there comes a time when the Team needs the input of specific knowledge, skills or expertise which is otherwise not normally part of the Team.

This could be a senior Technical Architect, Database Architect / Administrator, a business Subject Matter Expert or some other skill set not included in their routine multifunctional capabilities but required open an ad hoc basis to address a specific requirement.

In these cases, this external contributor is often invited to participate in some aspects of the analysis, design and development process. Of course, in organisations with multiple Teams, this external expertise might be in demand on occasion by multiple Teams, and sometimes at the same time. In situations where the demand is ad hoc, this is generally not a huge problem and it is a normal part of the multi-Team coordination that goes into Agile software development beyond a single-Team setup. Expertise required by a Team, on occasion, is brought in, on occasion. Again, all very fine and all very achievable. We’ve seen this model in lots of places too.

However, it is a very different situation when a specific resource is permanently assigned to more than one Team. This might be a Developer resource assigned to two teams continuously, or a resource moved from Team to Team as required but where s/he is always assigned to more than one Team at a time. This happens more regularly than Agile & Scrum guides seem to think and it can be more costly than it might appear to be on first look. In extreme cases, the shared resource might be so busy by just being a shared resource that they have little time left to actually contribute.

In fact, even the most experienced and evangelical proponents of Agile methodologies might be surprised at just how costly it can be – because much of the ‘cost’ is usually invisible, especially (ironically!) to those in the Teams that the ‘shared’ resource is assigned to.

This problem is not limited to Agile. It affects all sorts of scenarios where a single resource is required to provide input into multiple teams, projects or activities on a recurring basis. However, it is quite a lot more common in Agile than most of the books and articles describing how to become Agile seem to indicate, mostly (ironically, again!) because of the ‘best practice’ cross-functional, self-organising Team. Much of the theory assumes a single Team will always have all the cross-functional capabilities that it needs to self-organise properly in order to deliver the next-most-valuable requirements. When that Team needs outside help, it’s assumed that it will be provided. However, not much is written about the cases where that outside help is required every Sprint but by multiple Teams… just not enough to justify an additional full time Team member. But little thought is given to the ‘cost’ of splitting a Developer’s time between teams.

In other Sectors, the effort required & time lost to ‘move’ from one activity to another can be easier to see. For example, imagine the shared resource is a vehicle. It is required by more than one Team for different purposes during the same time window. There is an obvious ‘cost’ to this transition (i.e. someone has to transport, collect or otherwise move the vehicle – and maybe even prepare it to make it ready for the next use).

We sometimes forget that the same applies in ‘knowledge’ activities. In psychological terms, this is called ‘context shifting’ and it incurs a cost. The more often someone has to shift contexts (e.g. projects, products, teams, scenarios etc), or the more contexts they need to switch in an out of, the more the cost. This is one of the reasons why, in Kanban-like Agile scenarios, there is the concept of WiP (Work in Progress) Limits: to minimise the simultaneous contexts that a Developer needs to be contextual aware of, ‘front of mind’. We are very aware of this within the Development Team and we try to minimise the work that is in progress or active at any one time. However, it is not always taken into account for external, occasional contributors. This is the subject for another discussion (there are many empirical studies to show the ‘cost’ in terms of lost Development capacity, if you want to look online).

But there is another, more obvious – but, strangely less considered – impact of shared resources when the shared resource is regularly required to be part of the work that a Development Team delivers.

Consider a situation where a Product Owner is responsible for a Product that requires multiple Teams to deliver. In Scrum-like Agile scenarios, there is a single Product Owner. S/he is, therefore, a shared resource across Teams on a regular, Sprint-by-Sprint basis. The same applies if a single Scrum Master is responsible for facilitating the activities of multiple Development Teams. Of course, this specifically relates to Scrum-based Agile but the same issue arises in other flavours of Agile.

Apart from all of the overhead that a Product Owner or Scrum Master has to contend with in these cases (which an experienced resource is probably capable of dealing with), there is the even more obvious issue of the various activities (‘ceremonies’) that happen during the regular iterations. In any Agile development methodology, the Team has different activities which repeat per iteration and this means the ‘cost’ accumulates (possibly invisibly) over time. Since the individual resources who actually ‘produce’ the value from Sprints are the developers, not the Product Owner or Scrum master (sorry, guys: you’re just there to make the Developers more productive!), it makes sense to minimise any unnecessary ‘loss’ in Developers’ capacity to deliver.

By way of illustration, imagine, for example, a Scrum Team that operates a 2-week iteration. During that iteration, they will have time allocated to Backlog Grooming, Sprint Planning, Daily Standups, Sprint Review and Sprint Retrospective. All Scrum team members are required to be at all of these meetings. This could easily be 20% of their time. Multiple this by 3 Teams and it could easily equate to 50-60% of their time, leaving only about half their time to do all of the other things they need to do. Add in the subconscious ‘cost’ of context shifting and it becomes clear that a shared resource can easily – and quickly – start to lose their ability to contribute to their best ability.

While this might be seen as simply a cost of having an experienced resources shared across multiple Teams, this cost can have a much higher impact where the shared resource is a Developer because their efforts contribute much more in a cross-functional, self-organising Team.

While some on the outside might think a good Developer should be able to switch in and out of multiple Teams (‘contexts’), the same way as they switch from one User Story, PBI or Feature to another, it is not as easy as that. Humans (yes, even including Developers!) are not machines. At the extreme, it could even lead to a very effective professional becoming less effective than a junior teammate, affecting the quality and pace of delivery of the whole Team. It can even lead to complete burn out.

Besides, it’s simple maths:

Assume a 2-week Sprint cycle. The Scrum guide specifies that each Team member should attend:

• 10 * 15 minute stand ups (=>150 min => 2.5 hours)
• 4 hours Sprint Planning (2 to 4hrs per Sprint, longer for newer Teams)
• 1 hour Sprint Review
• 1.5 hours Sprint Retro (1 to 1.5hrs, longer for newer teams)

In total that is 9 hours across two weeks, or 4.5 hours per week.

Note: Backlog Grooming is explicitly excluded here for convenience but included in the overhead mentioned below

Now, assume the Developers’ capacity is 100% assigned to Team A. That equates to approx 60 to 70 hours per Sprint. Let’s say 65 hours per Sprint (32.5 hours per week), to allow time for all the other things that employees have to do.

Deduct the 9 hours of Sprint ceremonies from the 65 hours capacity and the developer can allocate 54 hours to delivering on the Sprint goals. In reality, it’s probably best to leave at least 10% headroom, especially for newer Teams. Backlog Grooming alone is recommend as up to 10% of Sprint capacity in the Scrum guide so 10% overhead is conservative. So, let’s say no more than 50 hours effective development capacity.

Now, assume that the Developer is assigned to Team B for a series of Sprints. For convenience, let’s split the assignment 50/50 to Team A and Team B. It might seem logical to think: “OK, so that means the Developer can allocate 25 hours to Team A and 25 hours to Team B in a given sprint.

But, no. Remember, each Team has it’s own Sprint ceremonies and each team member is required to be at them. This is not about vague ‘team bonding’ or ‘all in this together’ cohesion. It’s a necessity of good Agile development: these ceremonies are where all the communication, conflict and clarification happen. This is where decisions get made. This is, in the purest of agile terms, where ‘self organising teams’ self-organise and continue to self-organise throughout the iterations.

So, let’s look at this again:

• 9 hours per Sprint are allocated to Sprint ceremonies.
• For two teams, that means 18 hours.
• Deduct this from the original 65 hours capacity and the remaining Development capacity is 47 hours.
• Leave 10% headroom per each Team and this comes down to 37 or so hours of Development capacity… split across two Teams.

Effectiveness for both Teams declines significantly.

So, simply by assigning a Developer to two teams, the organisation instantly loses about 12 or more hours of capacity (i.e. close to 20% of the headline figure of around 65 hours).

Assign that Developer across three Teams and the effect is worse (obviously!). In that scenario, development capacity reduces to a total of approx 20 hours.

• 3 collections of Sprint ceremonies => 27 hours or so.
• 3 times 10% Backlog Grooming and overhead => 30% of 65 hours (18.5 hours).

That’s around 45 hours without doing any Development. Split the remaining 20 hours across three teams and delivery will suffer drastically from that one resource. Instead of having 50 hours of Development capacity across a Sprint, the same resource only has 20. Now multiply that by multiple sources.

The ‘loss’ increases as the number of assigned Teams increases. Taken to the extreme, allocating a single Developer resource across 5 teams would probably mean s/he doesn’t have time to do anything except attend Sprint ceremonies.

On a side note, some (naive) Resource allocation people might think it doesn’t matter what percentage of the Developers time is assigned to Teams. They get a demand for increased resources and assign the minimum hours available, on the basis that a small allocation is better than none. In fact, its the opposite. A small allocation simply reduces some other Team’s capacity while allowing the resource to contribute very little for the new/extra Team and decreasing overall (i.e. combined) delivery capacity.

I once had a Senior Developer assigned to my Team for 1 hour per day to ‘help’ with the more junior team members. I quickly asked for that resource to be removed and another (less skilled) Developer’s allocation to be increased instead. Why? Because no matter how brilliant the senior Developer was, if s/he can only contribute 10 hours over a Sprint, all s/he could realistically do was attend Sprint ceremonies. While that might be good enough (in some Organisations) for an advisory resource like a DBA or Architect, it is pointless for a Developer.

In summary, Organisations that operate in an Agile way should be very cognisant of, and very careful to avoid, the personal and development costs of over-stretching their shared resources, especially the Development resources. While that is a nice ‘fluffy’ target to aim for, the more data-drive, cost-conscious, time-aware resource allocation people (including managers in many organisations) should also realise – and be more interested in the reality – that they are actually decreasing delivery capacity on an aggregate basis when they allocate Developer resources to more than one Team. In simple terms, for each team that a given Developer is assigned to, s/he costs the same but can only deliver 20% less, per team. Assigning a Developer to multiple teams is not only bad for the Developer, bad for the Agile methodology in the Organisation and bad for capacity & velocity… its also bad for the bottom line.

Note: the above all assumes the resources are full-time employees. If they are not (e.g. provided under some managed services contract) it might be tempting to say “Yeah, it’s OK. Someone else is paying for that lost capacity”. That is naive in the extreme, as the Developers’ combined overheads are factored into all Contracts, implicitly (they have to be, or the Managed Service vendor wouldn’t survive).