敏捷实践社区是以敏捷实践为单位构成的虚拟组织，比如ScrumIT运维管理社区、持续交付俱乐部、测试自动化社群等。敏捷社区是由企业员工自愿组织的兴趣社团，本着交流敏捷实践、提升企业的敏捷能力为目的。敏捷实践社区的组建是敏捷转型委员会Backlog中的一项，可以由企业员工自己主动认领（但不应该由领导自上而下任命组建）；也可以由企业员工凭兴趣自发组建。

如果说敏捷转型委员会是组织的官方力量，那么敏捷实践社区便是组织的民间力量，它就像组织里播种的敏捷种子，生命力顽强且传播迅速。

企业C在开展敏捷转型时，成立了两个实践社区。

（1） ScrumMasterIT运维管理社区

这个社区的宗旨是为那些新的ScrumMaster提供快速成长的平台。由一位ScrumMaster主动发起，每隔两周召集公司所有ScrumMaster聚集一次交流经验，每次交流的话题由大家投票决定。

（2） 持续集成俱乐部

增强团队持续集成的能力是转型委员会Backlog里的一项重要工作。转型委员会将这项工作拆分成了几个重要任务，其中一个是成立持续集成社区，让持续集成实践在组织里迅速传播。委员会在企业内网上发布了求贤贴，招募社区的组织者。不久，一位工程师报名，他在之前的企业里有深厚的持续集成、自动化测试的经验，来到一个持续集成从零起步的组织，难以忍受这里落后的工作环境，于是主动请缨，愿意组建这个社区，传播持续集成和测试自动化实践。

此外，每个敏捷试点团队也是重要的敏捷种子，他们身体力行地每天在实际工作中实践敏捷。敏捷转型委员会与试点团队、实践社区的关系如图4-2所示。

图4-2敏捷转型委员会与试点团队、实践社区的关系

首先，敏捷转型委员会、试点团队与实践社区的运作模式就像一个独立的Scrum团队，他们各自维护一个改进事项Backlog，迭代式运作，持续改进。

其次，实践社区与试点团队之间也有密切的合作关系。实践社区将业内优秀的实践和必要的知识及时传递给每个试点团队，帮助其快速成长；试点团队定期将自己实践的一线经验分享给各个实践社区。由于实践社区组建的范围覆盖到整个企业，所以，试点团队通过实践社区可以将自己的经验迅速传播到企业的其他团队，从而加速敏捷在整个企业范围内的发展。

最后，这三个组织单元之间保持密切协作。敏捷转型委员会向每个试点团队、实践社区沟通转型愿景，并授权实践社区和试点团队自管理。每个试点团队、实践社区向敏捷转型委员会反馈其需要的支持和遇到的障碍，敏捷转型委员会再把这些反馈纳入Backlog。

2.提供培训和辅导

敏捷涉及企业内的所有人。因此，最好让每个人都接受正式的敏捷导入培训。但是碍于企业人数众多以及预算有限等原因，往往不可能让每个员工同时参加培训，因此企业可以分多个批次滚动式进行培训。企业可以让管理团队先参加培训，然后让项目经理、产品经理、测试经理等项目一线管理人员参加培训；选定试点团队后，让试点团队全员参加培训；之后，在每个新的团队启动敏捷之前为这些团队提供培训。

当然只培训还远远不够，敏捷转型委员会还需要雇用或培养敏捷教练，为管理层和试点团队提供手把手的辅导。敏捷教练的辅导着重针对以下角色：

• 每个试点团队的ScrumMaster和产品负责人；
• 职能经理层；
• 开发者和测试者。
  

敏捷教练的辅导可以从以下几个维度开展。

• 对试点团队的辅导，要遵循试点团队的迭代周期。迭代计划、每日站会、每日开发工作、迭代回顾和评审都是可以辅导的时间点。
• 对管理层的辅导，可以采取“一对一”的线下交流方式。在管理者反馈自己的疑惑或担忧的时候，正是开展辅导的好时机。此外，敏捷转型委员会的例行会议对整个管理层的每个职能经理来说都是开展“一对多”辅导的好机会。
• 对技术实践的辅导，要深入团队的每日开发和测试工作中，与团队坐在一起工作，这样便于开展辅导。
• 对关键角色的辅导，比如ScrumMaster、产品负责人、职能经理，可以采取“一对一”的方式，针对每个人的实际情况开展辅导。
  

