9月份某日，我参加了智联研发每日微信沙龙，讲述了一个团队先搞敏捷成功，后来失败的故事，来自于某知名公司的亲身实例，非常棒。

沙龙后，咕咚老王整理了一篇博文《一个成功敏捷团队的失败历程》，（转载在 http://blog.csdn.net/zhangmike/article/details/40950267 ）

本文试着从我的视角来分析下为什么？

首先来看其前期为什么成功？

     1，项目经理首先选用了Scrum，决定实施自动化测试，允许测试落后开发一个Sprint

     2，美国老大不满意，要求开发测试必须同步，制定强制要求，引入TDD（被老大逼迫使用的）

     3，项目经理进一步要求，开发人员必须参与集成测试Case的编写

     以上看起来是命令驱动的结果。将常见的敏捷实践用起来了。

那么为什么后期失败呢？

    1，项目经理和测试Leader离开团队，虽然来了一位美国架构师，但后来他也离开了。

    2，原测试人员的顶头上司（测试部门经理）转变了职能

    3，没有人真正关心质量，原来的敏捷实践-结对，TDD被放弃，自动化测试用例不再维护

咕咚老王对于前期成功的分析是“前一个产品开发阶段的敏捷，是权威下的“敏捷”。之所以成功，不是形成了真正敏捷的自组织团队，而是在项目管理人员的个人权威之下，实施了真正的敏捷实践。”

      所以可以看到，真正的敏捷实践能够带来团队的成功，虽然没有形成真正的敏捷自组织团队。

     咕咚老王在文中推荐了敏捷教练/Scrum Master。这是一个不错的解决方案。

但除了这个解决方案之外，还是否有其它方案呢？  笔者推荐如下的2个方案

1，保持权威，既然权威敏捷带来了成功，何不发挥这种方式。

2，将形成的好实践落在团队章程上，形成组织+团队双重监督

对于保持权威，即是让续任的项目经理继续坚持好的实践，续任的项目经理要同样的理解敏捷实践，理解其中利弊，能够做出权威的正确决策。这其实是对一个组织的项目经理培养机制的考验。一个成功的项目经理晋升了，续任者不可能有前任相同的看法和经验。中国人信奉新官上任三把火，续任者总是有些不一样的。“萧规曹随”虽然也是国人古代的智慧，但貌似在中国用得不多。  目前而言，培养权威的项目经理较之培养合格的敏捷教练，我认为培养前者更容易些。 在东方官文化下，合格的敏捷教练实在是太稀缺了。

而对于团队章程，即是将团队得到的好做法记录下来，在Scrum中推荐制定完成定义DoD，这其实就是团队章程，或者说章程的一部分。

团队章程在每个（或者每2个）迭代的回顾会议上得到更新的机会，把最新的好实践加到团队章程中。

加入的方式可以是自组织的方式，也可以是权威方式。

权威方式获得的团队章程将高于权威，也即是团队章程不会被权威轻易的修改。

团队章程的形成会对权威形成制约。

这样固化的共识就不会因为个别权威人员的离开而消散。

曾经成功的敏捷团队为什么失败？