敏捷是如何在两个星期里“毁掉”我们团队的！

如果现在提到敏捷，你还认为这只是软件开发的领域，小π姐姐就要严肃地哔哔几句了：

 

“年轻人啊，

too young too simple !

sometimes naive!”

 

接下来要讲的故事，没有发生在软件开发领域，却是软件开发团队值得学习的一个故事，尤其对想要实行或是已经实践敏捷的团队来说，都极具实战性的参考价值。

 

编辑 Ⅰ小π姐姐

来源 Ⅰ 网络各平台

   温馨提醒：文末有福利！

 

这个团队有点方

 

小C任职于一家金融公司的新媒体部门。

 

上个月，突然从外部空降一位所谓的敏捷教练，听说是公司高层的旨意，希望将新的工作模式在公司推行，而新媒体部门——这个欣欣向荣（前途迷茫）的新事物就成了身先士卒首享恩泽的小白鼠。

 

教练带领小C所在团队的第一周，首先第一件事，指定了两个重要的角色，小C作为

SM(ScrumMaster)，还有另外一位团队的小领导作为PO(Product Owner)，教练一开始就强调了SM与团队平等云云，这种套话嘛大家听听就算了，毕竟传统的命令式领导风格已经不适合当下的环境。

 

团队每天早上计划会，中午站会，下午梳理会，评审会，下班前还有一轮回顾会，对于团队来说，突然发现，这一天工作的8小时，竟有大量时间是耗在了各种会议上。

 

不同于传统会议的是，这个会议里教练一直在强调，我们是作为一个整体，为同一个目标而工作的团队。

 

比如：

文案在讲自己的内容困难时，教练提醒其他团队成员一起提建议，大家起初还有点不适应，因为大家始终还是抱着我把我分内的事做完就好的态度，别人的工作和我不相干。但在第二天下午的评审会时，大家就傻眼了：文案因为没完成当天的任务，虽然其他同事的工作都完成了，教练却告诉大家，今天团队的产能是0！

 

只是文案没完成，而且2个故事点的文案，粗粗估一下，也已经完成了1.5，其他当天的任务也都完成了啊，怎么可以说产能是0呢？

 

然而，敏捷教练强调到：我们团队是在为同一个项目目标努力，所以每个人都要为产能负责，只要其中有一项没完成，产能就算为0。

 

终于，大家对这个充满各种会议的所谓Scrum开始重视起来了。第三天的计划会上，很明显团队成员的状态不一样了，每个故事的预估点，每个任务的拆分，大家更加谨慎，更加投入了。

 

小C作为指派的SM，从刚开始观摩教练开会，到教练让他自己来主导会议，也感觉有些力不从心。

 

因为会议的不熟悉，教练在一旁指导很多，小C有些挫败感，自信心也不够，而且他也感觉到团队成员对自己并不是很信任，毕竟自己就是临时被拎出来的一个SM，他认为自己是没有传统管理层背景，没有职权让大家信服。

 

从第一周的生疏到第二周全权交给SM和PO，敏捷教练目睹了整个团队明显的改善：

 

团队从刚开始的“嫌麻烦”，到后来成员主动提议开会了开会了；

 

团队每天在评审会看到完成的故事点感觉像打了一个小胜仗，士气明显提升；

 

每天的任务更加明确，大家的工作激情好像被重新点燃了。

 

同时，敏捷教练也看到了团队在整个过程中的一些潜在风险：

 

1.估算故事点的时候，大家出现不一致的情况时，按照教练的指导，讲出自己估算的理由。

 

尝试了两三次后，教练发现一个问题，不知道是SM态度的强势，还是团队成员图省事，在某一个快要产生争议的时刻，团队成员会直接以SM的建议为准，SM说两个故事点那么就两个故事点吧。

 

2.PO则带着强烈的交付使命感，一直在催促着团队和ScrumMaster：“这个做好了吗”“这个今天能做好吗”“现在进行到哪里了”“我不是催你们哦，你们不要有压力哦”。。。

 

