- 人们过度偏离自组织状态（比如非常无组织、非常不专注、情绪化等等）。
- 人们的软技巧与业务需求不相匹配（比如，不能做到积极主动，害怕讲话，沟通不良，时间管理差等等）。这些软技巧的缺乏，不可能让真实的潜力转化为绩效。
- 人们得了企业病（比如诽谤中伤，嫉贤妒能，自吹自擂，知识垄断，阿谀奉承等等）。技术上讲，假如有强力的管理者（而非教练）以持续的监督来控制他们，在影响到团队互动之前就扼杀这些苗头，仍然可能使这些人有所产出。
我在此的意思是，我们应当对所有专业人员具备高度的包容。但是处理和发挥一个个体的长处，方法因人而异，没有适用于每个人的通行法则。组织在这一点 上应当反省。所有国家都有很好的技术人员，他们可以是好的贡献者，但也许不能自组织。这就是教练/促进者会转为更像一个项目经理的地方。这些人也许会犯 错，也许需要引导和监管，也许缺乏软技巧，如此等等。在教练/促进者的有限范围内，让这些类型的人员与敏捷相适应来完成工作，会成为一个噩梦。我对各种各 样的人充满尊重，也坚信这些人可以成为好的贡献者，但是你需要延展教练的职责范围，给与其某种权力来强硬地表明“什么该做，什么不该做”。这里项目经理的 角色就变得有帮助。下表展示了一些觉得需要项目经理的其他领域。
| 情境编号 | 事实 | 敏捷如何有用 | 敏捷帮不上忙的地方
（而管理者可以！） |
备注 |
| 1 | 人无完人 | 举行每日进度会议，让他们保持专注，让产品负责人保持需求与业务相一致。 | 1.专注点是否在正确方向上？ 2.产品负责人是否每个冲刺都改变目标？ 3.责任是否真正分担？如果每人都觉得别人更有经验、懂得更多，所以更要负责，该怎么办？ 4.人们是否以敏捷之名掩盖自己能力的不足？ 5.团队是否做到真正自组织？ 6.人们是寻找外部原因作为借口，还是真正有所改善？ 7.团队中是否有某人正抢占所有功劳，而损害了团队动力？ 8.是否有人垄断了知识，不与团队分享？ |
具备横向思维的管理者可以想出创新的办法来管理不完美之处。
教练可以用合适方式提出如何做事，但如果人们不遵循又如何？比如，要是团队在演示后不听取产品负责人的反馈呢？这是可接受的，还是必须强制听取？ |
| 2 | 控制改变 | 敏捷在每个冲刺开始时欢迎新的需求，而Scrum Master在冲刺中防止范围蠕变。 | 1.Scrum Master是否正确履行职责？ 2.测试人员是否按时做了工作？ 3.人们的软技巧和承诺是否正在改变？ 4.客户是否突然开始不信任敏捷？ 5.客户是否突然开始期待不切实际的事情？ |
敏捷以需求优先级来照管改变，但只是一部分。
产品负责人可以发挥影响力，在冲刺进行中增加故事，可团队不知道如何应对？ 任何方法都无法应对无形的改变。 |
| 3 | 沟通不适当 | 敏捷用站会提供了每日沟通的机会，也用回顾会议创造了大家畅所欲言的平台。 | 1.团队是否真正提出障碍？ 2.团队是否积极主动地沟通所有事项？ 3.受众是否完全理解了沟通内容？ 4.我们的沟通中是否有语言或文化的隔阂？ 5.分布式的沟通是否成了瓶颈？用户体验是否良好？ 6.是否所有email都得到回复，并达到预期、质量良好？ |
公司沟通是与懂得写程序非常不同的课题，也是很困难的课题。
管理学研究解释了沟通的艺术性。 任何流程都不能处理软技巧。 |
| 4 | 流程不完美 | 敏捷在软件开发中有效。 | 每个方法论都有其局限，最终是人来使项目成功。 | 差的敏捷不如没有敏捷。 |
| 5 | 流程实施不恰当 | 敏捷是一个实施依赖于人的流程。 | 1.人们是否遵循流程？ 2.流程可否改善？ 3.流程的哪些子集适合我的项目？ 4.例外在哪里，何时偏离流程没有关系？ |
一个简单例子——在敏捷中，团队是否进行大量的结对编程？ 最佳实践何时真的成为我项目的最佳实践？ |
