You have an agile delivery train, so what?

These last couple of weeks I've been visiting some companies that have been on the agile@scale journey for just over a year. I participated in some of the initiatives. What caught my attention in all 3 companies was that the delivery group/train/tribe grew during this time both in number of teams as in number of people per team. 

This movement was driven by the need to "increase the delivery capacity" of the group.

The interesting thing is that, in all cases, either the measure did not have the expected effect or even reduced the productivity.  It is not difficult to understand what happened, increasing people and teams increases the need for coordination and interdependencies. The ceremonies are less efficient and the motivation decreases.

"More people" seems the right answer to the delivery problem and it is easier to justify hiring developers, who do the job, than Scrum Masters, POs, RTEs, ... that in theory are overhead.

All studies show that an agile delivery group is efficient with up to about 130 members and teams with no more of 11 or 12 professionals. Violating these values is not "adapting the framework to our reality” but reducing the efficiency of the team. The data shows that.

Another important remark: the original design of the trains or tribes has practically not changed since its formation (only their sizes). 

The assumptions that led to the original organization (number of teams, their purposes, functional and component teams, etc.) wasn’t questioned after its launch. That's a mistake! The configuration of teams and trains is a hypothesis like any other in the process. It should be checked constantly and not reevaluating it in each cycle means losing an opportunity to improve all indicators, including delivery capacity: productivity.

Next week we will facilitate a session of Value Stream Mapping (VSM) precisely to address a situation like this. What started just over a year ago with 3 agile teams, became a giant train with more than 250 personnel involved. I'm convinced there's an opportunity for giant improvement in this group.

Revalidating the organization from its purpose, which may also have changed over time, and based on collected data in a systematic way as a workshop of VSM is a great opportunity for learning and alignment for all involved: business and delivery.

Inspecting and adapting regularly is not being "by the book"!  I&A is part of the essence of being an agile organization and is not optional!