如此反复几次，发现团队成员交付东西的目的性更明显了，成员之间的沟通也都是以交付为准，看起来好像没什么问题，但是总感觉哪里有点不对。

 

3.期间还出现了两次加班到9点多的情况，一下子增加这么多的会议，每天的工作难免会有延迟。

 

所以到晚上9点时大家已经有些情绪，9点终于结束工作准备离开时，没想到教练说今天的回顾会还没开。

 

一想到又要回顾哪里做得好哪里做得不好，怎么改善，来来回回讨论半个多小时，团队的成员已经没有多少耐心，虽然围成一个圈圈，却都是一幅垂头丧气的模样。当然了，这个会议依然还是在教练的督促下开了半个小时，不知道晚上10点多还在下班路途中的团队成员，有多少是没有抱怨的。

 

两周的时间很快过去，在教练离开后的第一周，经过周末的休整，大家恢复了元气，于是在周一的早上顺利开了计划会。

 

可能10个迭代已经耗尽了所有耐心，待到下午的回顾会时，有两个同事因为忙于其他事情也就不了了之，到第二天早上，计划会果然更松散了，这时PO提出，要不我们一周一个迭代吧，大家都表示赞成。

 

这下好了，周一贴的便利贴在周四时依然保持原位，这块大白板完全被打入了冷宫。SM看看大家也都在正常工作，想想自己还有事情忙，这个虚职也算不得什么，慢慢也就不提了。

 

PO继续回归到小领导的角色，偶尔加几句用户故事的标准用语：我作为一个什么什么，我想要什么什么，以便于什么什么。然后继续催促着团队成员的任务。

 

拆分故事时才发现，之前教练带着拆分故事可能10分钟，现在自己拆个20分钟还有点疑惑，不确认拆的对不对，没有底气。

 

就这样，一个所谓的敏捷团队就不伦不类地自行运转了4天，到周四下午时，突然部门的总监来问候，疑惑地看着大白板：“这个，你们还在用吗？”

 

团队成员稍微愣了一下，在SM的号召下，大家又悄悄摸摸站起来，围成一个圈圈，PO和SM建议说：要不，我们还是日迭代吧？SM也点点头，团队成员都默默地应了。

 

问题出在哪儿呢

 

“我们什么都没有做错，但是我们不敏捷了”当离场的教练两周后再次回访团队时，SM描述了现状，教练神秘一笑：“不不不，你们做错了,所以你们才不敏捷:

 

1.团队对敏捷教练的依赖性太大，忽略了时间的限制。

 

教练确实带来了变化，这也是可预见的，一个新事物进入时总会带来一些效应，而敏捷在全球多家知名企业的成功落地已经获得业内认可，所以敏捷肯定会带来积极的转变。

 

然而，短暂的改变刚唤起团队的学习劲头，教练的离场却突然让大家感觉好学的冲劲有点无处安放了，慢慢就回归到又像敏捷又不像敏捷的第三种敏捷团队了。

 

2.外力撤除前，并没有很好的种子选手培养计划。

 

Scrum团队中两个重要的角色：SM和PO。

 

教练驻场时，没有让SM和PO做到能够独当一面，所以教练离场后，SM面对各种仪式时只能按照固定的问题提问，缘于之前对教练的依赖，SM还没有太大动力和信心来自己主导各种会议，也就看不到很多团队内部存在的问题。

 

对于团队来说，其意义就是发挥一个定时提醒开会的闹钟功能。

 

PO在拆分需求时则是小心翼翼，又不确认自己拆得是否正确，只能摸着石头过河，一边履行着自己小领导的角色：督促成员交付任务；一边自己捉摸着这还是不是敏捷。

 

 

3.迭代周期的突然拉长，让团队成员一时之间有些无措，不知道什么时候开始各种仪式是最佳的，以至于无法运转一个完整的敏捷流程。

 

