It’s not all about the team.
For Agile to work in a large program or a large organization, the cross-team issues are even more important than how well teams function individually. This is a common phenomenon in the world: that relationships between things are even more important than the things.
What does not work well for managing the cross-team issues is old school hierarchical autocratic management. Too many issues span cross-cutting subsets of teams, rather than some nicely defined sub-hierarchy. For example, a portion of teams might all be creating microservices that are part of a larger system, and an issue has come up that affects all microservices: that issue does not map nicely to a sub-hierarchy of teams. Somehow, the issue needs to be brought to just the teams that are affected, discussed, and resolved.
This kind of cross-cutting issue management is the norm today, as systems have become more complex, and work is more just-in-time, requiring just-in-time issue-focused collaborative decision-making. Let me emphasize: the issues that need deciding right now often cut across teams and across hierarchies.
What does not work well is to have autocratic leads figure it all out.
What does not work well is to have autocratic managers or tech leads figure out all of the answers and dictate those to those who need to know. That does not work well because (1) the lone decision-maker is often wrong (more often than not), (2) doing this destroys morale, (3) teams become dependent on the individual decision-makers, and (4) teams become passive and wait to be told what to do.
What does not work either is to “leave it to the teams”.
What does not work well either is to “leave it to the teams”, hoping that multiple teams will self-organize around the cross-cutting issues. In my experience, that rarely happens. What happens instead is that teams become silos, and the cross-team issues suffer from a “tragedy of the commons” whereby they languish and go unaddressed.
And since the cross-team issues are the important ones, this tragedy of the commons becomes a tragedy for the organization. The platform becomes brittle, feature lead time gets stuck at three months (or longer), and there are chronic production issues that seem to always have a different root cause.
What is missing is leadership, but the right kind of leadership.
Some organizations have tried to solve the cross-cutting issue problem by defining cross-cutting structures. Spotify’s guilds, tribes, chapters, and squads come to mind. However, each of these has a designated leader, which is significant, because leadership is critical—the right kind of leadership. The wrong kind can be toxic.
Servant leadership has been misinterpreted by the Scrum community.
The right kind of leadership is servant leadership. Unfortunately, servant leadership has been misinterpreted by the Scrum community, which takes it to be little more than facilitation and impediment removal. Real servant leadership is much more than that. Real servant leadership carries responsibility and accountability with it, and operates by actively watching for issues, making sure those issues get discussed by the right people, and get resolved in a timely manner.
Real servant leadership is not autocratic most of the time, but it can be on occasion; the proviso is that if a servant leader makes an autocratic decision, they do so after honest discussion, and they take responsibility for it, no matter the outcome. They have the team’s back, and the team knows it.
A servant leader also makes it a main focus of theirs to ensure that the team is learning and growing its capabilities, is learning to make its own decisions, is operating with minimal conflict (debate is not conflict), that all opinions get heard, that discussions are Socratic and respectful, and that morale is high, because those are the things that make the team effective.
Being able to propose ideas in a manner that generates Socratic discussion is a critically important skill.
An effective servant leader also benefits greatly from understanding the work that the team does. No one attribute of a leader can be said to be indispensable, but knowing the work of the team is an immense benefit, because it enables one to understand the issues, to perceive issues that are being missed by the team because they are too “heads down” to notice it, participate in discussions and problem solving, and even suggest solutions.
Yes, it is important that a leader be able to propose solutions, in a manner that generates honest discussion. That is a skill, and an important one. It is perhaps the most important leadership skill in my opinion.
Go beyond the root cause.
I often hear leaders ask their teams to determine the root cause of a problem. However, one must go beyond the root cause: one must ask, what are the “meta” processes that would have prevented that root cause? For example, if a team makes an error and a bug reaches production, a root cause analysis might inform the team that the root problem was that a particular team member did not include a particular unit test case.
Do you systematically manage risk?—and in a manner that preserves agility?
There is a different way to look at the same situation. Programmers will miss test cases: it is inevitable. How can you increase the odds that critical misses will be caught before the code reaches production? Are you measuring your test coverage? Are you performing routine automated integration testing across teams, and measuring the coverage of that? Are you using both test data and production-like data for your cross-team tests? Are you first deploying the application changes in a limited “blue” mode and gradually scaling up to “green”?
My point is, there are practices that provide a safety net to trap problems before they become real. How complete is your safety net? An inadequate safety net is a “meta” root cause of every production incident. A leader needs to make sure that the right amount of safety netting is in place. The teams can design it, and can debate about what is “enough”, but the leader needs to have the final say about what “enough” is. And it needs to span teams—not be limited to the scope of each team.
Is your safety net Agile?
Traditional risk management practices focus on checkpoints: having everyone “sign off” that they have done their part and are comfortable with code being “promoted”. That is old school and slow. Modern continuous delivery methods are continuous. The checking is real time and automated, and the “sign off” is on the process. For that to work, the process needs to be sufficient, and to know if it is sufficient, you have to be measuring or assessing the completeness of all of your types of tests.
To achieve that, you need continual retrospective on your continuous delivery practices; and not just of your component pipelines, but more importantly of the integration of your pipelines, across your teams. In other words, you need to see all of your teams as a system, and be continually optimizing that system, from both the perspectives of risk and speed. That continual cross-team retrospective and optimization requires leadership to orchestrate it and make sure it happens and is sufficient.
In summary, if you do not have effective leadership across your teams, your teams will operate sub-optimally, with performance that seems to be stuck, and you will likely not have an adequate safety net that protects you from potentially disastrous production issues.