变化经常发生，然而人们畏惧改变。人们感觉上认为改变是痛苦的，主要源于脱离舒适区域和面对未知世界的恐惧。虽然敏捷团队对变化准备充分，他们却对团队本身的改变感到不适。
Dean Johnson在Scrum开发讨论组中发起了一个讨论，来探讨移走团队成员的弊端。这个讨论基于他的项目经验。在项目中，一个团队成员被副总裁从团队中调出，时间长达几个Sprint。根据Dean的说法，负面影响包括：
这打破了团队的节奏
这危害到团队的速率（Velocity）
这伤害了团队的凝聚力
除了列出的问题，讨论中的大部分回复指出：在当前的商业和市场条件下，团队的改变在所难免。团队应该努力以建设性的方式，将改变带来的影响减少到最低点。根据Jack Milunsky所说：
然而，事情总会发生变化，比如优先级会改变等等。所以，要在整个公司的大背景下看待这个问题。我会和团队一起开会，讨论人员损失造成的影响。调整一些可以调整的，把无法处理的事情的优先级降低，然后继续前进。
Chris对ScrumMaster做了一些建议来帮助协调改变。
在会议上，询问每个团队成员他们喜欢原来团队的什么方面，他们希望现在的团队有什么改变。
使别人容易地得到你对问题和疑虑的回答。
组织团队出游，团队出去吃午餐，确保新成员和旧成员坐在一起。
作为ScrumMaster，确保你花一些时间和每个成员一对一交流，方便观察他们适应新团队动态的情况。
Alan Dayley 建议减少改变带来的痛苦的最佳方法之一，是使团队不受干扰直至Sprint的结尾。相对在Sprint的开始或中间，在Sprint的交界处对团队的增员或减员，会少些痛苦。
这种方法保护了当前Sprint的结果。也提供了对后续Sprint的清晰计划。
Mark Levison 建议向团队增加成员也需要适当整合。新成员需要对现有的代码库做培训，会增加交流的复杂度，也会破坏团队的构成。
Mark对减少改变团队带来的影响提供了几条有趣的策略：
如果在项目中已经太晚了，拒绝向团队中增加成员。
同时引进所有新人，来减少逐步增加团队成员的成本。
在团队中混合新人和旧人。
要求新人使用重构、写单元测试、自动化验收测试来使他们提速。
让新人和其他开发人员结对。
这样说来，团队改变是不可避免的。关键在于通过适应变化来最小化改变的影响，然后继续前行。毕竟，敏捷团队的主要目的是为利益相关人提供最大化的商业价值。正如Gary Brown所建议：
你也许不想听这个，但是团队的成员并不是你的孩子。如果这句话让你震惊，我真心道歉。我想要重申：你和你的团队每天到办公室工作，只有在交付最大化商业价值时才会得到报酬。商业价值是什么就是什么，而不是你认为的样子。和它们做伴。交付你的承诺。检验并调整。