导读  ID:TOP100case

    导读：在缺少外部指导，对敏捷认识也极其有限的情况下，团队如何从自己遇到的问题出发，通过反复摸索，找出新路？敏捷团队的成长究竟需要经历什么样的阶段和辅助条件？敏捷真正的核心究竟是什么？当转型之路从团队往更大一级组织扩展时，我们又能从以前的经验教训中获得什么样的帮助？

    本案例通过再现一些真实的故事，讲述一支传统团队如何通过不断尝试探索自己的工作流程，实现集体职责共享，提升质量及学习意识，从而成功实现敏捷转型。

案例简述

三年前，中兴网管UEP项目告警团队在懵懂中开始了自己的敏捷转型之旅。在缺少外部指导，对敏捷认识也极其有限的情况下，团队如何从自己遇到的问题出发，通过反复摸索，找出新路？

本案例讲述了转型过程中，团队发生的一些故事，包括：传纸条的故事、回顾会的故事、防火墙的故事、测试休假故事。通过这些，我们可以了解到一支传统团队是如何通过不断尝试，探索自己的工作流程，实现集体职责共享，提升质量及学习意识，从而不断成长的。

今天，再次审视这些故事时，我们也在思考，敏捷团队的成长究竟需要经历什么样的阶段和辅助条件？敏捷真正的核心究竟是什么？当转型之路从团队往更大一级组织扩展时，我们又能从以前的经验教训中获得什么样的帮助？

案例背景

中兴网管UEP项目是从2008年末启动的平台项目，历经2009年试商用，2010至2012年逐渐全面铺开，项目总人数达到百人规模，自研代码超过300万行。

2011年底，整个项目进行了组织结构调整，除少数公共测试外，大部分测试进入研发团队，形成全职能的UST（统一服务团队）。每个UST少则4人，多不超过9人，每2-3个UST归属一个科室，由一位重点关注需求计划和周任务安排的研发科长管理。我们的转型故事就发生在这样一个UST中。

当时这个UST有6人，包括1位开发经理，1位测试，4位开发人员中，1人是参与项目2年半的资深员工，3人则是进入项目不到1年的新员工。

早几年前，该UST的现任开发经理（在UST成立前是科室的研发骨干）更多聚集于技术实践，所以该团队的持续集成系统，单元测试工具及技能储备、WIKI知识库建设等都已经有一定基础，但这些工具并不能解决团队当前遇到的问题。

随着11年大量新员工加入，团队成员的平均代码水平有所下降、而且，项目大规模商用铺开后，外场支持压力和更多专业网的新需求开发任务都在激增，整个团队不知不觉间已跌入焦油坑。不断增加的救火任务不停消耗着团队有限的精力，由于精力分散再加上队员能力和配合上的问题使得新需求开发效率和质量情况极不令人乐观，而这又进一步导致更多救火任务出现。难以突破的怪圈，使得团队士气不断下降，下一步，团队将何去何从，这是个严重问题！

故事再现

● 传纸条的故事

团队迈出怪圈的第一步从传纸条开始。

一次周任务研发过程中，两名队员领取了两个看上去独立，实现上却存在严重相关性的任务。但在整个编码及测试过程中竟然一直没人发现问题。这件事刺激了团队，经过讨论，他们采用了一种把任务记在便利贴上，并把贴纸在队员之间来回传递的方式来规范相互间协作。

这是团队可视化协作改进的起点，它极其简单，甚至连白板都没有使用。但正是这微不足道的改进，团队惊奇的发现，小小纸条的价值绝不可小看，它直接影响并导致了后来团队的一系列改变。

通过纸条变革，团队总结出了可视化的五大价值：

·         队员之间的协作流程清晰化；

·         实物情节增强了办事成就感；

·         可视化对周边的影响力辐射；

·         得领导认可，赢获更多支持；

·          新问题，引出下步改进。

● 回顾会的故事

从纸条变革开始，团队转型第二件最有价值的事是启动并长期坚持召开回顾会议，并最终形成了一周一回顾的持续改进闭环。这是支持团队转型最重要的制度基础，但坚持此会的过程并不容易，它先后经历了多个阶段：

·         团队领导（研发科长、开发经理）根据需要偶然召开回顾会，队员被动参与。这阶段实际上不能真正及时发现并解决团队问题。

·         固定节奏的回顾会制度，但话题和改进措施都是团队领导提出，队员被动执行。这阶段很多人觉得开回顾会是在浪费自己时间。

