{"id":2807,"date":"2022-08-08T15:26:54","date_gmt":"2022-08-08T14:26:54","guid":{"rendered":"https:\/\/www.smharter.com\/blog\/?p=2807"},"modified":"2023-03-19T13:51:19","modified_gmt":"2023-03-19T13:51:19","slug":"agile-cross-team-collaboration-how-tos-long","status":"publish","type":"post","link":"https:\/\/www.smharter.com\/blog\/2022\/08\/08\/agile-cross-team-collaboration-how-tos-long\/","title":{"rendered":"Agile cross-team collaboration HOW-TOs (4-part)"},"content":{"rendered":"\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Agile-cross-team-collaboration-how-tos.png\" alt=\"\" class=\"wp-image-2819\" width=\"420\" height=\"326\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Agile-cross-team-collaboration-how-tos.png 1190w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Agile-cross-team-collaboration-how-tos-600x466.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Agile-cross-team-collaboration-how-tos-768x596.png 768w\" sizes=\"auto, (max-width: 420px) 100vw, 420px\" \/><\/figure><\/div>\n\n\n\n<div style=\"height:60px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<pre class=\"wp-block-verse has-text-align-center\"><strong>PART ONE<\/strong>\n<\/pre>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Acknowledgements<\/strong><\/h1>\n\n\n\n<p>Thanks to those that contributed to this post, reviewed it and made suggestions for improving it: <br><em><strong>Jon Kern<\/strong> (co-author of the Agile Manifesto), <strong>Matthew Skelton<\/strong> (co-author of Team Topologies), <strong>Mark Dalgarno<\/strong> (Agile conferences organiser, Agile professional), <strong>Carlo Beschi<\/strong> (Agile professional), <strong>Carlo Volpi<\/strong> (Sr Programme Manager), <strong>Luca Cicale<\/strong> (Senior Application Architect and Developer).<\/em><\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Summary<\/strong><\/h1>\n\n\n\n<p>This post explores why Agile cross-team collaboration is fundamental, why current solutions for cross-team collaboration are flawed, and when Agile cross-team collaboration is really needed. It describes how to pursue good Agile cross-team collaboration. And it concludes arguing whether cross-team collaboration should be embraced or avoided.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Why is Agile cross-team collaboration fundamental?<\/strong><\/h1>\n\n\n\n<p>Teams and organisations are Human Complex systems where people are the most valuable, adaptable, and essential element. Because of our social nature, the relationships and the interactions between individuals and teams are fundamental. The overall behaviour of such Human Complex systems results from the interplay of the many interactions between people and between teams. Therefore, Agile cross-team collaboration is the single most consequential success factor when pursuing Agility beyond one team and across the organisation.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-why-matters.png\" alt=\"\" class=\"wp-image-2820\" width=\"527\" height=\"363\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-why-matters.png 1278w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-why-matters-600x414.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-why-matters-768x530.png 768w\" sizes=\"auto, (max-width: 527px) 100vw, 527px\" \/><\/figure><\/div>\n\n\n\n<p><meta charset=\"utf-8\"><\/p>\n\n\n\n<p>Let&#8217;s take as an example Software development. In Software development, when someone begins to learn how to design a system, they usually start by focusing on the design of the individual objects or functions. They master it.<br>Then, later, their focus shifts to the most important aspects of the design: the space between objects or functions, their relationships, the messages and information they exchange, their interdependencies, and the way they can be combined.<\/p>\n\n\n\n<p>Similarly, when someone starts learning and adopting Agile, they usually start from the individuals and team and how to make it work well. Then they master it at the team level. Later, the focus shifts to mastering the collaboration across Agile teams, and the intangibles in the space in-between.<\/p>\n\n\n\n<p>See, for example, the general idea here and in particular principle #5:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"http:\/\/p2.fed.wiki\/view\/part-2-collaborating-at-scale\" target=\"_blank\" rel=\"noreferrer noopener\">http:\/\/p2.fed.wiki\/view\/part-2-collaborating-at-scale<\/a><\/li><\/ul>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>What are the current solutions, and why are they flawed?<\/strong><\/h1>\n\n\n\n<p>The current solutions for cross-team collaboration come from the Agile Industry and the scaled frameworks. With the exception of LeSS (that is about de-scaling), they are traditional pre-Agile practices disguised as new, or at best Scrum of Scrums. And none of them works well.<\/p>\n\n\n\n<p>One common solution is the generic 1-size-fits-all <strong>Scrum of Scrums<\/strong>. There is much more than Scrum of Scrums that must be considered for a good cross-team collaboration, and at the same time, Scrum of Scrums is too much for what it does. It is, at best, a starting point to be quickly left behind like the starting blocks at the sprint&#8217;s start signal.<\/p>\n\n\n\n<p>The other common solution comes from scaled frameworks and some inexperienced Agile practitioners. It boils down to <strong>traditional pre-Agile practices disguised as new<\/strong>, that don&#8217;t work for today\u2019s Complex problems. These practices boil down to more process, more governance, more roles and hierarchy levels, more upfront top-down planning, more timelines a la Gantt charts, more shared services or centralised functions, or more tools. Not only they are ineffective, wasteful, and lead to very low productivity, but they also hinder the ability of individual teams to work effectively and achieve any degree of Agility.<\/p>\n\n\n\n<p><meta charset=\"utf-8\"><\/p>\n\n\n\n<hr class=\"wp-block-separator is-style-wide\"\/>\n\n\n\n<p class=\"has-text-align-center\"> (Part 1)<strong> <a href=\"https:\/\/www.smharter.com\/blog\/2022\/08\/08\/agile-cross-team-collaboration-how-tos-long\/2\/\">Part 2 &gt;&gt;<\/a><\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator is-style-wide\"\/>\n\n\n\n<!--nextpage-->\n\n\n\n<pre class=\"wp-block-verse has-text-align-center\"><strong>PART TWO<\/strong>\n<\/pre>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>When is Agile cross-team collaboration really needed?<\/strong><\/h1>\n\n\n\n<p>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.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaborate.png\" alt=\"\" class=\"wp-image-2821\" width=\"623\" height=\"288\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaborate.png 1030w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaborate-600x278.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaborate-768x356.png 768w\" sizes=\"auto, (max-width: 623px) 100vw, 623px\" \/><\/figure><\/div>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Rationales.png\" alt=\"\" class=\"wp-image-2822\" width=\"624\" height=\"357\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Rationales.png 1714w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Rationales-600x344.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Rationales-768x440.png 768w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Rationales-1536x880.png 1536w\" sizes=\"auto, (max-width: 624px) 100vw, 624px\" \/><\/figure><\/div>\n\n\n\n<p>The most common cross-team dependencies forcing 2+ teams into cross-team collaboration are technical dependencies, which the book <a rel=\"noreferrer noopener\" href=\"https:\/\/teamtopologies.com\/\" target=\"_blank\">Team Topologies<\/a> refers to as <em>blocking team dependencies<\/em>. 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.<\/p>\n\n\n\n<p><em>Blocking team dependencies<\/em> can and should be turned into <em>non-blocking team dependencies<\/em>, 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.&nbsp;<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>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.<br>And professional software and digital products and services development have a strong social component too.<br>For all these reasons, good cross-team collaboration remains essential, always, and this leads us to Agile cross-team collaboration.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>The How-Tos of Agile cross-team collaboration are presented next, preceded by two paragraphs with two must-know.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Must-know: Not all <em>dependencies<\/em> are created equal<\/strong><\/h1>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>All technical and non-technical cross-team dependencies can be<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Essential dependencies: those that cannot be eliminated;<\/li><li>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.<\/li><\/ul>\n\n\n\n<p>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 <em>blocking team dependencies<\/em>.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Dependencies.png\" alt=\"\" class=\"wp-image-2823\" width=\"771\" height=\"224\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Dependencies.png 1346w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Dependencies-600x175.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Dependencies-768x224.png 768w\" sizes=\"auto, (max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px\" \/><\/figure><\/div>\n\n\n\n<p>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.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong><meta charset=\"utf-8\"><strong>Must-know: <\/strong>Clean the mess first, and keep it clean thereafter<\/strong><\/h1>\n\n\n\n<p>One fundamental learning from Agile software development that sets it apart from the traditional project and programme management is that:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><span style=\"text-decoration: underline;\">the effort to manage dependencies is orders of magnitude bigger than the effort to eliminate accidental dependencies and relax the remaining essential dependencies.<\/span><\/li><\/ul>\n\n\n\n<p>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.<\/p>\n\n\n\n<p><br>Ron Jeffries <a href=\"https:\/\/ronjeffries.com\/articles\/2015-02-08-dependencies\/\" target=\"_blank\" rel=\"noreferrer noopener\">here<\/a> says: <span style=\"text-decoration: underline;\">Eliminate dependencies, don\u2019t document or accommodate them<\/span>.<\/p>\n\n\n\n<p>This idea is pitched here and expanded in principles #2 and #3:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"http:\/\/p2.fed.wiki\/view\/part-1-unwinding-the-dependencies-spiral\" target=\"_blank\" rel=\"noreferrer noopener\">http:\/\/p2.fed.wiki\/view\/part-1-unwinding-the-dependencies-spiral<\/a><\/li><\/ul>\n\n\n\n<p>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:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"http:\/\/p2.fed.wiki\/view\/practices-and-patterns-for-the-product-and-the-delivery-initiative\" target=\"_blank\" rel=\"noreferrer noopener\">http:\/\/p2.fed.wiki\/view\/practices-and-patterns-for-the-product-and-the-delivery-initiative<\/a><\/li><\/ul>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Dependencies-eliminate-and-relax.png\" alt=\"\" class=\"wp-image-2824\" width=\"770\" height=\"224\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Dependencies-eliminate-and-relax.png 1346w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Dependencies-eliminate-and-relax-600x175.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Dependencies-eliminate-and-relax-768x224.png 768w\" sizes=\"auto, (max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px\" \/><\/figure><\/div>\n\n\n\n<p>The book Team Topologies advocates applying on an ongoing basis the inverse Conway&#8217;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.&nbsp;&nbsp;<\/p>\n\n\n\n<p>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, <a rel=\"noreferrer noopener\" href=\"http:\/\/p2.fed.wiki\/view\/part-2-collaborating-at-scale\" target=\"_blank\">http:\/\/p2.fed.wiki\/view\/part-2-collaborating-at-scale<\/a>).<\/p>\n\n\n\n<p>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.&nbsp;<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>The book Team Topologies also discusses the Interaction pattern <em>X-As-A-Service<\/em> (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.<br>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:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>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<\/li><li>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).<\/li><\/ul>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>In conclusion, the overall approach to enable teams\u2019 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.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><meta charset=\"utf-8\"><strong><strong>To summarise<\/strong><\/strong><\/h1>\n\n\n\n<ol class=\"wp-block-list\"><li>The top priority is to: Clean the mess first and keep it clean thereafter to create a fast flow<\/li><li>And after it is also necessary to: Continue creating good frictionless cross-team collaboration.<\/li><\/ol>\n\n\n\n<p>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 <br>a) removing all blockers to fast flow takes time meanwhile cross-team collaboration will continue; <br>b) some essential dependencies cannot be removed ever or until stable boundaries emerge meanwhile <meta charset=\"utf-8\">cross-team collaboration will continue; <br>c) there are cases where <meta charset=\"utf-8\">cross-team collaboration is desirable and advantageous like with pair or mob\/ensemble programming, and in those cases <meta charset=\"utf-8\">cross-team collaboration should be made as frictionless as possible too.<\/p>\n\n\n\n<hr class=\"wp-block-separator is-style-wide\"\/>\n\n\n\n<p class=\"has-text-align-center\"><strong><a href=\"https:\/\/www.smharter.com\/blog\/2022\/08\/08\/agile-cross-team-collaboration-how-tos-long\/\" data-type=\"URL\" data-id=\"https:\/\/www.smharter.com\/blog\/2022\/08\/08\/agile-cross-team-collaboration-how-tos-long\/\">&lt;&lt; Part 1<\/a><\/strong> <meta charset=\"utf-8\"> (Part 2)  <strong><a href=\"https:\/\/www.smharter.com\/blog\/2022\/08\/08\/agile-cross-team-collaboration-how-tos-long\/3\/\">Part 3 &gt;&gt;<\/a><\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator is-style-wide\"\/>\n\n\n\n<!--nextpage-->\n\n\n\n<pre class=\"wp-block-verse has-text-align-center\"><strong>PART THREE<\/strong>\n<\/pre>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>HOW-TOs<\/strong><\/h1>\n\n\n\n<p>Here follows a detailed description of how to create a good Agile cross-team collaboration that doesn\u2019t hinder the Agility of the individual teams while fostering the Agility of the whole system of teams.<\/p>\n\n\n\n<p>Below are some options available to quickly draft a good-enough starting point for an Agile cross-team collaboration.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>Different contexts &amp; circumstances need different solutions<\/strong>:<strong> 0) retrospecting the cross-team collaboration<\/strong><\/h4>\n\n\n\n<p>Many factors have a huge influence on what will work well or not in a specific Agile cross-team collaboration, for example:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>which teams are involved,&nbsp;<\/li><li>their ways of working,&nbsp;<\/li><li>their mastery and level of Agility,&nbsp;<\/li><li>their preferences,&nbsp;<\/li><li>the nature of the cross-team dependencies,<\/li><li>the degree of Complexity of the work to be done, intended as the degree of uncertainty, unknowns, rapid changes and a high level of innovativeness (find more about the degree of Complexity in the book <a href=\"https:\/\/leanpub.com\/livingcomplexity\/\" target=\"_blank\" rel=\"noreferrer noopener\">Living Complexity<\/a>).<\/li><\/ul>\n\n\n\n<p>There are so many factors and combinations that it is impossible to find out upfront what will work well and what will not.&nbsp;<\/p>\n\n\n\n<p>Therefore, achieving good Agile cross-team collaboration in a given context and circumstances is similar to attaining good Agile ways of working. It has to start from a simple starting point and from there it requires to experiment, learn, adapt and evolve along the way, with help from regular Retrospectives on the cross-team collaboration itself.<\/p>\n\n\n\n<p>This evolutionary process should re-start from the beginning whenever the teams, the cross-team dependencies, or the work involved changes. The cadence should be linked to the pieces of work requiring collaboration.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-retro.png\" alt=\"\" class=\"wp-image-2828\" width=\"608\" height=\"324\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-retro.png 1664w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-retro-600x320.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-retro-768x410.png 768w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Collaboration-retro-1536x820.png 1536w\" sizes=\"auto, (max-width: 608px) 100vw, 608px\" \/><\/figure><\/div>\n\n\n\n<p>With time and experience, the teams in the organisation will become better at choosing a good-enough starting point, choosing the next experiment, and learning and adapting faster. Gradually recurring patterns will emerge, forming a catalogue of experiences and options that will be known for having worked well before repeatedly under specific circumstances.<\/p>\n\n\n\n<p>Organisational bottlenecks, obstacles and inefficiencies affecting the shared work and cross-team collaboration will emerge during the retrospective. It will lead to improvement actions on the governance, structure and composition of the teams, departments and the whole organisation.<br><\/p>\n\n\n\n<p>Viktor Grgic pointed out the need for an organisational continuous improvement. This retrospective plays a big role driving the improvement toward the organisation&#8217;s specific needs and circumstances. It is an alternative to imitating canned solutions, standard solutions, or models copied from different organisations with different needs and circumstances.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>The practical elements of Agile cross-team collaboration<\/strong><\/h4>\n\n\n\n<p>Every time there is a Backlog item that needs 2+ teams to collaborate to get it done, the teams will have to find a common way for&nbsp;<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>planning the work,&nbsp;<\/li><li>considering temporary team structural changes, if needed<\/li><li>coordinating the work,<\/li><li>sequencing the work to do and getting it done together.<\/li><\/ol>\n\n\n\n<p>In summary, they will have to agree on the touch-points and the interface of their interaction, and agree on a protocol for their collaboration.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>1) Planning the work<\/strong><\/h4>\n\n\n\n<p>Below are three possible options to consider based on the scenario faced.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/planning-the-work.png\" alt=\"\" class=\"wp-image-2829\" width=\"681\" height=\"388\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/planning-the-work.png 1978w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/planning-the-work-600x343.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/planning-the-work-768x439.png 768w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/planning-the-work-1536x877.png 1536w\" sizes=\"auto, (max-width: 681px) 100vw, 681px\" \/><\/figure><\/div>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>When the teams are from the same product area (share the same Backlog and the same priorities)<br><\/strong>The Backlog defines the plan and priorities. No additional planning effort is required unless the dependencies between two district pieces of work are identified late in the process and so a re-prioritisation decision needs to be taken swiftly to bring the two dependent pieces of work closer together.<br><\/li><li><strong>When the teams work on the same product but in different areas of the product (have different Backlogs and priorities, but a common goal and a common decision maker)<br><\/strong>The teams and their POs and stakeholders need to coordinate their priorities among them when possible and in case of a conflict escalate the decision to the common decision maker.<br>No party can autonomously commit to a plan until the priorities are coordinated.<br><\/li><li><strong>When the teams work on different products or even in different companies (have different Backlogs and priorities, different goals, and don&#8217;t share any common decision maker)<br><\/strong>The teams and their POs and stakeholders need to agree to deconflict their plans and coordinate the priorities related to the piece of work and its cross-team dependencies. No party can autonomously commit to a plan until the priorities are coordinated.<\/li><\/ul>\n\n\n\n<p><\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>2) Considering teams&#8217; temporary structural changes to do the work<\/strong><\/h4>\n\n\n\n<p>All the structures discussed below, last for the relatively short time needed to complete the work (a Backlog item, a User Story). During that time each team member is fully dedicated to the structure they belong to.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/temporary-teams-structure-changes-2048x660.png\" alt=\"\" class=\"wp-image-2830\" width=\"823\" height=\"265\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/temporary-teams-structure-changes-2048x660.png 2048w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/temporary-teams-structure-changes-600x193.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/temporary-teams-structure-changes-768x247.png 768w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/temporary-teams-structure-changes-1536x495.png 1536w\" sizes=\"auto, (max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 543px, 580px\" \/><\/figure><\/div>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>None<br><\/strong>This is the most common and safe solution.<br>The rule of thumb is that each team should remain stable for around 18 months. And after that, only a limited number of changes should happen over time.<br><\/li><li><strong>Gelled teams helping each other<\/strong><br>Relevant team members from a donor-team can join the recipient-team to offer knowledge and help as needed. This requires the teams involved to be stable for long enough (18+ months) for the temporary changes not to damage the teams. The teams should not be suffering from knowledge silos either (e.g. they are practising pairing or mobbing\/ensembling that prevents knowledge silos).<br>This approach completely removes the need for cross-team collaboration. But it will affect to some degree the capacity and performance of all the teams that have temporarily donated some of their team members.<br><\/li><li><strong>Creating a temporary task force with relevant team members from the teams<br><\/strong>This is very similar to the previous options, except for all those collaborating cross-team now form a separated task force. It may be better when more than two teams are involved or when there is a need to reduce the noise added to the recipient team.<br><\/li><li><strong>Temporarily merged dependent teams<br><\/strong>When all teams involved in the work to do are very small (2-3 members) and the number of teams involved is also small (2-3 teams) there is the option to merge the teams for the time needed to complete the work at hand. This will completely remove the need for cross-team collaboration.<\/li><\/ul>\n\n\n\n<p>In the last three options, if those doing the work collaborate synchronously, pairing or mobbing\/ensembling for example, that will greatly amplify cross-team knowledge sharing.<\/p>\n\n\n\n<p>It is possible and desirable that, after the work is completed, knowledge sharing will enable these teams to work autonomously in the future on a similar piece of work with similar dependencies. Because they will have learned how to do the work autonomously.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>3) Coordinating the work<\/strong><\/h4>\n\n\n\n<p>After work has been planned and started, the teams involved need to coordinate their actions. For example, where to start, what to do next, exchange and share relevant information, develop a common understanding of the work to be done, help each other as needed, integrate their parts of the work, etc.<br>They need to find out which of the touch-points are needed. And for each one of them who should be involved, how should it be organised (for example as an ad-hoc event or a regular and recurring event), how communication should happen (for example synchronous or asynchronous), etc.<\/p>\n\n\n\n<p>Below are three common approaches to do this, and the description of how they fit with the degree of Complexity of the work at hand (find more about the degree of Complexity in the book <a rel=\"noreferrer noopener\" href=\"https:\/\/leanpub.com\/livingcomplexity\/\" target=\"_blank\">Living Complexity<\/a>).<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-continuum.png\" alt=\"\" class=\"wp-image-2831\" width=\"692\" height=\"129\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-continuum.png 904w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-continuum-600x113.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-continuum-768x144.png 768w\" sizes=\"auto, (max-width: 692px) 100vw, 692px\" \/><\/figure><\/div>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Self-synchronisation<\/strong><br>This approach expects all the members of every team to be empowered to directly share information and coordinate their collaboration and work activities, as needed by the work at hand and its progress and evolutions. Imagine the players of a football team or doubles tennis players and the way they work together.<br>This is the same level of synchronous collaboration expected in a good Agile team, but in this case, across the members of the teams collaborating.<br><br><em>Work nature:<\/em> This approach is a good fit for a type of work that has a high degree of Complexity. Meaning it has a lot of uncertainties, unknowns, rapid changes and a high level of innovativeness.<br>And as such it requires a high bandwidth of information sharing and interaction and high-speed feedback loops. For the nature of the work, the collaboration protocol cannot be defined upfront and will emerge during the collaboration. It may remain fluid and may continuously change until the work is completed.<br><br><em>Team capability:<\/em> It requires each team involved to be comfortable with this type of collaboration and to already have a good level of Agility.<\/li><\/ul>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Orchestration<\/strong><br>In this approach, someone from each team like the Scrum Master and the PO are empowered to come together to form a temporary orchestration workgroup lasting for the limited duration of the collaboration. The group shares relevant information and coordinates the collaboration and the work activities across the teams.<br>This orchestration workgroup does not act as a (wo)man-in-the-middle, but whenever direct collaboration between members of different teams is needed, they just facilitate for it to happen, and get out of the way.<br><br><em>Work nature:<\/em> This approach is a good fit for a type of work with some degrees of Complexity. Meaning it has some uncertainties, unknowns, and some level of innovativeness. The orchestration facilitates the identification and definition of a collaboration protocol among teams that fits the work at hand: clear collaboration touch points (events) and interfaces (what is exchanged between teams, when, who, etc.)<\/li><\/ul>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Strictly hierarchical coordination<\/strong><br>This approach expects that there is a dedicated role in the org-chart with the authority to direct the collaboration among the teams, in a traditional top-down fashion.<br><br><em>Work nature:<\/em> It can be a good fit for the highly repetitive, predictable and standardised type of work. While it is very problematic for software development and innovative work where it doesn&#8217;t solve the coordination problems and it often becomes an obstacle that people have to work around.<br><br>This approach for obvious practical reasons is not applicable when for example the teams belong to different organisations that have distinct org-charts, or when the teams belong to disjoined parts of the same organisation.<\/li><\/ul>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-the-work.png\" alt=\"\" class=\"wp-image-2832\" width=\"694\" height=\"430\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-the-work.png 1822w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-the-work-600x371.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-the-work-768x475.png 768w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Coordinating-the-work-1536x951.png 1536w\" sizes=\"auto, (max-width: 694px) 100vw, 694px\" \/><\/figure><\/div>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>4) Sequencing the work across teams<\/strong><\/h4>\n\n\n\n<p>Below are a few options to sequence the work over time across the teams. Each option fits a certain degree of Complexity of the work at hand, and a certain level of Agility in the teams. Find more about the degree of Complexity and the level of Agility in the book <a href=\"https:\/\/leanpub.com\/livingcomplexity\/\" target=\"_blank\" rel=\"noreferrer noopener\">Living Complexity<\/a>.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Sequencing-1.png\" alt=\"\" class=\"wp-image-2874\" width=\"732\" height=\"587\" srcset=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Sequencing-1.png 1602w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Sequencing-1-600x482.png 600w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Sequencing-1-768x617.png 768w, https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Sequencing-1-1536x1233.png 1536w\" sizes=\"auto, (max-width: 732px) 100vw, 732px\" \/><\/figure><\/div>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Parallel work<\/strong><br>The piece of work that is consuming a cross-team dependency and the work on the related cross-team dependency are carried out by all the teams in parallel at the same time. It can be done using techniques similar to those that allow automated test coding in parallel with the coding of the related feature.<br><br><em>Team capability:<\/em> This requires the teams involved to have a high level of technical Agility and collaborate synchronously like with pairing and mobbing\/ensembling. And it benefits from the ability of the teams to practise Trunk Based Development (TBD), Feature Toggles, and Continuous Delivery with automated remediation plans (for example one-click rollback).<br><br><em>Work nature:<\/em> This approach is a good fit for a type of work that has a high degree of Complexity. Meaning it has a lot of uncertainties, unknowns, rapid changes and a high level of innovativeness. Because of the nature of the work, all the interfaces between the different pieces of work, their design, their integration, the understanding of the problem and the discovery of the solution, evolve gradually while the work is done and until the work is completed.<\/li><\/ul>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Asynchronous blocking work<br><\/strong>This approach is a more flexible alternative to the strictly sequential Staggered work (see later). Its flexibility is attained from more advanced teams&#8217; capabilities. While the teams work asynchronously, the work can only be completed after all the teams successfully complete their part of the work and successfully complete the integration.<br><br><em>Work nature:<\/em> it is a good fit for the same type of work that fits staggered work with or without a buffer.<br><br><em>Team capability:<\/em> The ability to work asynchronously requires the additional ability to practice Trunk Based Development (TBD), use Feature Toggles, and practice Continuous Delivery with automated remediation plans (for example one-click rollback).<\/li><\/ul>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Staggered work without a buffer<\/strong><br>In this approach, the piece of work consuming a cross-team dependency will be planned into the following iteration\/Sprint, after the work on the related cross-team dependency is completed. It needs all the work to be done iteratively and incrementally. So that even if the work on the dependency is not completed on time, the work that consumes the dependency can start anyway by consuming what is already available.<br><br><em>Work nature:<\/em> This approach is a good fit for a type of work with some degrees of Complexity and so with some uncertainties, unknowns, some changes, and some level of innovativeness.<br><br><em>Team capability:<\/em> This requires all the teams to have a good level of technical Agility that can be obtained, for example, by practices such as real Continuous Integration, TDD, and continuous refactoring with emergent design.<\/li><\/ul>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Staggered work with a buffer<\/strong><br>This approach is similar to the previous one but adds a safety buffer. It avoids last-minute emergency changes to the iteration\/Sprint planning when the work on the dependency is not completed in time by the end of the previous iteration\/Sprint.<br><br><em>Team capability:<\/em> Techniques such as Consumer-Driven Contracts (<a href=\"https:\/\/martinfowler.com\/articles\/consumerDrivenContracts.html\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/martinfowler.com\/articles\/consumerDrivenContracts.html<\/a>) can be enough to help teams avoid misunderstandings, and reduce the risk of integration problems.<\/li><\/ul>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>A future Deadline<\/strong><br>The teams will work independently on their own piece of work and the work will be sequenced using deadlines.<br><br><em>Work nature:<\/em> It can be a good fit for the highly repetitive, predictable and standardised type of work. For it, the interfaces and the integration of the pieces of work can be correctly defined upfront without causing unexpected surprises. And it won&#8217;t require multiple back-and-forths and rework that would cause very long delays.<br><br><em>Team capability:<\/em> The sequencing of the work with deadlines is inherently fragile because when any of the teams get behind schedule, that has a knock-on effect on all the other deadlines. So, it should be adopted only by teams that cannot be Agile.<\/li><\/ul>\n\n\n\n<h4 class=\"wp-block-heading\"><strong>Let&#8217;s not forget the important intangibles<\/strong><\/h4>\n\n\n\n<p>Being part of effective Agile teams taught us the huge importance of the many intangibles required for a great collaboration inside a team. Equally, in Agile cross-team collaboration, many essential intangibles play a fundamental role in the success of the collaboration. These are a few of them worth mentioning to help us not forget that processes, tools and techniques always come second, after the social and human aspects: we know it is important to get to know each other strengths and skills and styles, get along, trust each other&#8217;s genuine intent to collaborate and to help and support each other, and trust the ability of the collaboration to be successful. We know it is important to have authority aligned with our responsibilities, to have the freedom to bring our whole selves to work and be human, to use our creativity, to do our work well, and to have joy in our accomplishments.<\/p>\n\n\n\n<hr class=\"wp-block-separator is-style-wide\"\/>\n\n\n\n<p class=\"has-text-align-center\"><strong><a href=\"https:\/\/www.smharter.com\/blog\/2022\/08\/08\/agile-cross-team-collaboration-how-tos-long\/2\/\">&lt;&lt; Part 2<\/a><\/strong>   <meta charset=\"utf-8\">(Part 3)  <strong><a href=\"https:\/\/www.smharter.com\/blog\/2022\/08\/08\/agile-cross-team-collaboration-how-tos-long\/4\/\">Part 4 &gt;&gt;<\/a><\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator is-style-wide\"\/>\n\n\n\n<!--nextpage-->\n\n\n\n<pre class=\"wp-block-verse has-text-align-center\"><strong>PART FOUR<\/strong>\n<\/pre>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Should cross-team collaboration be embraced or avoided?<\/strong><\/h1>\n\n\n\n<p>When thinking about collaboration inside a good Agile team, what usually comes to mind is a very positive and fulfilling professional and social experience.<br>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 \u2013 for example,&nbsp; working in pairs or mob\/ensemble programming \u2013 did not want to go back anymore.<\/p>\n\n\n\n<p>So why are many experiences of cross-team collaboration painful, leaving bad memories, and making people wonder how to avoid the need for it?<br>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.<br>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.<\/p>\n\n\n\n<p>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.<br>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.<br><br>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\u2019d like to hear yours too).<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><meta charset=\"utf-8\"><strong>My personal experience and what I have learned so far<\/strong><\/h4>\n\n\n\n<p>I have found that where it&#8217;s possible to work in small <em>gelled teams<\/em> (see teams&#8217; 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.<br><br>I\u2019ve found that <em>self-synchronisation<\/em> (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 <em>orchestration<\/em> may be introduced to compensate for the lack of experience until the team learns how to do without.<\/p>\n\n\n\n<p>And finally, I have found <em>parallel work<\/em> (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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>So, in short, the answer to the initial question is: avoid hand-offs and blocking team dependencies<a rel=\"noreferrer noopener\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_throw_the_baby_out_with_the_bathwater\" target=\"_blank\">,<\/a> and make the remaining cross-team collaboration frictionless. With the warning: Don&#8217;t throw the baby (collaboration) out with the bathwater (hand-offs and blocking team dependencies).<\/p>\n\n\n\n<h1 class=\"wp-block-heading\"><strong>Conclusions, recap &amp; links<\/strong><\/h1>\n\n\n\n<p>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:<\/p>\n\n\n\n<p>&#8211; the traditional pre-Agile practices disguised as new do not work, that is why Agile was developed in the first place;<br>&#8211; Scrum of Scrums is at the same time too much and not enough, therefore it must be left behind, the sooner the better;<br>&#8211; 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;<br>&#8211; 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.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"560\" height=\"438\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/Agile-cross-team-commaboration-retro.png\" alt=\"\" class=\"wp-image-2827\"\/><\/figure><\/div>\n\n\n\n<p><span style=\"text-decoration: underline;\">Quick recap:<\/span><\/p>\n\n\n\n<ol class=\"wp-block-list\"><li><strong>Apply the approach described in Team Topologies to create stream-aligned teams as autonomous as possible. <br><\/strong>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.<br><\/li><li><strong>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.<br><\/strong>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.<br><em>You cannot be agile if you&#8217;re fighting your code and architecture to make every small change<\/em> &#8211; Allen Holub<br><\/li><li><strong>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.<\/strong><br>After #1 and #2 above, stream-aligned teams&#8217; focus should go here to prepare for any potential cross-team collaboration and make it frictionless.<br>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\u00f73).<br><\/li><li><strong>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.<br><\/strong>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.<strong> <\/strong>Even before the priorities can be aligned and the iteration\/Sprint can be planned by all the teams.<br><\/li><li><strong>Continuously retrospect on the Agile cross-team collaboration, experimenting, learning, adapting and evolving the collaboration aiming to a frictionless Agile cross-team collaboration.<\/strong><br>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.<br><\/li><li><strong>Document what worked in which context and share it with everyone approaching the beginning of a new collaboration.<\/strong><br>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.<\/li><\/ol>\n\n\n\n<p><span style=\"text-decoration: underline;\">Links<\/span><br>Here are a few useful links:<br>&#8211; Book Team Topologies: <a rel=\"noreferrer noopener\" href=\"https:\/\/teamtopologies.com\/\" target=\"_blank\">https:\/\/teamtopologies.com\/<\/a><br>&#8211; Book The Mikado Method: <a rel=\"noreferrer noopener\" href=\"http:\/\/mikadomethod.info\/\" target=\"_blank\">http:\/\/mikadomethod.info\/<\/a><br>&#8211; Book Living Complexity: <a rel=\"noreferrer noopener\" href=\"https:\/\/leanpub.com\/livingcomplexity\/\" target=\"_blank\">https:\/\/leanpub.com\/livingcomplexity\/<\/a><br>&#8211; Taming Dependencies, #2 in Practice and patterns for the Product and the Delivery Initiatives:<br>   <a rel=\"noreferrer noopener\" href=\"http:\/\/p2.fed.wiki\/view\/practices-and-patterns-for-the-product-and-the-delivery-initiative\" target=\"_blank\">http:\/\/p2.fed.wiki\/view\/practices-and-patterns-for-the-product-and-the-delivery-initiative<\/a><br>&#8211; Unwinding the dependency spiral: <a rel=\"noreferrer noopener\" href=\"http:\/\/p2.fed.wiki\/view\/part-1-unwinding-the-dependencies-spiral\" target=\"_blank\">http:\/\/p2.fed.wiki\/view\/part-1-unwinding-the-dependencies-spiral<\/a><br>&#8211; Collaborating at Scale: <a rel=\"noreferrer noopener\" href=\"http:\/\/p2.fed.wiki\/view\/part-2-collaborating-at-scale\" target=\"_blank\">http:\/\/p2.fed.wiki\/view\/part-2-collaborating-at-scale<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator is-style-wide\"\/>\n\n\n\n<p class=\"has-text-align-center\"><strong><a href=\"https:\/\/www.smharter.com\/blog\/2022\/08\/08\/agile-cross-team-collaboration-how-tos-long\/3\/\">&lt;&lt; Part 3<\/a><\/strong>  (Part 4)<\/p>\n\n\n\n<hr class=\"wp-block-separator is-style-wide\"\/>\n\n\n\n<div style=\"height:132px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<div class=\"wp-block-columns is-layout-flex wp-container-core-columns-is-layout-9d6595d7 wp-block-columns-is-layout-flex\">\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\">\n<figure class=\"wp-block-image size-large\">\n\n<img loading=\"lazy\" decoding=\"async\" width=\"420\" height=\"397\" src=\"https:\/\/www.smharter.com\/blog\/wp-content\/uploads\/turbocharge.png\" alt=\"\" class=\"wp-image-1974\"><\/figure>\n\n\n\n<p><\/p>\n<\/div>\n\n\n\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\">\n<div class=\"text-ads\">\n\t<h3>Turbocharge your scaling initiative.<\/h3>\n\t<p>\n\t<br>\n\tSee how we can help.\n\t<br>\n\tYou, your team, your organisation.\n\t<br><br>\n\t<\/p>\n\n\t<div class=\"local-scroll\">\n\t\t<a href=\"\/coaching.html#one_session\" target=\"_blank\" class=\" btn elastic-btn-mod btn-mod btn-dark btn-medium btn-round\" onclick=\"ga('send','event','Blog scaling-ads','Click one_session button','Virtual Mentoring');\" rel=\"noopener noreferrer\">\n\t\tVirtual Mentoring\n\t\t<\/a> \n\n\n\t\t<a href=\"\/coaching.html#coaching_as_a_service\" target=\"_blank\" class=\"btn elastic-btn-mod btn-mod btn-dark btn-medium btn-round\" onclick=\"ga('send','event','Blog scaling-ads','Click coaching_as_a_service button','Virtual Coaching As a Service');\" rel=\"noopener noreferrer\">\n\t\tVirtual Coaching As a Service \n\t\t<\/a>\n\t<\/div>\n<\/div>\n\n\n\n<p><\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>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 &#8220;scaled&#8221; solutions cut it.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-2807","post","type-post","status-publish","format-standard","hentry","category-lean-agile"],"_links":{"self":[{"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/posts\/2807","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/comments?post=2807"}],"version-history":[{"count":54,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/posts\/2807\/revisions"}],"predecessor-version":[{"id":3077,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/posts\/2807\/revisions\/3077"}],"wp:attachment":[{"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/media?parent=2807"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/categories?post=2807"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smharter.com\/blog\/wp-json\/wp\/v2\/tags?post=2807"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}