扔给团队一套标准流程为什么不能变敏捷？丨IDCF

273 2023-07-12

来源：敏捷DevOps那些事儿
作者：杨久成

这篇文章的起源是客户侧一位敏捷教练提了一个问题：”我们做敏捷，为什么不能直接给团队一套标准流程，类似Scrum的框架让团队去执行呢？而是要花费这么多的时间去辅导团队？“。今天希望通过这篇文章解答有类似疑惑的朋友。

回答问题时从根本原因上分析往往是最能够获得收益的。而这个问题的根儿就在于团队要做的是敏捷还是流程规范化。客户侧的敏捷转型是CTO发起并持续重点关注的组织变革活动，所以在客户侧我们也经常听到CTO强调要关注团队的持续改进。所以我们可以确信领导层想要的是敏捷转型，而不是单纯的流程规范化。

换个角度想，在敏捷转型的过程当中，流程规范化可以是敏捷转型的一个阶段。我们通过规范团队流程实现Doing Agile，再一步步向Being Agile的方向牵引。

那么，敏捷和流程规范化到底有什么区别呢？这里有两个根本逻辑：

1.敏捷的以人为本

敏捷关注“个体和互动高于流程和工具”，所以如果我们还是以落地流程和工具的角度去做敏捷，那与敏捷的价值观相去甚远。而即使从Scrum的角度去理解，Scrum也不仅仅是一套流程，Scrum也有它的5个核心价值观。如果Scrum的5个活动按部就班的执行了，但是并没有遵循Scrum价值观，那还是Scrum吗？

2.敏捷团队的“守破离”

敏捷团队的演进会呈现“守破离”的过程。如果按照上面的思路，我们把流程规范起来，而没有辅导，不给团队更多的输入。可预期的结果是团队会遵循既定流程持续运作下去。但是基本上很难打破限制、对流程和方法做改进和优化。也就导致团队无法做到持续成长，我们每天挂在嘴边的“自组织”也将很难实现。

所以对组织来说，做敏捷不是单纯的流程改造，而是基于敏捷核心价值观的组织变革过程。流程和工具更像是汽车的外壳和轮子，而人才是让汽车持续行进的发动机。

有啥洞察？

如果我们理解了这个逻辑，对我们的价值更多体现在几个方面：

1.指导敏捷转型过程：
理解了这个道理，可以让我们在规划敏捷转型方案时避免出现上述的片面理解，从规划上就关注到敏捷的本质，在“人”的角度做主动设计，推动组织产生持续改进的基因。避免敏捷转型像一场短暂流行，风雨过后，组织落不下什么有用的资产。

2.为团队解惑：对于团队来说，常常因为对敏捷的理解不到位，认为敏捷就是跑流程，开大会。而作为敏捷教练需要通过培训、分享、宣导等方式确保团队对敏捷具有正确的理解。从而帮助团队获得敏捷转型收益。

3.敏捷教练的自我检视：对于敏捷教练来说，容易扎进执行层，每天被团队辅导的各种事项包围，慢慢地也聚焦到具体的流程和工具层面。而定期的自我检视，强化对敏捷与流程改进区别的理解，能够帮助敏捷教练建立全局视角，思考敏捷转型本身的问题，回归本源，不断纠偏。

基于一个真实的问题，产生了以上观点，希望对读者有帮助。同时，也希望其他有疑问的小伙伴可以把问题私信给我，后续根据大家的提问形成文章，也是一个不错的尝试。

最后，手动感谢下提出问题的同学，促使我把这个潜在的观点整理出来。

#IDCF DevOps黑客马拉松挑战赛，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合。

2023年4月15-16日将在大连举办，36小时内从0到1打造并发布一款产品。