Agile cross-team collaboration HOW-TOs (4-part)
This post is a four-part deep dive into the How-Tos of making Agile cross-team collaboration frictionless and enjoyable, in one word: effective. That is one of the most consequential topics for successfully adopting Agile beyond one team. Ironically, none of the current “scaled” solutions cut it.
PART TWO
When is Agile cross-team collaboration really needed?
Every time there is a piece of work, like a Backlog item, that benefits from or needs 2+ teams to collaborate to get it done, good cross-team collaboration becomes essential.
Some collaboration can be a beneficial opportunity (to access more skills and creativity to find a better solution, for example). As such the teams might opt for it if they choose to.
Some collaboration can be the most effective approach to accomplish a goal (involving those affected by the problem in shaping a solution, for example), and such synergy is beneficial and just as much optional.
While other collaborations come as a necessity that forces the teams to collaborate. Think for example of some cross-team dependencies: technical, product, business, expertise, information, material, social, economic, political, or authority.
The most common cross-team dependencies forcing 2+ teams into cross-team collaboration are technical dependencies, which the book Team Topologies refers to as blocking team dependencies. Because they block the flow of work, cause delays, and kill productivity. Here we extend the use of that term and its meaning to also include non-technical team dependencies.
Blocking team dependencies can and should be turned into non-blocking team dependencies, those that do not block the flow of work because they do not require the teams to wait for each other. This can be achieved, for example, by applying one of the approaches described in the book Team Topologies.
Turning all blocking team dependencies into non-blocking team dependencies takes some time, because of the magnitude of the effort required or the immaturity of the service/platform for example. During that time, and even after, some cross-team collaboration remains a necessity.
Possible synergies and beneficial opportunities for cross-team collaboration can present themselves anytime. Like when creating an innovative product, or working on cross-cutting features such as GDPR or Internationalisation or Accessibility across the product suite.
And professional software and digital products and services development have a strong social component too.
For all these reasons, good cross-team collaboration remains essential, always, and this leads us to Agile cross-team collaboration.
Agile cross-team collaboration, as intended here, is a good cross-team collaboration that involves Agile teams, and is carried out in a way that does not hinder the Agility of the individual teams while fostering the Agility of the collaboration and the whole system of teams.
The How-Tos of Agile cross-team collaboration are presented next, preceded by two paragraphs with two must-know.
Must-know: Not all dependencies are created equal
Some of the most common cross-team dependencies found in a piece of work (a Backlog item, a User Story), are technical. This is why the literature on the topic is vast in software development. More in general, there are many non-technical cross-team dependencies too: product, business, expertise, information, material, social, economic, political, or authority, for example.
All technical and non-technical cross-team dependencies can be
- Essential dependencies: those that cannot be eliminated;
- Accidental dependencies: those that usually have been added by mistake, inexperience, lack of effort or quality, as a temporary solution, etc. and now can and should be eliminated.
The dependencies that are relevant when discussing Agile cross-team collaboration are all the technical and non-technical cross-team dependencies and hand-offs needed for a piece of work (a Backlog item, a User Story) forcing 2+ teams to collaborate together to get the job done. As mentioned before, we refer to them as blocking team dependencies.
They are all the essential dependencies that cannot or have not yet been changed into non-blocking team dependencies, plus all the blocking accidental dependencies not yet eliminated.
Must-know: Clean the mess first, and keep it clean thereafter
One fundamental learning from Agile software development that sets it apart from the traditional project and programme management is that:
- the effort to manage dependencies is orders of magnitude bigger than the effort to eliminate accidental dependencies and relax the remaining essential dependencies.
Consequently, every time one is confronted with a decision between managing the dependencies vs. eliminating dependencies and relaxing remaining dependencies, the elimination is always the best choice by far.
Ron Jeffries here says: Eliminate dependencies, don’t document or accommodate them.
This idea is pitched here and expanded in principles #2 and #3:
A few ideas on how to eliminate accidental dependencies and how to relax and deal with remaining essential dependencies are listed here in #2.b:
The book Team Topologies advocates applying on an ongoing basis the inverse Conway’s manoeuvre to stream-align teams within streams of business value to minimise cross-team dependencies and hand-offs. It also suggests changing blocking team dependencies into non-blocking team dependencies. As a result, it minimises the cross-team dependencies across the streams and allows stream-aligned teams to work within a fast flow.
The Team Topologies approach is based on team-first thinking which is the foundation of any good Agile team. If your organisation is not there yet, this is where it should start, even before looking at Agile cross-team collaboration or any Agility beyond one team (see for example principle #6 here, http://p2.fed.wiki/view/part-2-collaborating-at-scale).
Team-first thinking implies that the teams are stable and long-standing with team members fully dedicated to a single team. Team-first organisations typically budget products/services and prioritise initiatives instead of budgeting projects and optimising resource utilisation.
In typical Agile fashion, it is also essential that large initiatives like traditional programmes and large projects taking years or involving many teams are broken down into much smaller initiatives. Each one of them quickly delivering business value and learnings, and involving only a few cross-team dependencies if any at all.
The book Team Topologies also discusses the Interaction pattern X-As-A-Service (XAAS), where one team provides another team with an API, a tool, a platform, a sub-system, or a whole software product. It results in a non-blocking dependency between the two teams.
It is worth pointing out that instead many organisations make a common mistake. That is to form a global function or central team (like a dedicated DBA or Release team or a Back-end team) creating even more blocking team dependencies:
- for the wrong reasons (e.g. to centralise a function that becomes a silo, to add an approval gate that adds delays, to cut costs but kill productivity), or
- prematurely (far before the API, the platform, or the component can be consumed as a service, when instead each request of a new client to use the API leads to significant ad-hoc work, multiple iterations and intense communication and interactions across teams).
The technique described in the book The Mikado Method can help refactor the code when eliminating technical cross-team dependencies or changing them from blocking to non-blocking.
In conclusion, the overall approach to enable teams’ fast flow requires a) paying constant attention to spotting and removing any new accidental dependencies and relaxing those essential dependencies that are causing delays and wait time; and b) keeping teams aligned to streams of business value and the underlying architecture to minimise cross-team dependencies.
To summarise
- The top priority is to: Clean the mess first and keep it clean thereafter to create a fast flow
- And after it is also necessary to: Continue creating good frictionless cross-team collaboration.
This is because while point 1 is the top priority, and it cannot be stressed enough, it will never completely remove the need for cross-team collaboration so point 2 is also needed too because
a) removing all blockers to fast flow takes time meanwhile cross-team collaboration will continue;
b) some essential dependencies cannot be removed ever or until stable boundaries emerge meanwhile cross-team collaboration will continue;
c) there are cases where cross-team collaboration is desirable and advantageous like with pair or mob/ensemble programming, and in those cases cross-team collaboration should be made as frictionless as possible too.