然支持这些的主要敏捷实践，如用需求卡片表示需求、协作方式、迭代交付等，并不是全部的解决方案，其本身也需要适当的调整以适应特定的环境。
例如，一个地理位置上分散的、几百人组成的团队，通常会把项目分解到几个团队由其独立完成，而不是所有人都去研究同一类需求。这些独立的团队将 影响到需求的实现方式：高层次的需求可能需要多个团队各自完成一些子部分，而各子部分之间则通过消息来传递信息。而这并不会减少需求卡片所带来的价值，这 种“准需求”能使各团队完成各自独立的（至少是分离的）、可测试的需求，从而很好地实现业务价值。
此外，还要考虑到项目管理方式的模式化程度。分布集中的团队可能会体验到“需求卡片墙”生动地将需求分阶段展示出来的好处，它将包括已完成的、 待定的、正在实现中的和准备解决的。然而，地理位置分散的团队无法使用真正的需求卡片“墙”。在此情况下，可以使用项目追踪报告（比如借用Mingle等 工具）使团队掌握项目状态。团队的分布形式也会影响到业务的协调程度。虽然业务应该与开发团队分布于同一地理位置，但对于分散的团队来说这不可能。但这并 不意味着对本地业务的了解没有用处，因此可以在本地设置一个业务代理——如请一位业务方面的分析专家，可以取得同样的效果。
版本发布计划的实践会根据环境不同而有相当大的变化。在一个高度动态的领域里，版本发布计划基本就是一种“一厢情愿”的想法。在这种情况下发布 计划很可能会误导项目的利益相关人并损害团队的利益。这时，XP方法中的“昨日气象”法应该是管理发布过程最安全的方式。在一个较稳定的领域里，版本发布 计划就能在很大程度上改善项目档案管理。
另一个需要根据情况考虑的是某种环境下的紧张程度。Scrum方法可能会对经常在生产中遇到故障或者发现缺陷从而急需危机管理的项目很有效，我 们可以一个中等长度的时间（比如一个月）划分工作段，在各阶段每天举行站立会议。但对于无法规律地得到发布版本的客户，可能更喜欢敏捷方法中常见的、一致 性更好、时间更长的迭代和发布周期。
总之，透明度并不是在做任务的时候顺便获得的，而是通过诸多在特定情况下可以最大化透明度的实践来实现的。
困难的解决与管理上的约束
以上所述并不是说敏捷实践仅仅是一种如何选择的问题，它还需要考虑更多可验证的、协作上的效益。我们需要看到，当这些实践完全实施以后，质量与 响应性都会得到极大的提升。虽然不同种类的敏捷实践——Crystal、XP、Scrum等——提供了不同的敏捷实现方法，但不等于这些就是全套的解决方 案。比如，在一个高度动态的领域中，XP中的“昨日气象”预测方法可能有极其重要的价值，但是由于它强调100%的单元测试覆盖率，因此即使在这样的环境 下，也可能造成相当大的精力上的浪费。同样，只采用Scrum管理方法却没有相应的敏捷实践可能导致项目管理与技术执行不完全一致。不管采用什么方法，都 应该对其有粒度化的了解和调整。
必须了解敏捷实践还会受到环境中各种条件的限制。敏捷实践通常是为了解决企业中的一些问题而引入，比如质量、一致性，或者响应性等问题。但如果 只解决了问题，却仍然有各种各样的约束，是无法产生最佳效果的。比如，敏捷的版本发布计划会假定有一个“代码所有者群体”，整个代码库都由这个团队“掌管 ”。如果只采用了各团队独立的开发方式，管理方式却跟不上，就会导致“泳道”式的结果。特别是有高度耦合性的代码会产生依赖性，而使敏捷发布计划变成瀑布 模式。同样，如果质量保证是由处于某一地理位置的一个团队独自实现的，那么很可能会使这个团队疲于奔命，无法及时响应来自敏捷开发团队的各种变化。这样， 开发响应