培训和辅导的过程不只是传递知识和经验，同时还是消除阻碍、消除员工对敏捷的抵触心理的过程。

3.敢于解除与敏捷转型相左的流程桎梏

在敏捷转型的道路上，如何对待与敏捷相左的现有流程呢？这需要管理层具备大格局思维，为了实现更大的愿景，敢于改变组织现有体制中与敏捷转型相违背的流程，哪怕要承担风险，面对抵触和指责。

企业F启动敏捷转型的试点后，很快团队 出一个问题：按照公司原有的流程，每个工程师需要在每天下班前给部门经理和组长发日报，即总结今天做了什么，工作有什么进展和问题；此外，每个团队的组长在每天下班前需要将每个工程师的日报汇总成一个团队日报，发给整个项目群的经理。

团队发现，自从试点敏捷后一切信息和状态都可以在看板上呈现，不再需要大家做日报。如果哪位领导感兴趣，完全可以通过看板看到一切信息。

敏捷转型委员会就这个议题开展了讨论，一些部门经理仍旧习惯于在座位上收取邮件报告；项目群经理也认为，发日报的习惯一直都有，不能因为做敏捷就取消了。试点团队的ScrumMaster反馈，开展敏捷后，因为团队有每日站会的实践，他不再需要工程师发日报就可以清楚地知道每个人的工作状态。如果还让大家发日报，会让大家非常反感。日报和站会，只能保留其一。

经过激烈的讨论后，敏捷转型委员会决定，自此取消工程师发日报的工作，因为站会是高效的团队协作工具，在开展站会实践的团队里，做日报是一个不增值的工作。

在管理者眼里，做日报不是件大事，每天只耗费工程师10分钟的时间。但是在工程师的眼里，每天重复花10分钟做一件浪费时间的工作是一件令人沮丧的事情。如果敏捷转型委员会不采取措施改变原有的工作方式，那么团队会认为敏捷加重了其工作负担，即在做原有的日报、周报等基础上，又增加了一些新的管理会议，每天还得移动看板上的用户故事和任务卡片。

需要注意的是，不是现有的管理制度都需要向敏捷转型让路。转型委员会需要针对每个冲突情况分析风险和代价来决策。有些时候，企业改变现有流程的时机或许还不合适，需要推迟改变的时间。

敏捷实践社区是以敏捷实践为单位构成的虚拟组织，比如ScrumIT运维管理社区、持续交付俱乐部、测试自动化社群等。敏捷社区是由企业员工自愿组织的兴趣社团，本着交流敏捷实践、提升企业的敏捷能力为目的。敏捷实践社区的组建是敏捷转型委员会Backlog中的一项，可以由企业员工自己主动认领（但不应该由领导自上而下任命组建）；也可以由企业员工凭兴趣自发组建。

如果说敏捷转型委员会是组织的官方力量，那么敏捷实践社区便是组织的民间力量，它就像组织里播种的敏捷种子，生命力顽强且传播迅速。

企业C在开展敏捷转型时，成立了两个实践社区。

（1） ScrumMasterIT运维管理社区

这个社区的宗旨是为那些新的ScrumMaster提供快速成长的平台。由一位ScrumMaster主动发起，每隔两周召集公司所有ScrumMaster聚集一次交流经验，每次交流的话题由大家投票决定。

（2） 持续集成俱乐部

增强团队持续集成的能力是转型委员会Backlog里的一项重要工作。转型委员会将这项工作拆分成了几个重要任务，其中一个是成立持续集成社区，让持续集成实践在组织里迅速传播。委员会在企业内网上发布了求贤贴，招募社区的组织者。不久，一位工程师报名，他在之前的企业里有深厚的持续集成、自动化测试的经验，来到一个持续集成从零起步的组织，难以忍受这里落后的工作环境，于是主动请缨，愿意组建这个社区，传播持续集成和测试自动化实践。

此外，每个敏捷试点团队也是重要的敏捷种子，他们身体力行地每天在实际工作中实践敏捷。敏捷转型委员会与试点团队、实践社区的关系如图4-2所示。

图4-2敏捷转型委员会与试点团队、实践社区的关系

首先，敏捷转型委员会、试点团队与实践社区的运作模式就像一个独立的Scrum团队，他们各自维护一个改进事项Backlog，迭代式运作，持续改进。

