PART FOUR

Should cross-team collaboration be embraced or avoided?

When thinking about collaboration inside a good Agile team, what usually comes to mind is a very positive and fulfilling professional and social experience.
An environment where people constantly learn from each other, experiment, achieve more than they thought they could, enjoy the energetic creativity of the group, and succeed together. Some of those that experienced being in a good Agile team did not want to go back anymore. Some of those that tried synchronous collaboration – for example,  working in pairs or mob/ensemble programming – did not want to go back anymore.

So why are many experiences of cross-team collaboration painful, leaving bad memories, and making people wonder how to avoid the need for it?
Well, I suspect the problem is not in the collaboration bit, quite the opposite. Because of our social nature, relationships and interactions most of the time are very positive.
Instead, the root of the problem is much more likely to be in the wait time, the delays, the repeated back and forth, the re-work, the slowness and the overhead caused by hand-offs and the blocking team dependencies, the time and effort they take, and the massive impact they have in everyday work.

For that, I believe all that can be done to limit and reduce hand-offs and remove and avoid new blocking team dependencies should be done, as previously pointed out.
The medium and long-term repeated costs of hand-offs and blocking team dependencies are much greater than the cost of getting rid of them. This has already been mentioned before, together with suggestions on how to do it.

And there are also things that can be done to make the cross-team collaboration itself frictionless and more enjoyable. At least in my personal experience (I’d like to hear yours too).

My personal experience and what I have learned so far

I have found that where it’s possible to work in small gelled teams (see teams’ temporary structural changes in the How-Tos) in which every team member can help other teams as needed, it does eliminate the need for any coordination overhead. As such it is the simplest, fastest, most effective, flexible, and most powerful, solution.

I’ve found that self-synchronisation (see coordinating the work in the How-Tos), where the experience and ability of the team members allow for it, is lightning fast, effective and flexible. Elements of orchestration may be introduced to compensate for the lack of experience until the team learns how to do without.

And finally, I have found parallel work (see sequencing the work in the How-Tos) adopted in combination with technical excellence (Trunk Based Development, TDD, real CI, clean feature toggles, real CD with automated remediation plans, etc.) to be extremely simple, flexible and fast.

These elements allowed me to experience a frictionless cross-team collaboration that together with a minimal number of blocking team dependencies created a super fast flow, allowing me to enjoy the positive aspects of the collaboration not only inside the team but also across teams.

So, in short, the answer to the initial question is: avoid hand-offs and blocking team dependencies, and make the remaining cross-team collaboration frictionless. With the warning: Don’t throw the baby (collaboration) out with the bathwater (hand-offs and blocking team dependencies).

Conclusions, recap & links

The social and human intangibles of the Agile cross-team collaboration and all the suggestions above on how to pursue good Agile cross-team collaboration remind us that:

– the traditional pre-Agile practices disguised as new do not work, that is why Agile was developed in the first place;
– Scrum of Scrums is at the same time too much and not enough, therefore it must be left behind, the sooner the better;
– all the options presented above help to quickly identify a good-enough starting point for cross-team collaboration, for any new piece of work with blocking team dependencies;
– the real work then starts, and it is done by experimenting, learning, adapting and evolving the cross-team collaboration for the specific teams working on a specific piece of work. This is achieved by applying Agile, not only to each team, but also to the collaboration between the teams, evolving the collaboration itself thanks to the feedback loops and the lessons learned while doing the work. By continuously running Retrospectives on the cross-team collaboration.

Quick recap:

1. Apply the approach described in Team Topologies to create stream-aligned teams as autonomous as possible.
   When a piece of work (a Backlog item, a User Story) has to stop and restart multiple times with long delays due to hand-offs and blocking team dependencies, then this is where you need to focus first.
   
2. Clean up the mess and keep it clean thereafter removing as many blocking team dependencies as possible with technical excellence and following approaches such as those described in Team Topologies.
   When most pieces of work have blocking team dependencies that are often discovered after the development has started, then this is where the focus should go next.
   You cannot be agile if you’re fighting your code and architecture to make every small change – Allen Holub
   
3. Every time the scope of a piece of work is refined, enough time and effort must be dedicated to identifying its blocking dependencies, categorising them (essential, accidental) and with the related teams deciding which should be tidied up as part of the work.
   After #1 and #2 above, stream-aligned teams’ focus should go here to prepare for any potential cross-team collaboration and make it frictionless.
   Tidying up means avoiding new blocking team dependencies and eliminating accidental dependencies or changing essential dependencies from blocking to non-blocking. During the refinement, every piece of work should be sliced into smaller pieces that may require cross-team collaboration only between a small number of teams if any at all (0÷3).
   
4. For every piece of work involving Agile cross-team collaboration, quickly draft a good-enough collaboration starting point engaging with all teams affected and exploring the options suggested in the How-Tos above.
   Teams relying on Scrum of Scrums, traditional projects or programme management, or scaled framework (with the exception of LeSS) for their cross-team collaboration, should switch to Agile cross-team collaboration. Even before the priorities can be aligned and the iteration/Sprint can be planned by all the teams.
   
5. Continuously retrospect on the Agile cross-team collaboration, experimenting, learning, adapting and evolving the collaboration aiming to a frictionless Agile cross-team collaboration.
   Periodically, those directly engaged in an Agile cross-team collaboration for a specific piece of work should meet to run a Retrospective on the collaboration itself to make it more effective, simple, fast, flexible, or in one word: frictionless.
   
6. Document what worked in which context and share it with everyone approaching the beginning of a new collaboration.
   After the completion of a major initiative, interview the teams to document the options they have experimented with and the pros and cons they have experienced. Share this in a Wiki, and scan for patterns and learnings.

Links
Here are a few useful links:
– Book Team Topologies: https://teamtopologies.com/
– Book The Mikado Method: http://mikadomethod.info/
– Book Living Complexity: https://leanpub.com/livingcomplexity/
– Taming Dependencies, #2 in Practice and patterns for the Product and the Delivery Initiatives:
http://p2.fed.wiki/view/practices-and-patterns-for-the-product-and-the-delivery-initiative
– Unwinding the dependency spiral: http://p2.fed.wiki/view/part-1-unwinding-the-dependencies-spiral
– Collaborating at Scale: http://p2.fed.wiki/view/part-2-collaborating-at-scale

<< Part 3 (Part 4)

Turbocharge your scaling initiative.

See how we can help.
You, your team, your organisation.

Virtual Mentoring Virtual Coaching As a Service