当外部条件发生变化时（教练离场，迭代周期变化），我们没有花费足够的时间或者是没有能力去发现，这些变化带给团队的变化是什么。事实上，人员和组织架构，都已经不同于未实行敏捷前的状态了，现在又不像完全敏捷，所以倒是弄成了一个第三世界的敏捷团队了。

 

4.团队缺乏责任感，没有强烈的目标达成意愿，成员之间也没有主动的沟通。

 

事实上，Scrum事件的密集性在不断加强我们之间的连结。

 

教练驻场时的日迭代工作中，团队的目标在不断被提及，被分析，有限的时间让目标不断被强化，责任感也就伴随而生了。

 

教练离场后团队之间逐渐变得松散，沟通也不主动，对目标的努力冲刺也越来越松懈了

 

大神来支招

 

当我们将问题一一剖析在眼前时，问题已经解决一半了。

 

小C团队的案例并不罕见，甚至可以说是国内大部分企业实行敏捷转型的缩影。面对这些问题时，我们需要做的就是拿起圣经ScrumGuide,和一位资深的敏捷老司机一起，针对每个问题见招拆招。

 

面对上述的问题，我们今天会从两个重要的角色SM和PO的方向出发，看看这两个角色应该如何转变，从而影响到整个敏捷的实施。

 

首先，这个团队需要额外增加一个SM。

原本团队中的的Team Leader变成了PO后，团队成员既要负责交付又要做SM，根本没有办法保证投入的时间，而且SM也需要一些技能。

 

我们来看看优秀的Mike Cohn对SM的技能是怎么定义的。

 

负责

优秀的SM能够并愿意承担责任。这不是只要对项目的成功负责（这是整个团队的责任），而是SM要对最大化团队的产能和支持团队成员实施及使用Scrum负责。SM承担这个责任，却没有权力。好的SM在没有权力的时候也能成功履行这些责任。

 

（小π思：这就是我们常说的以德服人，我甚至认为没有权力的SM才是完整的，因为这样逼你不得不用软技能以及Scrum的框架去实现你的责任，最大化团队的产能。）

 

谦逊

优秀的SM不会以自我为中心。他可能为自己的成就而自豪（经常是非常自豪），但这种感觉是“看看我帮助完成了什么”，而不是更加自我中心的“看看我完成了什么”。

 

谦逊的SM懂得他的工作并不能给他带来公司的配车或近电梯的停车位（通常指公司重要职位）。谦逊的SM不会把自己的需求排在第一位，而是愿意去做任何能帮助团队实现目标的事情。谦逊的SM理解全体团队成员的价值，并以身作则促成其他人达成共识。

 

小π思：很有趣的是Mike Cohn把谦逊作为SM的一项总要特质。更多的是以团队为中心，是帮助团队做到了什么，始终把团队放在主攻的位置，自己放在助攻的位置上。这也是服务型领导的很好体现，帮助团队成功。

 

协作

优秀的SM的工作是保证团队中存在一种相互协作的文化。SM需要确保团队成员能够把问题拿出来公开讨论，并与此同时得到他人的支持。

 

好的Scrum Master通过语言与行动帮助团队形成协作的氛围。当争执发生时，善于合作的Scrum Master会鼓励团队用共赢的方式思考，而不是以输赢的方式思考。优秀的Scrum Master通过与组织内部其他Scrum Master一起工作，为这类行为树立典型。

 

除了打造合作的态度，优秀的SM还会为团队合作建立规范，并指出不合适的行为（如果其他团队的成员自身没有做到这点的话）

 

小π思：很多时候SM需要以事实说话，通过事实把问题公开讨论，从而促进团队成员的交流，所以一些情况下团队成员有态度问题时候需要发挥SM的Coach能力。

 

投入

