失败 - 敏捷团队成长路上的伙伴

上篇文章 过去一个多月的交付成果总结 提到打脸的事情来了。

1. 团队初期的护航

团队在进入Scrum初期,充满了各种疑虑和不解,为了让团队顺利体验Scrum的世界,我在初期阶段 Sprint 1 Sprint 2 Sprint 3 做了大量的护航工作:

  • Scrum的简单宣导。
  • 准备基建环境,以及整个适合TDD CI/CD的技术架构。
  • 引导团队如何进行需求规划。
  • 手把手演示如何编写用户故事,如何编写验收标准。
  • 手把手演示如何用TDD方式进行功能开发,以及两轮TDD kata。
  • 评审与回顾。

为了避免团队在一开始就遭受挫折,影响团队的信心与士气,Sprint 1 2 3 都在护航下成功完成既定交付。整个过程也存在一些严重的问题:

  1. 由于项目的特殊性和客观条件,我们没有全职的PO,是有CEO与开发团队共同形成的一个虚拟的PO,CEO兼职提供专业领域的知识和指导产品的规划。
  2. 团队成员都非常初级,全是应届毕业生,对项目工程缺乏实操经验。
  3. 团队与虚拟PO在前三个Sprint的故事与验收标准,投入程度不够,一方面是刚进入不熟悉,另一方面是CEO在该阶段有其他非常重要的事务处理。
  4. 团队成员在Sprint 1是分散远程办公,Sprint 2开始才是部分集中办公。
  5. 每个Sprint的需求故事,都无法提前准备就绪。

在这种情况下,重复多次向团队警示风险,但都没能受到重视,Sprint是交付了,但是理应还可以做得更好。同时,团队成员也点以为Scrum就是这样的感觉。

2. 引入失败

我希望尽快改变这种情况,但不喜欢强压的方式,反复提醒无效的情况下,放手让团队失败,是一个比较好的方案。

首先,放手让团队失败,并不是说故意设计让团队失败,而是,让团队以他们坚持的方式继续工作,不去干涉、改变他们的行为,他们有可能成功,也有失败,取决于团队自己。

其次,整个过程,并没有增加任何额外的成本,即使Sprint失败,并不意味着零交付。

目的是让整个团队明白现状,我们还没有想象中那么厉害,依然比较初级。

3. 失败

Sprint 4 的最终交付果然是失败,没能100%交付预期的质量和内容。
失败的感觉并不好受,会痛才有效果,也因此能让团队认清自己的现实状况,反省不足地方。
尤其是虚拟PO,明白了对用户故事与验收标准的投入度不够,会导致什么样的结果。

Sprint4 的失败,让团队重新感受压力,反省并承诺在下一个Sprint改进:

  • 全团队必须重视用户故事与验收标准的质量。
  • PO 加大对用户故事与验收标准的投入度。
  • 开发团队重视交付质量,每一个交付都必须亲自在QA环境上通过验收标准,方可视为完成。
  • 开发团队改进工作习惯,在一个故事未完成前,不去启动新的故事,避免过多的故事堆积在Doing栏。
  • 开发团队提升能力,尽量做到小步快速交付。
  • 另一个位专业知识同事(非技术), 贡献一半的时间,做验收测试工作。

4. 转变

Sprint 4 的失败,给整个团队带来压力。Sprint 5 雪上加霜,一个开发成员要去参加一个为期三周封闭的学习会。团队既要补回Sprint4没有交付的东西,又要完成Sprint 5的目标,同时还要面对临时性减员。

在Sprint 5,虚拟PO做到承诺,投入比前几个sprint多,用户故事与验收标准的质量因而得到明显的改进。

团队憋着一股劲前行,到了Sprint 5的交付评审,提前做足了各项准备工作。Sprint5的交付也比前面的几个Sprint有明显改进,PO对结果比较满意,团队本身对交付也充满小自豪。

回顾会上,问团队,是什么让Sprint5有如此交付?团队的回答:

  1. PO参与度的加大投入。
  2. 有同事贡献时间做验收测试,对交付质量改进起到非常大的作用。
  3. 开发团队的上个sprint失败的耻辱感与对本sprint成功的渴望。
  4. 开发团队能力的持续提升的必然体现。
  5. 与外部压力关系不大。

Sprint V在减员一人的情况下,一共完成了75个验收标准(AC),人均 25个AC。
我告诉团队,如果以这个产能数据来看,很厉害了。我之前另一个团队通过一年的时间,才达到 人均25个AC 的产能。但实际上我们的这个产能数据对比,是有一些问题的:

  • 这些AC,某种程度上,有Sprint4的基础。
  • 我们做的是小程序,并且UI也比较简单,没有太多前端的展示工作。
  • 另一个团队,做的是App,同一个故事与AC支持IOS与Android的同时交付,比我们要复杂的多。
  • 我们采用的技术栈 Elixir + Phoenix + Functional Programming,令到我们能够专注于业务开发。
  • 我们的UI全自动化验收还没有真正实施,这部分省了一部分工作量。另一个团队是已经UI全制动化验收测试。

Sprint V大家做的不错,但我们算是成功吗?
我给大家的评估是:待定,不算成功,也不算失败。
原因是,我们剩有三个故事放在Todo中,没有交付,从这一点上,应当算失败。
但是从团队在减员的情况下的已完成交付质量与工作规模却超过Sprint 4来算,应当算成功。

如果我们接下来的Sprint 6中,完成做到同样规模的等同质量交付,就可以认为 成功


无需害怕失败,
失败是暂时停止成功。
失败是敏捷团队成长路上的良师益友。
失败也是敏捷教练引导团队的一个重要工具。

害怕失败,不能接受失败,是敏捷最大的障碍之一。
敏捷需要有能接受失败,包容失败的环境。

这里必须感谢团队付出的努力和团队CEO对Sprint4失败的包容与支持


把团队成长的过程记录下来,也是对团队的一种鼓励。

Sprint 6总结再见。

推荐阅读更多精彩内容

  • 敏捷读书之重回根本:《Scrum指南》100问 作者/分享人:glenwang 本文是对Scrum指南的解析,以展...
    glenwang真北敏捷阅读 2,539评论 0 13
  • 1、在项目的Sprint回顾会后,团队成员指出那是抱怨会,不是非常有效。Scrum主管应该怎么做?A 建议团队尊重...
    隔壁老李头阅读 4,416评论 0 12
  • 大家正准备抢的时候,陈凯璇说:“不要抢啦!”想吃的人排好队了,一个一个地来。”我们每人分了一块鸡腿后,一只小黑手正...
    包博文阅读 61评论 0 0
  • 大概两年前开始看简单生活内容的书,包括《断舍离》《不持有的生活》《怦然心动的人生整理魔法》,这几本都很喜欢,然后也...
    萧小泥阅读 809评论 0 2
  • 中学时候语文考试最后一道题是作文,通常是 500 字或 800 字,我很清楚的记得我写的过程中总是会停下来数一下写...
    平凡随笔阅读 19评论 0 0