---

克服缺乏承诺、变更管理与协作难题！答案可能让你惊讶！

Scrum 之前的流程改进框架，最大弱点是： 主要关注服务领导自身利益的组织要求.

例如监控、合规和可预测性。 完全不关注服务客户和提高员工士气.

因此，软件管理团队和内外相关方试图设定固定交付期限，并轻松监控工程阶段进展。

偏离计划就处罚员工，期望在预定完成日前解决新问题。

独立孤岛执行完全分离的工程阶段。例如开发和测试（验证）团队完全独立，许多为同一使命工作的人甚至不知道彼此姓名。

猜得到为什么组织重视孤岛，而非业务使命及员工的专业和业务成熟度吗？

原因就是 矩阵管理 。它是一种组织和人员管理结构，自 1970 年代存在于企业。乍看之下，矩阵的独特理念似乎聪明。

领导将功能和技术技能相似的员工放入同一孤岛，最好也不过相邻孤岛，形成组织结构。

矩阵组织中的瀑布项目交付模型

当时企业流行“能力中心”，每个中心都是独立自主的孤岛。

C++ 开发一处、数据库管理一处、质量保证又在海外独立一处，没完没了。真让人费解！

最大挑战是：没有 Scrum 和 Scrum Master 时，项目经理为交付软件，必须临时向孤岛借人。

员工甚至不与项目团队同地，而留在各自能力中心的办公室。

项目结束，临时团队解散，人员转到其他项目的新任务。

所以项目追求的业务价值，从不是这些独立孤岛的最高重点。

它们把工作看作此项目打个勾、彼项目打个勾。

领导和矩阵结构没有教人如何承诺改善业务，包括销售、收入和利润。

McKinsey & Company 在 McKinsey Quarterly 的文章也清楚说明了这种 矩阵组织中的成本优化幻觉 .

Gartner 估计，全球组织每年 花费 6000 亿美元恢复 IT 系统 ，以应对计划外维护和缺陷。

现在花点时间，想象当时项目的变更管理和障碍处理——在瀑布、矩阵组织和没有 Scrum 的配置下如何运作。

对，你说得没错。

管理层和员工把变更、障碍和错误当作本不该发生的不受欢迎的例外。

因此，变更等于延误，常产生连锁反应。团队寻找缺陷和阻碍的替罪羊。

最后，由于没有处理、纠正和学习错误的机制，孤岛不断重复相同错误。

同时，他们还不断 增加技术债务 ，却被动应付问题。