Scrum方法的局限性

Posted 2021-04-25 留留老师

在敏捷方法的实践和探索中，我已不止一次发现Scrum框架的局限性。

为什么呢？

  Scrum框架简介及分析

说起Scrum，很多人一定会非常熟悉3355，3355是描述Scrum这个敏捷框架最简单的理解方式：

• 3-三种角色：产品、ScrumMaster、研发团队。

• 3-三个工件：产品待办事项、迭代待办事项、潜在可交付增量。

• 5-五个会议：每日站会、需求梳理会、迭代计划会、演示会和回顾会。

• 5-五个价值观：承诺、专注、开放、勇气、尊重。

仔细分析3355，就会发现：

• 角色：经理、产品、研发、测试、运营，这在我们平常的组织中就是存在的。

• 工件：你叫产品待办事项还是迭代待办事项，还是说直接就叫需求，都没啥毛病，因为这没有改变我们要以需求为核心的开发本质，只是个交付过程阶段性称呼而已。 

• 价值观：人的价值观本身就是多元的，讨论不讨论没啥价值，因为并不会说因为你定义了价值观，人的价值观就随之改变。

那么，Scrum框架最大的价值，是提供了一种端到端交付团队共同的工作方式，而这个工作方式之所以强大，是因为，其中蕴含了多个PDCA的改进环。 

比如站会，是对每日项目管理的PDCA。 

比如演示会，是对产品提升阶段性的PDCA。 

比如回顾会，是对团队提升阶段性的PDCA。

所以，结合迭代冲刺目标，Scrum通过缩小暴露问题的反馈周期，促进及时改进，使得交付、产品和团队能力不断提升。

  业务复杂性与Scrum的局限

Scrum框架结合迭代冲刺，在一些场景下是可行的。而随着组织业务的复杂性增加，这个方式失去了其灵活性。

如上图，当组织业务复杂性达到一个临界值时，因为外部依赖的不确定性对于迭代前和迭代中的协作成本加剧，这不仅导致每次都在为如何更好的安排迭代周期而浪费时间，而且这个时候团队跑Scrum迭代会遭受大概率的失败，从而大家都会对迭代式产品交付慢慢产生质疑，并伴随满意度降低。

于是，我们探索没有时间框架限制的交付方式的期望就越来越强烈。

至于业务复杂度，有一个简单的划分，即产品、产业链、平台，因为我在京东的缘故，电商平台带有高复杂度业务属性，所以，我遇到了Scrum有所局限这样的问题。

这个问题，其实突出的不仅仅是基于Scrum框架结合迭代timebox的冲刺交付方式，对于高复杂性业务不适用的问题，也反应了Scrum中定义的角色和基于团队敏捷而发展成的SAFe和LeSS这种大规模敏捷在处理高复杂性业务不适用的问题。

我想，道理是同样的。

经过周而复返，痛定思痛，我们现在很多团队已经把“迭代”这个概念拿掉了，当我们把迭代拿掉，建立起团队持续输入和持续交付的共同的工作方式的时候，却发现，是那么的顺畅。

比如，有一个团队，就是每周一需求梳理，每周四计划会，然后在每日站会上刷新团队看板上的人、事和问题，及时暴露和反馈问题，并于每周二和每周四定期发布，换句话说，就是定期输入和交付，再结合看板，保证需求流动顺畅和持续，最后根据团队的开发能力和业务需求，调整定期的节奏。 

  打造团队共同的工作方式

后来，我思考了下发现，其实我们很多人的思维被束缚住了。我们整天提迭代，提Scrum框架五会，却忽视了作为团队，无论你是产研发交付团队，还是业务BD团队，甚至是高层决策团队，经过摩擦，都会形成共同的工作方式，而这个工作方式跟迭代跟Scrum五会并没有什么关系。

回归组织管理的本质，团队工作方式的建立一定基于暴露和解决问题便是没错的。

所以在京东内部，对于处理复杂度较高的业务产品交付团队，我会基于Scrum五会和精益看板方法的价值流动概念帮助团队建立共同的工作方式，以减少协作损耗，从而提高产品交付效率。（本文完）

关于作者

何留留，敏捷化变革赋能“6+6” 框架提出者。操盘京东部门级敏捷转型，在团队域、产品域、组织域沉淀了基于实战的方法论和实践。目前是一名老师。