Predictability at Scale
When multiple teams are working together towards a common goal, achieving predictability becomes a harder task. Here are some key points to remember.
A great deal of uncertainty comes from dependencies across teams. Streamlining dependencies is an important task. Some of them will certainly transpire only when working on the problem, but some can be proactively identified and managed. For that to happen, teams need an ability to identify them together. It is possible to do this as a result of cross team planning (with teams actually involved) or joint backlog refinement sessions, for example. It is important though that team are given an opportunity to directly interact with one another. A much less effective approach is when someone tries to identify dependencies for the teams. Or even teams trying to do this but in isolation from one another. So, that is for dependencies that can be proactively managed.
But in large, complex tasks there always are emergent dependencies, the ones that only transpire once the teams start doing the work. And it is very important here to respond to them quickly and effectively. So, not only planning or work refinement requires collaborative, cross-team effort, but also execution. Regular cross-team touch points are a good way to help respond to emerging dependencies. Besides, frequent cross-team integration of the work product helps spot inconsistencies that otherwise are discovered too late in the process.
But just for a second, let’s take a step back from managing dependencies and look into why we have them in the first place. See, it is quite likely that the team structure is such that to deliver any meaningful customer value, any more or less complete function, you always need multiple teams. And it may be that more collaboration is required across teams than within teams. But that contradicts with the notion of a team. It raises a question: Why would you have a group of people called “team” if those people have a lot more to do with their colleagues outside of this group? A restructuring may be needed. If your teams are built around skill areas or architectural components, you almost inevitably get lots and lots of cross-team dependencies. On the other hand, if they are structured around customer requirement areas (which usually requires people from different functions to be on a team), there will be a lot more collaboration inside and less dependencies on the outside parties.
Also, please keep in mind that there may be dependencies on other participants of the process, not just other teams, in a conventional sense. It can be some special subject-matter experts, like an architect or a UX designer, and so on. Or maybe it is a stakeholder that brings and clarifies requirements or validates solution deliverables. But a lot of what we’ve so far discussed applies to these cases, too.
Other factors to pay attention to
Now, there are also other potential sources of uncertainty at scale that might need addressing, depending on the context. Quite often it is a stale codebase or significantly deteriorating solution architecture that may also need addressing. And as the codebase gets bigger and bigger, it becomes harder and harder to understand (even to those who created it in the first) place; simply because of the vastness of it. But if the problem is also multiplied by poor development practices, it may quickly spin out of control.
Lastly, some degree of uncertainty is inherent to complex work, especially at scale. The goal is not to fully eliminate it; that’s simply impossible. The goal is to find areas where uncertainty is introduced due to ineffective process and improve it.
Alright, so, touching on some common issues that impede predictability at scale, probably gave you an idea of where to look in your case. Plan a few concrete actions items to improve predictability in your large-scale development effort.