The performance of software delivery teams is so often undermined by team members being shared with other teams or regularly borrowed for operational support and other emergencies.

We know that small, collocated, cross functional teams provide optimum performance. So why is it so difficult to have a small group (7 +/- 2) dedicated and focused on one project at a time?

One major reason is that organisations have too much Work In Progress – WIP. Just count the number of in-flight projects and then count the number of teams available to deliver them. If there are more active projects than teams then there is too much WIP. Reducing the number of active projects results in a dramatic increase in the rate of value delivered to customers.

Let’s explore why spreading people across multiple projects is so detrimental:

Switching Cost

it takes time to get our head around a problem domain and then find the relevant bit of the system to work on. The more switching of business and technical domains, the more loss through spin up time. There is much research and writing on this topic, here are a couple of references: 

In their excellent book, PeopleWare, Tom DeMarco and Tim Lister describe: "flow”, a state of deep concentration necessary for “high-momentum” tasks such as engineering, design, development, and other aspects of building software. It takes 15 minutes or more to achieve this state and only a moment to lose it. Every time a team member is interrupted, it costs the company fifteen minutes while they re-enter a productive flow of work. 

In another great book,
Quality Software Management: Systems Thinking by Gerald Weinberg, he estimates that there is a switching cost of around 20% for every project that a team member is shared across. The impact of switching cost on a team member’s available time is illustrated nicely by this graphic:

Blocking

Solving complex problems requires close team work with swift collaboration. When a colleague switches to work with another team, any unfinished work they were involved with can block progress of fellow team members. In the worst case, the original team may have to wait for the team member to return before completing a highly specialist task. Over specialisation is another issue that drives organisations to share people across multiple teams but I’ll save that for a future blog.

Dilution

It takes a focused effort to gain and retain a sufficiently deep understanding of a complex business and technical domain. Attempting to achieve this feat across multiple simultaneous projects, leads to a shallow veneer of knowledge and a poor basis for smart decisions and design.

Excuses

Being shared across multiple projects erodes commitment by providing places to hide, and we hear this sort of thing: “Sorry I didn’t get my stuff done because I was working on the other project”.

Deployment Contention

In most organisations, fully live-like testing environments are rare and expensive resources that are vital to ensure the software is of sufficient quality to release to production. Like a crowd of people trying to get through a single small door, these environments become a bottleneck on a project’s journey to live deployment. The greater number of projects in-flight exacerbates this situation, leading to a queue of projects and delaying the delivery of value to customers.

Meeting Overhead

Very little software is actually developed in meetings so we try to minimise our meeting overhead to just enough and just in time. However, even with an Agile approach like Scrum it is necessary to spend some time in meetings; as much as 15.5 hours for one team member in a 2 week Sprint. The more teams a person is shared across, the less time they have to actually develop software – see the numbers below:

The numbers below are worked out assuming:

• Scrum
• Working time of 6 hours per day (minus breaks and non-project time)
• 2 week Sprint
• 60 hours available per person per Sprint

Meeting time per person per Sprint:
     Sprint Planning 4 hours
     Sprint Review 2 hours
     Sprint Retrospective 1 hour
     Backlog Refinement (10% max) 6 hours
     Daily Stand-up 2.5 hours
     Total 15.5 hours

Impact of meetings as numbers
of projects increase

Summary

Of course, all these problems tend to be cumulative. So for example, the reduced time for actual work caused by multiple projects is further compounded by the switching cost, leading to very little productive working time.

Organisations that accept shared team members as an inescapable reality, must also accept the reality that their teams are never going to perform as well as they would like.

So the bottom line; reduce the number of simultaneous projects and focus team members to one team and one project at a time to increase the flow of value delivered to customers.