小白团队，就不能实践敏捷吗？

最近遇到一个事儿，就是当和一个团队聊到要开始敏捷实践时，一个比较有影响力的干系人直接跳出来叫停，说：

“敏捷对人的能力要求很高的，我们不具备这样的团队成员，也没有很成熟的流程，实施敏捷风险太大。”

所以如果不是先有上述轻量化实践的成功验证，2001年的那场雪，是否能诞生Agile是不是就有点像薛定谔的猫一般玄妙了？

那我们再继续看看，那些敏捷实践方法是怎么来的。是因为他们本身聚集了很多牛人大拿？有了很领先的工具？或者有很先进的流程？

这些方法的背景是20世纪90年代，随着互联网和软件行业的高速发展。从工业生产管理理念演变的软件开发管理过程已经没有办法快速响应需求变化。因为面对强大的市场竞争，需要尽快的把产品投放市场，以验证和证实市场需求，并根据用户的反馈及时地调整需求和策略。

在上面那个大背景下，所有的工程人员好像是一群落入沼泽的人，都在拼命找办法脱离所处的困境。敏捷实践方法就是在这些真实项目中一次次不断尝试、失败、再尝试中诞生的。当时的情景下那些团队是否有那么梦幻的开发条件？从结果上看还真没有，否则他们也不用苦苦挣扎了。

所以，敏捷实践就是一群拥有聚焦价值、拥抱变化、持续改进思维的工程师，基于经验主义不断尝试、优化最终形成的大家看到的样子。而这些朴素的做法反过来又形成了敏捷范畴。同时，这些行为做法都仅仅是一个个起点，我们能看到的是一个个敏捷主义者持续砥砺前行。

那么要想团队敏捷起来需要准备什么呢？

首先，是管理者要准备好一个想法。一个让高价值的产品尽快流入市场验证、能具备快速响应市场变化能力以及团队效能可以得到持续提升的想法。这个想法是你决定是否实践敏捷的源头，要知道上世纪90年代的工程师们也就是因此一念而生众法。

有人又说了，这个想法所有人都说自己有啊，谁没有？谁不想？

是的，想法每天都会有。但是有了想法以后，下一个动作很重要，就是要把它从闪念变为信念。闪念是虚有，通俗了说就是一会儿有一会儿没有，或者说我不愿为之付出行动。而信念是实有，也就是为此心念披荆斩棘也要取得的决心。

另外，还需要有一些学习成本，毕竟敏捷管理者要像球队教练一样，去引导和训练你的球队。想改变团队，首先要改变自己管理团队的方式。

有了以上的想法和信念，接下来就需要组建一个团队。这个团队是你按照实际情况（产品、目标、预算等）组建起来的一群人。如果资金充足，就可以招聘经验优秀的人，如果预算有限，就招聘一些能力合适的人。但不论哪种团队、任何时间地点，都不影响你按照敏捷的思维理念引导和组织团队。如果没有协作工具，甚至在白板上画一个看板贴上post-it就可以立刻启动。

不同的团队条件对实施敏捷这件事最大的影响是过程中的协作态。学习能力强、善于协作的一群人可能比较容易跨越组建态进入产出态；能力弱一些的团队可能在组建态磨合了更多的时间，然后才进入产出态。

那些推脱说自己团队能力不行、环境不具备、流程不完善的人们，是不是都想跳过组建态，一步到位获得一个产出态的敏捷团队呢？那就真只剩四个字，痴心妄想。

如果作为Leader自己不具备敏捷的思维，空降一个敏捷团队也会武功尽废。如果有了敏捷思维，一个能力很差的团队也可以在持续改进的过程中不懈努力得到提升。所以在说团队敏捷与否之前，先向内看自己是否是一个敏捷主义者。

那么敏捷到底是什么？是Scrum、XP、FDD、DSDM吗？都不是。这些都是聚合成敏捷或者由敏捷推演出来的方法论。敏捷本身就是一个聚焦价值交付、适应变化、持续改进的思维理念，是协作者们对待目标实现和协作过程的价值观。

那敏捷团队又到底是什么？是达到理想敏捷态的团队才叫敏捷团队？如果真如此，那世上也许就没有敏捷团队了。任何怀抱敏捷理念，并以之践行每日生活工作的团队，都应被称为敏捷团队。是一群群向着敏捷态不断向内、向外求索提升机会并付诸实践的人。

最后引用一句老话，实施敏捷实践最好的时间是十年前，其次，是现在。

在硬件和软件行业拥有超过10年的经验，历任开发人员、项目经理、咨询顾问、Scrum Master 和敏捷教练。作为敏捷教练参与多个企业级的全面敏捷转型，成功帮助企业完成了组织形态的敏捷蜕变。