在分布式团队中结对编程显然也不会有效(取决于距离，不同的时区，工作方式，语言)，即使这样，一些人仍然在尝试。

　　虽然结对编程相比独自编程提高了代码质量，你也可以通过较低代价的代码复审来获得同样的代码质量提高，并且还有一些信息共享的优势。代码复审——特别轻便，离线复审——比结对编程更容易安排，代价更低点并且没有打扰。就像詹森科恩指出的那样 即使开发们结对编程，你或许仍然需要代码复审, 因为结对编程确实是共同解决问题，但是它并没有包含所有代码复审所涉及的全部问题。

　　还是乔恩埃文斯关于结对编程的老话：

　　真正的答案是有没有答案：独自编程，结对编程还是小组合作要根据环境用你最好的判断来动态结合才是最有效的。 结对编程的确有它存在的意义。(定律又没用了!)在某些情况下，甚至是“绝对对的”。但是坚持100%结对编程是盲目的教条主义，和所有的盲目教条主义一样，最终只会适得其反。

　　紧急设计和隐喻

　　增量开发管用，而且尝试保持设计简单感觉起来不错，但试图飞速定义一个架构是愚蠢且不切实际的。几乎没有人遵循紧急设计有一个原因：它不管用。

　　依赖于高水平的隐喻 (系统是一条 "流水线"或 一个"物料清单"或 一箱"蜂箱的蜜蜂") ，这些隐喻被团队共享为某种 代替建筑 是更加荒谬的。 卡内基梅隆大学基金会 的研究显示

　　… 自然语言的隐喻，无论对技术和非技术项目成员之间增进沟通，还是在开发架构方面，相对来说都不是很有用。

　　总之几乎无人理解系统隐喻是什么 ，或者它怎样使用，或者怎样选择一个有意义的隐喻，或者如果你搞错了又怎样改变它(还有你怎么会知道你选错了)，其中有人提出了这样的想法：

　　好吧我还是不妨公开说出来 —— 我仍然不能找到这种隐喻事情的窍门。我发现它管用，而且在C3项目中工作的很好，但这并不意味着我知道怎么做，更不要说如何解释怎样做到了。

　　Martin Fowler, 设计灭亡了吗?

　　敏捷开发方法促进了开发的成功率，并且展现出处理许多不同软件开发问题的更好方法——但不是架构和设计。

　　每日站立会议

　　当你有了一支新的团队，而每个人都需要相互了解，并且需要更多的时间理解项目是关于什么的;或者当这个团队迫于超级压力，正在试图修复些什么或者结束些什么的紧急的状况，那么将大家聚集起来开工作例会，甚至也许一天超过一次，这是必要的且有价值的。但是每个人是站还是坐，最终他们在会议上讨论些什么，将由你决定。

　　如果你的团队已经合作一段时间也合作的很好，而他们每个人都互相了解并且知道他们在做的是什么，如果开发人员做完事情的时候，在任务板或看板上更新卡片，或者在一个电子系统里更新状态，如果他们足够成熟可以在需要的时候请求帮助，那么你不需要每个早上在房间里 让他们都站着。

　　集中式代码所有权

　　让每个人的工作都涉及到所有代码并不总是有效(因为不是团队中的每个人对每个问题都有必备的知识或者经验)，并且集中式代码所有权对代码质量有负面影响。

　　共享代码看起来似乎更有意义，但事实上却是不是每个人或者是应该为系统的每一部分工作。

　　像写故事一样编写需求

　　每一个需求规格说明都能以用户故事的方式，以1到2行写到卡片上的想法，需求应该简明扼要(以致开发者必须向某人解释真正的需求是什么)，坚持他们应该应该以相同形式的模板。

　　“作为某一类用户，我有目标期望因此某些问题…”

　　是非常愚蠢和没有必要的。在15年前，这同样是一类简单而又传统的想法，让每个人都用 UML的用例的形式试图去捕捉所有需求。

　　有更多不同的方式来有效的表达需求。有时候需求需要被规定到细节级别(当你必须满足合规性或者符合一种标准，或是与现有系统集成，或是实现特定的算法。。。)。有时候从一个测试用例或者一个具体的用例场景或一个框架或一切别的类型的模型开始会更有效，因为这样会让人知道如何推进，并且有些细节已经就绪。因此，运用格式化和细节层级能更有效也更容易开展工作。

　　对产品所有者的依赖

　　依赖作为产品拥有者的人，当项目失败的时候，就如客户唯一的声音和“一个发不出声音的喉咙”，无法扩展，无法持续，将团队和项目以及事实上的业务推向风险的边缘。很自然的，危险逐渐靠近正在设计的产品和管理中的开发项目，将比解决危险带来更多的问题。

　　一些团队意识到这一点，并试图与产品所有者的想法保持一致，因为他们必须这样做。为了成功，一个团队需要在各个层次的真实而持续的客户合同，他们需要对自己负责，为确保他们得到他们所需要的，而不是依赖某一个人去完成所有的一切。