敏捷开发现今已经成为互联网、软件行业的主流项目管理模式。但是对于新业务，无论是创业企业还是内部创业的新业务部门，敏捷开发模式的适用性可以说再怎么高估都不为过。
之所以笔者干预断言系业务更适合采用敏捷开发的模式，主要因为新业务当中的不确定性往往很大，而敏捷开发模式，对于项目的变化管理显然具有更好的适用性。在传统的PMP框架中，虽然将变化管理作为项目管理的一个重要的方面，但是并没有明确提出变化管理的可以实操的方法论，而敏捷开发模式正好可以补充上这一点。
敏捷开发模式相对注重短期目标，而在新业务起步阶段，实际上恰恰是短期目标更优先于长期目标。这么说可能很多人，尤其是高级管理人员和创始人们未必同意，因为在他们眼中，正式基于所谓长远目标才设立的新业务部门，或者基于一个伟大的“愿景”才投身到企业的创立过程中去的。但是，伟大的愿景都是抽象的，在现实中的落地实施的具体路径确实要实打实一步步地走。中国人有句老话，叫作“摸着石头过河”。实际上新业务的每一步多少都要这个味道。新业务团队必须实打实地交付一个近期目标，然后根据用户的反馈来寻找下一步迈向最终目标的路。甚至，有时候不得不根据近期交付物的市场反应重新评估当初设立新业务的长期不妙的合理性。所谓“精益创业”，实际上描述的就是这个“探索——调整”反复迭代的过程。
而这个过程中，刻板地执行长期的产品研发计划的往往不自觉地就成为了业务迭代的天敌。阶段性交付物的缺乏，会导致整个团队一直怀揣着梦想咬牙坚持，而在现实中找不到支持自己这份坚持的理由。久而久之，无论外部的投资人、合作伙伴，还是团队内部，都会陷入迷茫和心生弃意。
从内部管理的层面，敏捷开发模式也有利于将团队的注意力和资源集中在当前的任务中去，而不是围绕繁琐的项目管理体系耗费精力。这在成员相对缺乏工作经验的团队中，尤其重要。作为经理，你也许认为每天花10分钟填写一下项目日报并不是什么难事，但是对程序员思路的打扰，往往需要1个小时来恢复。而敏捷开发的专注短期目标、“日清日结”的模式却可以在不打断工作节奏的同时来及时体现项目进度、发现存在的问题。这是因为每次日会都是互动的，围绕明确主题的。而在一个项目管理系统中填报事项往往是单向的，得不到立刻的反馈；而程序员，尤其是中国程序员的糟糕的表达能力，又让项目管理系统在华而不实的文案主义、官僚主义的道路上跑得更远。
我们会发现，很多敏捷开发管理大师经常会提醒说不要采用项目管理系统，而是直接在办公室的墙上做一个物理的、可感知的画板来展示项目的进度，其实就是为了避免上面这两种情况。毕竟，项目的真正进展是来自于团队成员在统一目标下积极探索而获得的工作成功，而不是在一个系统中录入和跟踪的文字。
这么说并不是为了贬低项目管理系统软件的作用，实际上，我们还会发现这个世界直到今天还在不断涌现新的项目管理软件，特别是在对敏捷开发持拥抱态度的开源项目领域。这难道不是和那些敏捷管理大师们的告诫背道而驰么？这么理解其实也还是没有抓住重点，因为新软件的出现，往往正是要解决现存的同类产品中团队成员的互动性不足的问题。到目前为止，大家还不敢说有一块项目管理软件可以让团队享有类似面对面交流的同等体验和效果。此类系统，更多是作为减轻项目追踪文档编制（这一点在大型项目中也十分重要）工作量的作用，而这个对文档工作负担的减轻，其实也可以在客观上起到让项目经理把有限的精力更加聚焦项目进度与风险的作用。但可惜的是，很多人还是摆脱不了“工具即成果”的情结，以为架设个项目管理系统就可以保证项目的进展，而忽视项目经理的作用。这听起来就像你听见一位烹饪爱好者告诉你他这顿饭做得好吃是因为刚买了一把最先进的厨刀——某种情况下或许真的有关系，但是多数情况下这二者很难建立直接的因果关系。
新业务部门或创业企业，往往面临更大的不确定性，刚组建的团队也缺乏默契甚至整体成熟度都不高（这很好理解，即便都是年龄和从业经历上的老员工，面对的新业务本身的能力架构也许还是新手），所有的动态性导致试图建立任何固化的流程的努力都是徒劳的，过度规划长远的路线图也是白白浪费精力，而敏捷开发的模式才是保证团队活在当下，扎实交付，真正为美好的明天奠定基础。