敏捷的过程控制理论的三大支柱：透明(Transparency），检验(Inspection)，调整(Adaption)是敏捷理论的核心，它保证了整个敏捷的实用性和不断改善。
但在应用这个理论时，有些情境下我们会流于形式浮于表面，从而不仅不能达到应有的效果，反而给团队增加负担，伤害团队的积极性。比如：
1. 每日站会变成的进度汇报会议
这是一个在团队敏捷转型初期常见的问题。每日站会是用于增加团队透明度，促进团队之间的沟通合作，暴露团队成员在迭代中面临的问题的会议，但是如果scrum master还是以项目经理的心态主持这个会议，对团队“负责”，那么这个会议就变成了一个汇报会议，每个人只关心自己的汇报内容，对其他人的进度和困难既不了解也不关心，团队成员依旧是一座座的孤岛，并没有形成通力合作。
2. 迭代回顾会议被跳过
回顾会议是团队改进的心脏起搏器可以检视团队的表现，识别优秀的实践和可能的问题。尽管大部分scrum master都明白这个会议的重要性，但常常因为这个会议不够紧急而取消跳过这个会议。这就使得团队在迭代中发现的问题继续留存在团队当中，无法得到正视和解决，久而久之，问题堆积，效率得不到提升，团队成员的积极性也会受到打击，形成一种“得过且过”而不是“积极创新”的团队氛围。
3. 迭代审查的结果并没有反馈到产品代办列表中
在迭代结束之前，产品经理和业务需要对迭代的交付物进行验收，在验收的过程中出现的反馈意见需要反映到产品代办列表的调整当中，以作为团队对业务的变更的响应。如果丢失了这一步，那么实际上整个团队为验收会议所作的准备都付之东流，团队也会逐渐失去业务的信任，从何打破和业务合作的良好关系。