·         团队领导尝试通过头脑风暴等方式收集队员意见，却发现会议变成吐槽大会，大家提出的都是非常大的全局性问题，而且都认为这是别人的问题，应该反馈给项目，让其他人去改。这时候团队领导也很困惑，回顾会真有价值么？难道让队员主动去考虑团队改进问题，让他们自觉去实践改进真是件不现实的事？

·         队员开始提出一些自己能够搞定的问题缓解办法，但同时也发现可改进的东西太多，大家根本无力投入实施。团队领导也在思考，队员承诺改进却不去做，难道真是因为大家只习惯于在强制命令，考核督导下做事？

·         收敛改进项，每次回顾会只选择一个（最多两个）改进。当在改进内容和精力投入间做出调整后，改进之轮终于能比较顺畅的转动。很快我们发现，高频小改进（比如每周半小时会议，设定一个改进项）的效率远远胜过低频大改进（比如三周一个半小时会议，一次设定三个改进项）。

·         把改进当做两次回顾会间隔之间的小尝试。没有“改进”，只有“尝试”。尝试是中性的，且无关乎好坏，最坏的尝试最多也就是持续满一个回顾周期，而一周一次的高频回顾会议能有效缩短回顾周期，也控制了试错代价。此种信念指导下，大家开始更加放松的投入到各种尝试中。

·         发现回顾会也是团队协作场域的调节器，不一定每次都需要产生外部尝试动作，因为会议自身就是在不断改善团队的协作。

● 防火墙的故事

可视化和回顾会打造了团队持续改进的基础，那进一步，我们该如何去引导团队更好地做事？在很多情况下，当团队领导看到团队层面问题时，会自然而然从问题本身出发，下达命令要求团队执行来解决问题。比如发现团队中存在技术壁垒，特定人只能做特定事，导致团队人力调配受到严重限制时就强制规定队员间结对互备。

但是，这种解决方案实施效果往往并不好，这是因为团队整体利益和个人痛点之间缺少足够联系，队员并不会天然就基于团队利益去做事。在这个问题上，告警团队采用了一种特殊的改进步骤，总结起来就是：

·         解决集体问题，先跟个人痛点

·         解决个人痛点，带动行为改变

·         连续小步改变，导向集体目标

该方法的实际案例，就是团队防火墙的形成过程。当团队发现队员们越来越和特定模块绑定，不管在计划会上估算，还是每日立会讨论问题，每个人都只表现出对“自己模块”事务才关心时，并没有直接下命令去改变这点。而是先访谈队员，了解到他们的共性痛点是对外支持任务多、杂且随时会出现，导致无法专注的编码做需求。

开发经理在回顾会上抛出此问题，引发了队员们强烈共鸣，所有人都觉得应该有所改变。于是全员同意成立防火墙机制，并规定：各开发按月轮流担当对外防火墙，负责全团队对外支持工作；开发经理默认是第二支持，负责和防火墙一起解决疑难问题；防火墙尽量直接搞定外部支持，若搞不定先查WIKI知识库中有无相关记录，还找不到，则找该功能以前的维护队员，该队员必须无条件支持防火墙工作。

防火墙制度开始运作后，虽然头几个月也遭遇诸多困难，但当熬过这段时期后，团队发现模块壁垒问题竟然慢慢消失了。

站在防火墙队员这方面，他现在能从全局角度看待整个团队的问题。随着和外部用户交流增多，他更多体会到从用户视角看待我们系统是什么样子，这让他越来越多的反思我们以前的编码方式、日志记录和文档编写习惯。同时，在支持工作中，他看到了更多模块的代码，对导致维护痛苦的烂代码越来越难以容忍，越来越愿意学习那些写得好的代码。

对于其他队员：

·         一方面由于防火墙队员在知识库中找不到必要的信息时，还是会不断来打扰自己，所以他们会倾向在WIKI系统中多写将来可能会用的信息，这导致了知识库中的有用信息进一步丰富。

·         另一方面，由于防火墙是轮流担任，为了自己当防火墙更方便，他们开始更多开始关注他人工作。

·         第三，由于承担过防火墙支持工作，现在大家对烂代码的坏处更有切身体会，所以他们现在的代码会尽量争取有更好的可读性和可维护性。

