It’s Not All About the Team: Cross-Team Leadership

The Agile Manifesto refers to a software development "team". Extreme Programming (XP) refers to a "team". Scrum refers to a "team". But what if you are building something that is too big for one team to handle?

Leadership spanning teams is also needed. (See the LinkedIn article, Agile at Scale Requires a Special Kind of Leadership.) How do issues bubble up to product level of program level leadership? Cross-team issues are often intractable unless management steps in. How do you ensure that product level leadership knows what the real problems are? Do they "Gemba walk"? That is, do they actually listen in on standups of various teams? Do they talk to tech leads? Do they sample what the programmers are thinking in safe one-on-one conversations? Or do they merely ask for status reports and short slide decks?

The focus on a single team indicates the small-project focus of early Agile, and so it is no surprise that when people tried to apply Agile ideas to large and complex things that required many teams, that there was a-lot of frustration that there was no clear answer for how to "scale" Agile. It was finally the organizations that developed "DevOps" methods that solved the problem on the technical side, and the concept of a "Lean portfolio" that provided a workable model on the business side.

One argument that I have heard is that one should decompose software into small independent pieces, and so then teams can operate independently. However, while decomposing things is good, and trying to make them independent is also good, if all components are fully independent, then you don't have a system - you have many independent parts that have no relation to each other. Sometimes, to do big things, that is not sufficient: you need a big thing, or many inter-connected things - to do something big or hard. The Apollo Moon rocket required many pieces, and they are all quite interconnected. A great deal of work was done to get the part count down, but there was a lower limit.

When I work with financial institutions, there seems to be a most-common program size in terms of number of teams, and it tends to be around 30. That is, organizations seem to divide things up into parts of their platform, such as payments, valuation, and so on, into business areas, and those tend to be of the order of 30 teams in size to maintain the software. I can't explain the number - this is just an observation. Systems that are connected to outside the program - beyond the 30 or so teams - are usually seen as "external", even if they belong to the same company.

I am not going to consider here how an organization should be structured, or how many teams should comprise a program or product. The fact is, there are often many. That's all I need to know.

The challenge is to get those teams to work together on a single set of things that are highly interconnected as part of one or more business value streams.

The most common malady that I find in my consulting today is that organizations excessively "leave it to the team". In particular, they assume that the teams will collectively self organize to figure out things like integration testing, dependency management, and design cohesion. I usually see pretty good efforts on design cohesion, because organizations usually have architects who have been repurposed into Agile architects, and those people think about design cohesion all day long.

Where things tend to fall down is in the continuous delivery practices that need to span teams. I tend to see very inadequate collaboration in that area; and leadership usually does not know what to do. They often have meetings with the team leads, and complain, but nothing changes. What is needed is more leadership, in which issues are asked about, and a list is maintained, and the leads are challenged to propose solutions, and those solutions get discussed, and implemented, and measured. And all that needs to be done with DevOps expertise injected, often from outside the organization, because there is seldom sufficient DevOps expertise inhouse.

That's the reality that I see, again and again. I know that Scrum insists that teams self organize, but it says nothing about how multiple teams interact, and my experience is that they do not organize themselves sufficiently across an entire product or program. Someone needs to make that happen, and drive it, and focus on it, like with anything that is critical and needs to work.