尽管做SM不总是全职的，但是确实要求全力以赴的投入。SM必须与团队成员一样，对项目及其目标有高度的奉献精神。作为这种投入的一部分，优秀的SM不会任由问题遗留多日而不解决。

 

小π思：尽管大家知道当日事当日毕，这里的确要求SM自己需要对自己的时间安排做好优先级安排，完成好自己的SM职责。这里告诉大家一个方法，当进行SM的工作的时候计算一下投入产出比，这样对事情的轻重缓急就有一个合理的安排。

 

有影响力

成功的SM会影响团队的内和团队外的人。开始时，可能需要说服团队成员尝试Scrum，或者是表现得更容易合作。后来SM可能会让团队相信要尝试一项新技术实践（例如TDD或结对编程）。SM懂得如何向别人施加影响，同时又避免独裁式的“因我这样说了”的风格。

 

许多SM也会被要求去影响团队之外的事情。例如，一位SM可能要说服一个传统的团队为Scrum团队提供一个局部的实现方案。或者，一位SM要说服QA主管为项目投入全职的测试人员。

 

尽管所有的SM要懂得如何运用自己的个人影响力，但理想的方式还是具备一定程度的公司政治技巧。“公司政治”这个词经常被用于贬义，不过一个SM了解谁能在组织内做决定，这些决定如何做出及有哪些派系等，这肯定是团队的宝贵财富。

 

小π思：这里面说的是有影响但不独裁。有影响力其实不难做到，当你不断帮助团队解决问题的时候，当团队碰到问题时候就会主动找你。这时候你的影响力就自然而然的体现了。

 

小提示是与团队坐在一起，他们需要你的时候你就马上出现。不独裁是将决策权交回给团队，技术出身的SM特别需要主义。

 

知识渊博

不光对Scrum有深刻的理解和丰富的经验，最好SM还具备技术、市场和其他的专业知识，可以帮助团队实现目标。

 

LaFasto和Larson研究过成功的团队及其领导，得出的结论为“对某事如何工作又清楚而细致的了解，领导将又更多机会帮助团队弄清楚隐藏更深但又必须解决的技术问题”。

 

虽然SM不必成为市场大师或编程专家，但他们确实对这两者要有足够多的了解，才能有效地领导团队。

小π思：在很多情况下，你了解越多的领域，你越能帮助到团队。保持一颗学习的心态，你的知识才会越来越渊博（很多时候你会发现，你可以帮助解决技术问题，虽然你不懂这种开发语言。

 

好了，我们自己对比一下以上的特质，看看你团队的SM是否具备，如果不具备怎么办。

 

第二个问题是Team Leader担任PO。

在管理产品待办列表的时候很习惯按功能，一急就按功能拆分了。我们来看看Mike Cohn对PO的职责的定义。

 

提供愿景

很多PO的职责包括确定产品的愿景，做好沟通交流。最好的团队是那些因为产品负责人分享诱人愿景而激情洋溢的团队。

 

愿景不仅仅只是清晰地存在于头脑里，PO必须向团队清楚解释愿景。他可以通过创建、维护产品待办列表并按优先级排好序来做到这一点。

 

PO还需要通过回答团队成员下面这些问题，不断丰富愿景细节：你希望用这种方式工作吗？你所说的如此这般是指什么？虽然PO可以把回答问题的任务委托给别人，但他要负责让团队得到答案。

 

提供边界

愿景与边界可以视为项目竞争方面的因素。愿景展示了产品会变成什么样，而边界则描述愿景被实现时候的现实情况。边界里PO提供并经常表示为限制条件，如：

l  我六月份需要它

l  我们要减少一半的每单位开销

l  它的速度要加倍

l  跟现在的版本相比，它只要一半的内存

 

小π思：所以PO需要把他的精力放在提供愿景与设立边界上。对于习惯与团队一起冲的Team Leader，尽量少参与细节的定义，先定好愿景并正确地描述它。

 