结果，不到一年时间，困扰团队的技术壁垒问题逐渐减弱并最终消散了，而且伴随着团队知识库有用内容的极大丰富。整个团队的整体目标意识极大加强。

● 测试休假故事

某一天测试MM怀孕了，因为身体原因，她马上就会请一年以上长假。由于项目组没有其他测试能投入团队，而且历史上测试一直在团队中起最后的质量守门员作用，这导致整个团队进入危机状态。所有人都担心团队质量会大幅下滑，故障泄露率将直线走高。但令人意外的是，几个月，甚至持续一年后的统计数据表明，团队外部泄露和内部故障数是呈双下降趋势！

促使此现象发生的直接原因是，当所有开发人员发现自己身后不再有其他安全网，必须靠自己把事情做对时，他们的质量意识明显上升。而且，在危机面前，所有人都觉得做出改变应对是必须的，所以虽然团队人数减少一名，团队内队员交叉走查，交叉测试，单元测试编写和学习交流等活动反而更好的借此开展起来。而且，通过这次事件，也让整个团队重新思考测试在团队中的作用和定位，这为团队在后来接受测试前移，实例化需求等理念打下了思想基础。

通过这次危机，我们见识到了危机时刻在团队转型中的强大促进作用。当团队经过了初期碰撞，转型基础已经构建完毕，通过先跟后带等方式让团队自组织性建设达到一定程度后，运用或者制造一些危机让团队去经历风雨并进一步成长是一种极为有效的方法。

案例启示

总之，通过一系列的转型动作，团队终于突破了早期的困扰，进入一个全新阶段。虽然，团队转型之路不会有终结，旧的问题解决，新的问题还会继续。但是这并不妨碍我们总结已有经验，并思考这些经验对未来的意义。

首先，通过这四个小故事，我们看到了团队转型三阶段需要实施的不同建设方法：

阶段一是基础期：这时候最重要的是帮助团队打好持续改变的基础。其两大核心手段：

·         一是引入可视化来展示团队工作状态，同时 问题，为下一阶段改变做准备。

·         二是努力在团队中引入正式的回顾制度，让团队开始定期审视自己的工作方式，并引发团队成员积极参与到微改进微尝试中来。

由于历史惯性，初期的回顾会往往得不到多少建设性意见，以致很多工作繁忙的团队，会把这看起来和业务不直接相关的活动当作额外浪费而“优化”掉，但我们希望团队领导和团队成员坚持下去，回顾会的长期价值要远远超过其他各种活动。

阶段二是引导期：虽然有了基础制度保障，此时团队还很稚嫩，变革发动者需要采用先跟后带、小步促变的方式来引导团队，并最终将团队成员的个人痛点解决和团队目标整合到一起，以此增强团队的凝聚力和自组织性。

阶段三是磨砺期：当团队成长到一定阶段后，促进其进一步成长的重要方法就是危机。不管是运用突发危机，还是设法制造出一些可控危机，危机时刻能够激发团队潜力，并刺激团队进一步成长。

其次，通过回顾告警团队转型之路，我们也在思考，什么是敏捷最核心的东西？现在我们回过头来讲述几年前团队敏捷转型起步阶段的故事，是否还有其他现实意义？。

我觉得，敏捷的核心有两者：

·         从当下开始，持续保持对自身状态的审视，朝着目标方向，快速试错并不断调整，这是敏捷性的基本含义。

·         而通过用微观和宏观手段引导组织不断往更适应变化方向进化，这是敏捷性的现实承载。

至于其他的具体敏捷实践、敏捷框架及敏捷方法都只是达成敏捷性的辅助工具。

几年前，当团队蹒跚踏上改变之路时，严重缺乏敏捷工具及实践方法支持，大家只能从解决问题开始，不断摸索尝试。这样确实走过不少弯路，但整个探索过程既不受既有条框的限制，也始终在推动大家思考总结，这使得整个团队能始终行走在敏捷改进的道路上。

今天，各种敏捷工具和方法已极大丰富，各地转型实践也提供了大量现成经验。但是，我们在组织中推广敏捷时，是否会因对敏捷形式的强调，而导致新的僵化产生？是否会因为大量现成经验指导，让受众缺少不断试错调整而引发的深入思考过程，从而使新的敏捷探索只停留于表皮？对此需要保持足够警惕！

所以，在此重新整理当年团队转型的历史，既是提醒自己，也是和大家交流对敏捷初心的认识。

（张莹原创）

