| 大型项目团队 |
将大项目重建为多个小项目。首先尝试技术试验项目，然后再执行实施项目。考虑频繁的发布较少的功能，以创建较小的项目团队。 考虑将团队裁剪到仅包含关键核心成员。通常人员过多会阻碍过程而会有所助益。缩小团队规模可减少内部动荡和成本。 将大型团队分解为多个小团队，并利用项目管理进行同步和协调。 利用敏捷和精益项目管理来组织大型项目。考虑DA，SAFE或LeSS等大规模敏捷框架或精益框架。每个团队都可提供一些有用的观点，并承担实施风险以及过程压力/成本 |
| 分散团队 |
许多项目都会包含（一些）分散团队成员。即时信息、视频会议和团队电子版都有助于确保通讯流畅。 如果团队保持稳定，请尽快构建面对面会议提高未来远程交流的效率。面对面交流时更容易建立信任感，提高对话质量。 如果在远程会议过程中参与者缺乏面部表情和身体语言交流，请考虑循环提问以确认他们的参与程度以及对决策是否认可。 此外，请考虑使用基于迭代的敏捷方法。如果团队成员所在时区差别较大，请避免使用整个项目迭代方式，而是鼓励开展更多更频繁的私人会议（每次两到三个人） |
| 某些安全关键型产品可能需要当前敏捷过程所建议的其他文档及合规性检查 |
在这些环境中仍可使用敏捷方法，但还需要该领域所要求的其他相应的合规性审查、文档和认证。在这种情况下，文档可能需要随已完成的功能一起交付。只有文档完成后功能才算完成。 考虑使用混合方法（多种敏捷方法），按照产品环境所要求的的更高严格程度，从敏捷所带来的协作和沟通改善中获得益处。航空飞行系统开发商和药物公司采用敏捷方法并结合自己的其他过程，充分利用这些优势并保留了相应的控制权。 |
| 稳定需求和执行过程 |
是否真正需要敏捷方法？如果需求不确定性较低、变更速度缓慢，或者执行风险很小，则可能不需要整套敏捷方法。尽管协作和透明程度提高对任何项目都有益处，但某些迭代机构和审查周期可能会是多余。 如果构建/反馈周期无法定期发现或者优化需求，请考虑延长持续时间以减少审查时间对成本的影响。 如果项目在设计和开发期间的变更速度极快，但向客户交付是一个确定性的可重复的过程，在每个项目阶段采用相应生命周期模型的混合方法可能更有意义 |
| 团队位于职能型组织内的职能孤岛中 |
敏捷是基于跨职能团队的理念。考虑让这些员工自行创建跨职能团队，而不采取管理干预手段，并了解其后果。如果能够通过组织报酬系统认可职能领域并给予奖励，请考虑首先变更改系统。除非对自己的报酬有一定影响，员工才会为产品或团队的利益行事 |
| 透明会产生恐惧 |
敏捷将会创建透明文化：员工会在整个开发期间展示和分享其成果。这种分享中间可交付成果的方式以及对成败得失和当前状态的开诚布公的态度即反应了透明化。透明需要勇气。 通过使用状态板或白板，示范引导并在决策过程中展示透明化 |
| 许多团队成员缺乏技术领域知识 |
敏捷方法将会提高团队的主动性并发挥其优势，做出工作内容相关的本地决策，例如任务安排顺序以及在解决问题时采用哪种方法。如果大多数团队成员经验不足，基于共识的方法可能会产生问题并导致返工。因此，对于这些团队来说，在获取必要技能之前，一些“分配”和“指导”方面的额外帮助可能是必需的。换言之，不要盲目地采用敏捷方法，授权经验不足的自指导团队尝试解决一切问题。考虑构建能力中心以帮助提供指导并积累领域知识 |
| 缺乏管理层支持 |
如果缺乏管理层支持，团队将会在敏捷思维模式和方法与更具预测性的思维模式和方法之间遇到冲突。根据组织需求找到共同点和改进之处，然后利用实验和回顾取得进展。 考虑管理层教育/培训。考虑从精益思维方面解释敏捷：周期短、规模小、频繁审查、回归与小幅改进 |
| 敏捷术语和语言不适合组织文化 |
如果不是敏捷语言，就修改术语，让员工了解并同意这些活动。说明每个术语的特定含义 。 例如，如果组织认为“游戏”一次不够专业，请勿使用类似于“计划游戏”这样的术语，而是考虑使用“计划研讨会”这样的术语 |