其次，实践社区与试点团队之间也有密切的合作关系。实践社区将业内优秀的实践和必要的知识及时传递给每个试点团队，帮助其快速成长；试点团队定期将自己实践的一线经验分享给各个实践社区。由于实践社区组建的范围覆盖到整个企业，所以，试点团队通过实践社区可以将自己的经验迅速传播到企业的其他团队，从而加速敏捷在整个企业范围内的发展。

最后，这三个组织单元之间保持密切协作。敏捷转型委员会向每个试点团队、实践社区沟通转型愿景，并授权实践社区和试点团队自管理。每个试点团队、实践社区向敏捷转型委员会反馈其需要的支持和遇到的障碍，敏捷转型委员会再把这些反馈纳入Backlog。

2.提供培训和辅导

敏捷涉及企业内的所有人。因此，最好让每个人都接受正式的敏捷导入培训。但是碍于企业人数众多以及预算有限等原因，往往不可能让每个员工同时参加培训，因此企业可以分多个批次滚动式进行培训。企业可以让管理团队先参加培训，然后让项目经理、产品经理、测试经理等项目一线管理人员参加培训；选定试点团队后，让试点团队全员参加培训；之后，在每个新的团队启动敏捷之前为这些团队提供培训。

当然只培训还远远不够，敏捷转型委员会还需要雇用或培养敏捷教练，为管理层和试点团队提供手把手的辅导。敏捷教练的辅导着重针对以下角色：

• 每个试点团队的ScrumMaster和产品负责人；
• 职能经理层；
• 开发者和测试者。
  

敏捷教练的辅导可以从以下几个维度开展。

• 对试点团队的辅导，要遵循试点团队的迭代周期。迭代计划、每日站会、每日开发工作、迭代回顾和评审都是可以辅导的时间点。
• 对管理层的辅导，可以采取“一对一”的线下交流方式。在管理者反馈自己的疑惑或担忧的时候，正是开展辅导的好时机。此外，敏捷转型委员会的例行会议对整个管理层的每个职能经理来说都是开展“一对多”辅导的好机会。
• 对技术实践的辅导，要深入团队的每日开发和测试工作中，与团队坐在一起工作，这样便于开展辅导。
• 对关键角色的辅导，比如ScrumMaster、产品负责人、职能经理，可以采取“一对一”的方式，针对每个人的实际情况开展辅导。
  

培训和辅导的过程不只是传递知识和经验，同时还是消除阻碍、消除员工对敏捷的抵触心理的过程。

3.敢于解除与敏捷转型相左的流程桎梏

在敏捷转型的道路上，如何对待与敏捷相左的现有流程呢？这需要管理层具备大格局思维，为了实现更大的愿景，敢于改变组织现有体制中与敏捷转型相违背的流程，哪怕要承担风险，面对抵触和指责。

企业F启动敏捷转型的试点后，很快团队 出一个问题：按照公司原有的流程，每个工程师需要在每天下班前给部门经理和组长发日报，即总结今天做了什么，工作有什么进展和问题；此外，每个团队的组长在每天下班前需要将每个工程师的日报汇总成一个团队日报，发给整个项目群的经理。

团队发现，自从试点敏捷后一切信息和状态都可以在看板上呈现，不再需要大家做日报。如果哪位领导感兴趣，完全可以通过看板看到一切信息。

敏捷转型委员会就这个议题开展了讨论，一些部门经理仍旧习惯于在座位上收取邮件报告；项目群经理也认为，发日报的习惯一直都有，不能因为做敏捷就取消了。试点团队的ScrumMaster反馈，开展敏捷后，因为团队有每日站会的实践，他不再需要工程师发日报就可以清楚地知道每个人的工作状态。如果还让大家发日报，会让大家非常反感。日报和站会，只能保留其一。

经过激烈的讨论后，敏捷转型委员会决定，自此取消工程师发日报的工作，因为站会是高效的团队协作工具，在开展站会实践的团队里，做日报是一个不增值的工作。

在管理者眼里，做日报不是件大事，每天只耗费工程师10分钟的时间。但是在工程师的眼里，每天重复花10分钟做一件浪费时间的工作是一件令人沮丧的事情。如果敏捷转型委员会不采取措施改变原有的工作方式，那么团队会认为敏捷加重了其工作负担，即在做原有的日报、周报等基础上，又增加了一些新的管理会议，每天还得移动看板上的用户故事和任务卡片。

需要注意的是，不是现有的管理制度都需要向敏捷转型让路。转型委员会需要针对每个冲突情况分析风险和代价来决策。有些时候，企业改变现有流程的时机或许还不合适，需要推迟改变的时间。