Daniel Heinen
& Konstantin Ribel

Allow us to share the vicious effects we have observed when organizations add additional teams (from vendors) to an ongoing product development endeavor because it is not progressing as expected.

Every new vendor team needs to gain a full-system understanding of the product and how it is developed. How much help they need from experienced teams and how long the learning will take depends on the product complexity.

Consequently, Brooks’ law comes into effect (from Frederick Brooks’ book, The Mythical Man-Month [Addison-Wesley, 1995]):

Adding manpower to a late software project makes it later.

Feature output decreases, and management concern rises even further. Action is expected. The most obvious one is to add even more people. Since it is easier to ramp up (and later say goodbye to) external staff in comparison to recruiting internal staff, the hiring rate of (external) vendor teams rises steeply.

The product group size grows as do the differences between teams in terms of system understanding. However, a common expectation is a maximum utilization of teams and individuals. This leads to fragmentation of work along the current capabilities of the teams instead of organizing for customer value, as can be expected in Scrum. The flexibility in work distribution between teams drops, and the workload of a team on particular specializations increases. Work becomes splintered even more, and the adaptability of the Product Development group decreases. The teams specialize in their field of work and become what are known as component teams.

The usual observed pattern is that teams no longer work on highest-priority items but on items with lower priority just because they are in their field of expertise and add to maximizing utilization.

As people start accommodating this situation, Product Backlog items now start reflecting the technical split between teams (and no longer customers’ needs), and a Product Owner no longer prioritizes for value.

This downward spiral can only be broken with teams mastering the full technology stack and focusing on customer value—i.e., teams becoming “feature teams”.

However, integrating external vendor teams is often contractually limited (think of information protection, etc.) and further endangered by contractual demands of utilization. Such contractual conditions translate into having multiple team backlogs, rather than one Product Backlog, and proxy Product Owners trying to better direct their vendor teams.

Consequently, Conway’s law comes into effect:

Organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations.

The small clusters of component teams working on different backlogs are the communication structures of the organization. Therefore, the design and usability of the software being produced deteriorates. Furthermore, the cost of adding inexperienced developers is overlooked when the Key Performance Indicators (KPIs) are all about utilization. Collaboration across all teams degrades at the cost of losing organizational flexibility and overall performance.

A better approach is to carefully consider whether scaling up is really needed and whether it needs to be done by externalizing the workforce. Prefer avoiding both.

Otherwise, scale slowly and allow learning, observed by a lot of management GoSee to have full transparency upon contractual agreements that focus on collaboration toward customer value.