Coordination & Integration
Scrum重视分布式的、自组织的协调和集成，而不是传统项目管理集中式的、控制型的协调。LeSS定义的协调和集成指南专注于如何支持分布式的协调，同时提供足够的边界和结构来避免混乱。
直接交谈
也许团队间协调的最佳方式就是让团队直接协调。如果有问题需要讨论，自管理团队的任何成员都能够并被期望与另一个团队联系。当需要协调时，可以通过去找另一个团队、拿起电话，或者至少给他们发邮件来“交谈”。你不需要一个正式的、官方的、通常缓慢的协调机制来进行协调。站起来直接找人交谈。
以代码交流
LeSS团队采用持续集成，这意味着每个人都将所有代码提交到中央仓库的主干（分支会引入不必要的复杂性，应该避免）。产品团队中的每个人每天都会与仓库同步几次，并获得其他人做的所有更改。
所以，当你更新时，花两分钟时间检查一下其他人所做的更改，看看它们是否与你现在正在做的工作有关。如果是的话，就随时站起来“直接交谈”，以便和其他人同步你的工作！
侦查员
一种简单的协调方法是让团队探索他们的环境，向其他团队或接口派遣侦察员。侦察员监控相关接口并汇报回团队。通常，团队在迭代计划期间做出安排，为一个迭代的长度选择侦察员。团队的接口可以是另一个团队、另一个产品、团队外部的东西或干系人。..团队侦察什么都可以。
组件社区和导师
同时工作在相同组件上的人需要相互了解，以便可以相互问问题并评审彼此的代码。通过创建组件实践社区（CoP）来实现这一点，该社区可以通过邮件列表、聊天、临时会议和其它远程协作渠道进行沟通。
这些社区经常是由一位“组件导师”来组织，他通常是特性团队的成员，但承担了一些额外的职责，例如（1）教授组件的工作原理，（2）监控组件的长期健康状况，（3）组织组件社区，（4）组织设计工作坊，以及（5）评审代码。
组件导师并不是在代码提交之前评审批准代码。他是作为老师和组件看护，而不是一道门禁。
一个组件可能有几个导师，他们分担工作，从而减少对关键人员的依赖。
重要！… 除了有助于协调，这些实践还有助于维护或改善组件的代码/设计质量，并增加学习。
多团队会议
一些团队常常需要密切合作，而另一些团队则可能不需要。对于紧密合作的团队，通常会举行多团队LeSS会议。例如：
旅行者以利用和打破瓶颈并创建技能
有时，一个产品组依赖于几位经验丰富的技术专家。如何让所有团队都能获得这些（稀缺）专家的知识？他们可以成为旅行者。每个迭代他们都会加入一个不同的团队，通过结对、工作坊和教学课程加以辅导。
虽然旅行者不是专门为协调而创建的，但通过加入不同的团队他们创建或加强了一个广泛的网络，这正是非正式协调渠道所需要的。并且他们增加了某些知识或实践在团队间的一致性，由此实现了协调目标。
领头羊团队
在某些领域的特性非常大。当你将这些大特性拆分为更小的产品待办条目时，可能需要许多团队紧密工作在一起，每个团队各自在一些条目上，共同来创建一个大特性。
另一种协调多个团队共同开发从一个大特性拆分出来的不同条目的技术是领头羊团队。领头羊团队只是一个承担了牵头整个大特性的常规特性团队。除了做开发工作外，他们还负责跟踪其他团队正在做什么，并帮助他们同步。简而言之，他们除了自己开发之外还组织与大特性相关的跨团队协调。
有时几个团队会同时开始实现大特性。有时领头羊团队会独自开始，关注早期知识的转移，并简化了创建内聚设计的过程。在几个迭代后，更多的团队再加入。在这种情况下，领头羊团队也有教学职责，来帮助新来的团队学习他们已经知道的东西。
也许不用Scrum of Scrums
Scrum of Scrums是一种常见的跨团队协调技术，但在LeSS中并不推荐。
Scrum of Scrums是团队之间类似每日站会的会议，一般每周举行两到三次。
通常的形式是三个问题，类似于每日站会：
- 我们团队做了什么与其他团队相关的事情？
- 我们团队会做什么相关的事情？
- 我们团队有哪些障碍是其他团队应该知道或可以帮助解决的？
当然还可以使用和演进你们团队认为有用的任何问题。
警告：想要举行Scrum of Scrums可能表明了存在由于单一职能组和组件团队或者团队无法或不愿识别并共享工作所造成的不必要依赖或协调问题。
Scrum of Scrums不是LeSS的一部分，它作为一种更正式的集中式协调技术也不被推荐。但是如果它有效，也没必要停……只是不要觉得因为导入LeSS就必须要做它。