这个事情已经很难，不要让PO陷入到无穷的细节中，然后SM需要协助团队将交付压力逐渐移到团队成员身上。

 

这个团队的解决方案是，配合SM，让PO更多地去实践拆分产品待办列表，给PO多一些时间，思考愿景的事情。

 

在这个团队中，不幸的是，一旦外部力量消失团队产生了很大的回退，幸运的是，知道目前所面临的困难是什么。 

 

案例中的SM和PO两个角色，都不合格。

 

 SM不能作为一个开会走流程形式的角色。

 

SM可以实际的解决一些团队在日常工作中遇到的困难，特别是一些技术上的，来实际的给予团队帮助，从而让自己获得一些实际的领导力和权威，这样以后说话大家可能也会信服。 

 

那么如果没有技术背景的SM呢?

 

作为一个服务型的团队成员角色，是没有授权来管理和领导团队的，所以他如果想辅导团队就只能依靠一些软技能来达到目标，比如我们常说的“话聊”，还有一些引导技术和自己掌握的理论知识。这实际上对于个人智商，情商，沟通能力等要求都很高。

 

甚至有时候可以借助领导的威严。

 

比如邀请领导参与到某一次的会议中，让团队成员意识到领导对这个项目的重视，对SM的认可。从而便于SM以后的工作开展。

 

沟通，沟通，沟通!

如果SM想要让团队信服，就需要了解团队成员的反馈，回顾会就是一个很好的机会。

 

在回顾会议上，引导团队成员阐述对SM的期望和看法，然后SM朝着这个方向努力，及时的反馈与调整也是敏捷所提倡的精神。

 

说完SM我们再看PO

 

一个称职的PO需要和团队工作在一起，却不能干涉团队太多，也不能将交付作为唯一标准。

 

不能干涉团队太多。

很多大型企业，PO是由原来团队中的技术专家转型而来，这样的好处是PO对产品技术很熟悉，但是带来不好的一点是在Scrum的日常工作中，PO往往会惯性地纠结于各种实现细节，从而让团队觉得PO对团队的工作干涉过多。

 

PO更应该注重资源的调配和需求还有ProductBacklog的管理，避免使自己陷入技术细节的讨论。

 

不能将交付作为唯一标准。

众所周知，Scrum团队的velocity是衡量团队的一个标准，但不应该是唯一标准。因为团队的交付能力随着团队成熟度的上升而达到一个平衡，不能无限增加。

 

看到很多团队的PO考量团队的时候，如果交付能力多的就是好团队，交付能力少的就是不好的团队。这样会对团队传输一个不好的信号，就是会在日后的工作中片面强调交付，还有相关的数据，从而使得团队的成长走向一个错误的方向。

 

PO的主要职责：

PO要不断地梳理Product Backlog，并做出正确的决策。

 

极优秀的PO勇于去说“不”，去做减法，因为PO要面对大量来自不同干系人的声音和信息。

 

好的Product Backlog管理不是左右逢源，PO应该不允许Product Backlog无休止的膨胀，而应该能让团队工作聚焦，全力以赴地关注最重要的东西。

 

附和及迎合所有人的意见的产品管理不是最优秀PO所追求的。

 

 

我的团队怎么办

 

一个企业没有真正做到敏捷的原因很多，这跟企业文化，企业内部的机制都有关系，需要专业的敏捷教练指导，同时，更需要我们自身的成长。

 

面对上述案例时，除了两个SM和PO角色应该纠正，其他如团队成员的配合，针对项目的适合工具，企业的文化等等，都是需要关注的点。

 

如果你也在敏捷的边缘一筹莫展，或是陷入伪敏捷的深渊无法自拔，那么拯救自己和纠正团队的机会来了。

 

敏捷行动派的“7天线上训练营”重磅来袭：十年敏捷转型实战经验，世界500强企业盛誉的组织级敏捷专家带队历时200小时精心打磨，为所有敏捷人带来的前所未有的线上学习体验。