5.2 分析当你面对复杂局面的方式方法，从而去解决组织级功能失调的根因

5.2 analyze your approach to a complex intervention that addresses the root cause(s) of an organizational impediment.

挑战：从敏捷Scrum回退到小瀑布模式的转型

首先，面临价值观的转变，敏捷软件开发的四个核心价值回退：

1. 流程和工具 重于 个体和互动

1）开发与测试团队物理座位分开，分开在不同的楼层，沟通方式从面对面沟通，变成：如果需要面对面沟通则需要爬楼梯，或采用IM工具、电话替代。

2）在流程中，从开发到测试需要发起单独的测试流程，小步快跑频繁交付拆小的用户故事的方式被替代。

3）需要应对的流程成倍增加，流程/工具不能支持自动过，需要人工介入比较深

2. 详尽的文档 重于 可工作的软件

1）对流程、评审、文档的各种约束和要求

2）对度量指标数据的各种要求，软件开发过程变成了面向度量指标组织软件开发

3）项目制，一次性的工作，失去Sprint的开发节奏，团队难以适应

3. 合同谈判 重于 客户合作

不关注用户反馈，不关注实际情况响应变化，只关心按计划完成

4. 遵循计划 重于 响应变化

各种对计划的依赖，体现在：

1）制定详细的项目计划，并且严格按照计划执行

2）需求冻结，一旦确定不再增删改

敏捷所解决的瀑布存在的问题，被一点一点找回来，这个过程是非常痛苦的。

1. 从产品到项目

产品：

1）迭代+增量

2）共同目标

3）相对稳定的开发团队，Scrum Team作为一个团队工作

项目：

1）临时的

2）明确的开始和结束时间

3）不是规律发生的

4）人员不固定

2. 从跨职能团队到职能团队

跨职能团队：共同目标

职能团队：以职能团队的利益为优先，竖井&筒仓

3. 从自组织到命令控制

4. 从人（有机体）到机器（工具/工具人）

5. 从“小”到“大”

6. 从Outcome到Output

开发项目仅关心事先定义好的项目范围，关注Output是否按计划

从螺旋动力角度分析：

橙色向蓝色和红色的退行。

橙色：成果导向，追求成就，自我驱动

蓝色和红色：1）不论是否达到目标取得成果，过程必须要符合流程； 先制定计划，再按照计划一丝不苟的执行。

                      2）把工作放进系统里，由上级进行监控

从螺旋动力的角度该如何应对？

用蓝色和红色的方式来应对：符合流程、遵守各种要求

1）韬光养晦：收敛自己，为自己未来的转变积蓄力量

2）步步为营：尽可能保持小团队的环境，彼此能够合作和对话

总体上来说，差异主要是：

由此引发，团队面临很多实际的困难需要解决：

1. 客户端开发、服务端开发、测试分别变成了独立的职能团队，团队不再坐在一起，工作节奏也不一致，前后端互相等待，同一个功能两个客户端（iOS/Android）进度也不一致，彼此工作进展不透明，需要同时协调多个团队的工作，造成沟通成本大大上升，整体交付变慢。

2. 独立的职能团队工作目标并不一致，各自为各自的绩效（刷存在感）而工作，对同一件事情有各自的立场和认识，给协作造成了障碍，需要更多的沟通。

3. 人员不稳定造成质量不稳定（不了解需求的前因后果）

4. BUG不好管理，问题追踪困难，需要一直跟踪催促，BUG修复的时间拉长

5. 项目立项结项时间随机，经常会议时间冲突

6. 瀑布模式容易出现集中大量交付，积压在测试

原因：

1. 价值观冲突，处于螺旋动力发展的不同层级的冲突。

2. 与领导者的认知水平有关，意识发展没有跟上世界的变化，认为要依靠组织的力量（流程、规范化、标准化），而不能依靠个人能力去发展，与敏捷对“人”的认知有冲突。

2. 组织规模，规模大，传统按职能划分的组织架构坚固，既得利益者的利益难以撼动，成为变革的阻力。

3. 组织结构决定的软件开发组织方式、方法论以及工具的差异，筒仓不需要协作，然而软件开发是一个协作问题（Software creation is a collaborative process.）。

4. 想要的绝不是形式上的一致，而是思想层面的操控。必须在符合命令控制的价值观体系下“自由创造”。

如何解决？

前提条件：人的意识/价值观、团队的文化已经改变了，回到过去是很痛苦的。

并非单纯的转型的问题，还要考虑组织人员的稳定性、组织业务的持续性等问题。

仍然只能是边前进、边学习

从肯尼芬框架（Cynefin framework）分析来看：

从组织的角度，大体上处于Complex 复杂区域，结果是确定的，但方式和路径是没有标准答案的，只能摸着石头过河。不断的在“行动-反馈-调整”（行动-感知-响应）中无限循环，快速试错。从这个角度看，适应的过程本身就是敏捷的。

对于个人而言，我更倾向于这是一个Chaotic - 混沌/混乱问题。不如“RUN！”

从解决方案来看，能否做成假瀑布、真敏捷，在瀑布的约束下尽可能的保持团队响应变化的能力以及团队目标一致、群策群力的协作模式。为了最终的交付质量和效率要做的事情还必须要去做。能不能成功还是未知。目前会朝这个方向努力。

中国有句古话：

法不轻传，道不贱卖；师不顺路，医不叩门；香不白烧，经不空念；千金不传不义者，万财不渡忘恩人；医逢信者但可救，道遇无名枉费心；甘露不润无根草，妙法只渡有缘人。

无论外面的世界如何变化，我们仍然还是可以做自己。不需要跟别人说，不需要告诉别人我做的有多好，更加不需要教别人该怎么做，只要做好自己，就好了。

尽可能的，哪怕在最小的范围内（如一个小团队）来保持团队的氛围。

落实到具体的工作中：

1. 更多的沟通：同一个产品的相关方（PO、开发、测试等）能够充分的讨论和澄清需求，对需求达成一致理解；共同评审代码和测试用例，共同参加计划会、每日站会、回顾会等，对齐目标，加强对细节的沟通

2. 开发/测试人员的变动，做好基础性的工作，避免频繁变动影响产品质量

3. 积极主动的沟通，每个人都主动对团队公开信息

4. 项目经理仍然要花一部分精力用来指导团队自组织和跨职能（尽可能），帮助移除障碍（尽可能）

5. 尽量拆小，做小的、有价值的交付，来保证质量和提高效率

带来的一些思考：

让自己和团队重新认识到敏捷的意义