导读  ID:TOP100case

    导读：在缺少外部指导，对敏捷认识也极其有限的情况下，团队如何从自己遇到的问题出发，通过反复摸索，找出新路？敏捷团队的成长究竟需要经历什么样的阶段和辅助条件？敏捷真正的核心究竟是什么？当转型之路从团队往更大一级组织扩展时，我们又能从以前的经验教训中获得什么样的帮助？

    本案例通过再现一些真实的故事，讲述一支传统团队如何通过不断尝试探索自己的工作流程，实现集体职责共享，提升质量及学习意识，从而成功实现敏捷转型。

案例简述

三年前，中兴网管UEP项目告警团队在懵懂中开始了自己的敏捷转型之旅。在缺少外部指导，对敏捷认识也极其有限的情况下，团队如何从自己遇到的问题出发，通过反复摸索，找出新路？

本案例讲述了转型过程中，团队发生的一些故事，包括：传纸条的故事、回顾会的故事、防火墙的故事、测试休假故事。通过这些，我们可以了解到一支传统团队是如何通过不断尝试，探索自己的工作流程，实现集体职责共享，提升质量及学习意识，从而不断成长的。

今天，再次审视这些故事时，我们也在思考，敏捷团队的成长究竟需要经历什么样的阶段和辅助条件？敏捷真正的核心究竟是什么？当转型之路从团队往更大一级组织扩展时，我们又能从以前的经验教训中获得什么样的帮助？

案例背景

中兴网管UEP项目是从2008年末启动的平台项目，历经2009年试商用，2010至2012年逐渐全面铺开，项目总人数达到百人规模，自研代码超过300万行。

2011年底，整个项目进行了组织结构调整，除少数公共测试外，大部分测试进入研发团队，形成全职能的UST（统一服务团队）。每个UST少则4人，多不超过9人，每2-3个UST归属一个科室，由一位重点关注需求计划和周任务安排的研发科长管理。我们的转型故事就发生在这样一个UST中。

当时这个UST有6人，包括1位开发经理，1位测试，4位开发人员中，1人是参与项目2年半的资深员工，3人则是进入项目不到1年的新员工。

早几年前，该UST的现任开发经理（在UST成立前是科室的研发骨干）更多聚集于技术实践，所以该团队的持续集成系统，单元测试工具及技能储备、WIKI知识库建设等都已经有一定基础，但这些工具并不能解决团队当前遇到的问题。

随着11年大量新员工加入，团队成员的平均代码水平有所下降、而且，项目大规模商用铺开后，外场支持压力和更多专业网的新需求开发任务都在激增，整个团队不知不觉间已跌入焦油坑。不断增加的救火任务不停消耗着团队有限的精力，由于精力分散再加上队员能力和配合上的问题使得新需求开发效率和质量情况极不令人乐观，而这又进一步导致更多救火任务出现。难以突破的怪圈，使得团队士气不断下降，下一步，团队将何去何从，这是个严重问题！

故事再现

● 传纸条的故事

团队迈出怪圈的第一步从传纸条开始。

一次周任务研发过程中，两名队员领取了两个看上去独立，实现上却存在严重相关性的任务。但在整个编码及测试过程中竟然一直没人发现问题。这件事刺激了团队，经过讨论，他们采用了一种把任务记在便利贴上，并把贴纸在队员之间来回传递的方式来规范相互间协作。

这是团队可视化协作改进的起点，它极其简单，甚至连白板都没有使用。但正是这微不足道的改进，团队惊奇的发现，小小纸条的价值绝不可小看，它直接影响并导致了后来团队的一系列改变。

通过纸条变革，团队总结出了可视化的五大价值：

·         队员之间的协作流程清晰化；

·         实物情节增强了办事成就感；

·         可视化对周边的影响力辐射；

·         得领导认可，赢获更多支持；

·          新问题，引出下步改进。

● 回顾会的故事

从纸条变革开始，团队转型第二件最有价值的事是启动并长期坚持召开回顾会议，并最终形成了一周一回顾的持续改进闭环。这是支持团队转型最重要的制度基础，但坚持此会的过程并不容易，它先后经历了多个阶段：

·         团队领导（研发科长、开发经理）根据需要偶然召开回顾会，队员被动参与。这阶段实际上不能真正及时发现并解决团队问题。

·         固定节奏的回顾会制度，但话题和改进措施都是团队领导提出，队员被动执行。这阶段很多人觉得开回顾会是在浪费自己时间。

