有很多的敏捷障碍被Bas Voddle和Craig Larman在《Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum》一书中提及，并给予了很多建议和意见。
虽说很多我都遇到过，但在这里我仅仅列举一个比较头痛的组织障碍。它就是“承诺游戏”和非现实承诺，而问题的暴露经常是在多次的冲刺交付中不断涌现出来的。
开发团队在做交付的时候，我们发觉缺陷率升高；冲刺完成率非常低；由于无法及时交付被投诉等等问题不断涌现。在回顾会议上究其原因，发觉原因有以下几点：
1、遗留代码问题 - 由于时间紧，技术债无法偿还而导致的。
2、环境问题 - 持续集成和交付的环境出问题，从而打乱交付节奏。
3、人员流失 - 团队成员不断流失。
4、非现实承诺 - 可能在很久之前就已经做好计划，现在却无法兑现。可是管理团队仍然会以此作为交付的最后期限，最后导致被投诉。
5、救火队 - 不停的有线上问题和新的缺陷引入，是团队如救火队一般。而实际的迭代内工作却无法及时完成。
浅层次可以解释为人员流动、节假日、代码质量、敏捷失效等等。可深挖之后，这些“显而易见”的组织级障碍却会被人直接忽视，为什么？因为改变是困难的，敏捷万能和敏捷只和开发相关的思想不是一朝一夕可以改变的。
因此，我作为Scrum Master引入以下措施尝试移除这些障碍。
1、对于代码遗留问题 - 说服产品负责人，在冲刺中添加技术用户故事或者将其与某一个略低优先级或相关的用户故事绑定，来做技术债偿还。
2、对于环境问题 - 及时修复和讨论替代可行方案，将CI/CD的影响降低。
3、人员流失 - 暂时没有什么好方法，尽量说服高层保持人员稳定性。
4、非现实承诺 - 还是以透明、检视、调整为主，在遇见到事情可能会发生但情况下做到上下及时但沟通，调整非现实部分并给予理性的调整。使之能尽量贴合现实计划。
5、救火队 - 对于线上问题，做分别对待。需要马上处理的，就马上处理。否则会将其放入代办列表，与团队一起做及时梳理和调整。
如果不能改变组织，那么去做那些我们能力之内的调整，使之有所改善。
https://www.informit.com/articles/article.aspx?p=1380615
Books for new Scrum Master