·         团队领导尝试通过头脑风暴等方式收集队员意见，却发现会议变成吐槽大会，大家提出的都是非常大的全局性问题，而且都认为这是别人的问题，应该反馈给项目，让其他人去改。这时候团队领导也很困惑，回顾会真有价值么？难道让队员主动去考虑团队改进问题，让他们自觉去实践改进真是件不现实的事？

·         队员开始提出一些自己能够搞定的问题缓解办法，但同时也发现可改进的东西太多，大家根本无力投入实施。团队领导也在思考，队员承诺改进却不去做，难道真是因为大家只习惯于在强制命令，考核督导下做事？

·         收敛改进项，每次回顾会只选择一个（最多两个）改进。当在改进内容和精力投入间做出调整后，改进之轮终于能比较顺畅的转动。很快我们发现，高频小改进（比如每周半小时会议，设定一个改进项）的效率远远胜过低频大改进（比如三周一个半小时会议，一次设定三个改进项）。

·         把改进当做两次回顾会间隔之间的小尝试。没有“改进”，只有“尝试”。尝试是中性的，且无关乎好坏，最坏的尝试最多也就是持续满一个回顾周期，而一周一次的高频回顾会议能有效缩短回顾周期，也控制了试错代价。此种信念指导下，大家开始更加放松的投入到各种尝试中。

·         发现回顾会也是团队协作场域的调节器，不一定每次都需要产生外部尝试动作，因为会议自身就是在不断改善团队的协作。

● 防火墙的故事

可视化和回顾会打造了团队持续改进的基础，那进一步，我们该如何去引导团队更好地做事？在很多情况下，当团队领导看到团队层面问题时，会自然而然从问题本身出发，下达命令要求团队执行来解决问题。比如发现团队中存在技术壁垒，特定人只能做特定事，导致团队人力调配受到严重限制时就强制规定队员间结对互备。

但是，这种解决方案实施效果往往并不好，这是因为团队整体利益和个人痛点之间缺少足够联系，队员并不会天然就基于团队利益去做事。在这个问题上，告警团队采用了一种特殊的改进步骤，总结起来就是：

·         解决集体问题，先跟个人痛点

·         解决个人痛点，带动行为改变

·         连续小步改变，导向集体目标

该方法的实际案例，就是团队防火墙的形成过程。当团队发现队员们越来越和特定模块绑定，不管在计划会上估算，还是每日立会讨论问题，每个人都只表现出对“自己模块”事务才关心时，并没有直接下命令去改变这点。而是先访谈队员，了解到他们的共性痛点是对外支持任务多、杂且随时会出现，导致无法专注的编码做需求。

开发经理在回顾会上抛出此问题，引发了队员们强烈共鸣，所有人都觉得应该有所改变。于是全员同意成立防火墙机制，并规定：各开发按月轮流担当对外防火墙，负责全团队对外支持工作；开发经理默认是第二支持，负责和防火墙一起解决疑难问题；防火墙尽量直接搞定外部支持，若搞不定先查WIKI知识库中有无相关记录，还找不到，则找该功能以前的维护队员，该队员必须无条件支持防火墙工作。

防火墙制度开始运作后，虽然头几个月也遭遇诸多困难，但当熬过这段时期后，团队发现模块壁垒问题竟然慢慢消失了。

站在防火墙队员这方面，他现在能从全局角度看待整个团队的问题。随着和外部用户交流增多，他更多体会到从用户视角看待我们系统是什么样子，这让他越来越多的反思我们以前的编码方式、日志记录和文档编写习惯。同时，在支持工作中，他看到了更多模块的代码，对导致维护痛苦的烂代码越来越难以容忍，越来越愿意学习那些写得好的代码。

对于其他队员：

·         一方面由于防火墙队员在知识库中找不到必要的信息时，还是会不断来打扰自己，所以他们会倾向在WIKI系统中多写将来可能会用的信息，这导致了知识库中的有用信息进一步丰富。

·         另一方面，由于防火墙是轮流担任，为了自己当防火墙更方便，他们开始更多开始关注他人工作。

·         第三，由于承担过防火墙支持工作，现在大家对烂代码的坏处更有切身体会，所以他们现在的代码会尽量争取有更好的可读性和可维护性。

结果，不到一年时间，困扰团队的技术壁垒问题逐渐减弱并最终消散了，而且伴随着团队知识库有用内容的极大丰富。整个团队的整体目标意识极大加强。

● 测试休假故事

某一天测试MM怀孕了，因为身体原因，她马上就会请一年以上长假。由于项目组没有其他测试能投入团队，而且历史上测试一直在团队中起最后的质量守门员作用，这导致整个团队进入危机状态。所有人都担心团队质量会大幅下滑，故障泄露率将直线走高。但令人意外的是，几个月，甚至持续一年后的统计数据表明，团队外部泄露和内部故障数是呈双下降趋势！

促使此现象发生的直接原因是，当所有开发人员发现自己身后不再有其他安全网，必须靠自己把事情做对时，他们的质量意识明显上升。而且，在危机面前，所有人都觉得做出改变应对是必须的，所以虽然团队人数减少一名，团队内队员交叉走查，交叉测试，单元测试编写和学习交流等活动反而更好的借此开展起来。而且，通过这次事件，也让整个团队重新思考测试在团队中的作用和定位，这为团队在后来接受测试前移，实例化需求等理念打下了思想基础。

通过这次危机，我们见识到了危机时刻在团队转型中的强大促进作用。当团队经过了初期碰撞，转型基础已经构建完毕，通过先跟后带等方式让团队自组织性建设达到一定程度后，运用或者制造一些危机让团队去经历风雨并进一步成长是一种极为有效的方法。

案例启示

总之，通过一系列的转型动作，团队终于突破了早期的困扰，进入一个全新阶段。虽然，团队转型之路不会有终结，旧的问题解决，新的问题还会继续。但是这并不妨碍我们总结已有经验，并思考这些经验对未来的意义。

首先，通过这四个小故事，我们看到了团队转型三阶段需要实施的不同建设方法：

阶段一是基础期：这时候最重要的是帮助团队打好持续改变的基础。其两大核心手段：

·         一是引入可视化来展示团队工作状态，同时 问题，为下一阶段改变做准备。

·         二是努力在团队中引入正式的回顾制度，让团队开始定期审视自己的工作方式，并引发团队成员积极参与到微改进微尝试中来。

由于历史惯性，初期的回顾会往往得不到多少建设性意见，以致很多工作繁忙的团队，会把这看起来和业务不直接相关的活动当作额外浪费而“优化”掉，但我们希望团队领导和团队成员坚持下去，回顾会的长期价值要远远超过其他各种活动。

阶段二是引导期：虽然有了基础制度保障，此时团队还很稚嫩，变革发动者需要采用先跟后带、小步促变的方式来引导团队，并最终将团队成员的个人痛点解决和团队目标整合到一起，以此增强团队的凝聚力和自组织性。

阶段三是磨砺期：当团队成长到一定阶段后，促进其进一步成长的重要方法就是危机。不管是运用突发危机，还是设法制造出一些可控危机，危机时刻能够激发团队潜力，并刺激团队进一步成长。

其次，通过回顾告警团队转型之路，我们也在思考，什么是敏捷最核心的东西？现在我们回过头来讲述几年前团队敏捷转型起步阶段的故事，是否还有其他现实意义？。

我觉得，敏捷的核心有两者：

·         从当下开始，持续保持对自身状态的审视，朝着目标方向，快速试错并不断调整，这是敏捷性的基本含义。

·         而通过用微观和宏观手段引导组织不断往更适应变化方向进化，这是敏捷性的现实承载。

至于其他的具体敏捷实践、敏捷框架及敏捷方法都只是达成敏捷性的辅助工具。

几年前，当团队蹒跚踏上改变之路时，严重缺乏敏捷工具及实践方法支持，大家只能从解决问题开始，不断摸索尝试。这样确实走过不少弯路，但整个探索过程既不受既有条框的限制，也始终在推动大家思考总结，这使得整个团队能始终行走在敏捷改进的道路上。

今天，各种敏捷工具和方法已极大丰富，各地转型实践也提供了大量现成经验。但是，我们在组织中推广敏捷时，是否会因对敏捷形式的强调，而导致新的僵化产生？是否会因为大量现成经验指导，让受众缺少不断试错调整而引发的深入思考过程，从而使新的敏捷探索只停留于表皮？对此需要保持足够警惕！

所以，在此重新整理当年团队转型的历史，既是提醒自己，也是和大家交流对敏捷初心的认识。

（张莹原创）