在顾问们经历的很多敏捷咨询过程中，经常遇到那些将Scrum实施成小瀑布的团队，这些项目的结局，往往比大瀑布还差。软件开发是一个复杂系统，没有什么“最佳实践”组成的银弹，因此也没有一种方法可以把敏捷套用到每一个团队中。但一些共同的精神和价值观构成了我们常说的敏捷思维，这些是具有共通性的，它是践行敏捷实践的前提。
理解市场和需求会不断变化
我们和最终用户交谈，辛苦做完用户调研和需求分析，但上线后他们却认为这不是他们自己想要的？这是软件工程中老生常谈的话题，工程师常常抱怨“这不是上次访谈中确认的需求吗？为什么又要改了？”然而一个真正有敏捷精神的专业工作者，应该反过来理解“需求”是会不断地变动的，因为技术、竞争对手、市场一直都在变化（我们所处的VUCA时代就是变幻莫测的时代：VUCA是Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）、Ambiguity（模糊性）的缩写。），因此我们该做的是在可变动的范围内保留一定的弹性，缩短交付进度。
对应到敏捷软件开发中，有三种方式来缩短交付进度：首先，在短暂的迭代时间范围内不断关注产品功能及其优先次序；第二，理顺开发流程，将重点集中在增值（有价值）的活动上；第三，将精力放在选择和培养项目所需的团队技能上。
减少浪费
按照精益原则，任何不能为客户增加价值的行为即是浪费。在软件开发中，“没有必要的功能或需求”是很明显的浪费。我们也许碰到过这样的案例：团队觉得这个功能很酷，用户一定想要这个功能，但这些需求真的都是必要的吗？如果我们不能列出需求的优先级，很容易陷入这样的处境。因此我们要很清楚用户的行为（我们常用设计思维来理解用户旅程），什么功能（需求）对他们是最有价值的，并设定正确的优先级。精益思想认为软件业有七大浪费，分别是：库存（半成品、WIP），额外过程（比如文档工作中不会产生增值的部分），多余功能（任何一段不需要的程序代码都是一种浪费），任务调换（软件开发人员每次在转化工作时都会浪费调换时间），等待（比如在软件开发过程中一方等待另一方的响应），移动（比如当开发人员遇到无法立刻处理的问题而需要他人协助时，他需要移动多少“距离”才能找到问题的答案？），缺陷（缺陷需要越早找到越好，因此借助频繁集成及发布是一种很好的实践）。
无论一个人、一个团队或者一家公司有多么强的预见能力，未来总是为我们带来预料不到的东西。一些产品每周、乃至每天都在发生市场、技术等方面的变化，行之有效的办法是减少浪费、努力提高产品的适应能力——这是开发流程的一个关键设计标准。事实上，在敏捷项目中，卓越技术通过两方面评判：一是提供客户价值，二是创造适应能力强的产品。
使用者参与并尽早取得反馈
想象我们在TWI培训中做过的乐高游戏（用于理解精益创业），其中的痛点是研发团队常常容易忽略的：研发团队关在办公室中“想想”使用者的需求，并以此开始研发工作。显然这并不是好的做法，我们应该早期产出软件，让用户尽早验证这些功能是否满足需求，让用户（或是数据）反馈哪些是重要的功能、哪些功能不好，或是从中观察使用者的操作经验，使软件能够在下一个周期持续改善。
这是一个探索的过程。设计生产流程是为了重复使用，不断地产生同样的结果，好的生产流程是在规定的时间、用标准的成本产生预期的结果，它们是可预测的。探索流程则不同，因为围绕着用户需求和新技术，存在着不确定性，所以探索项目不可能产生已知的、完全预先规定的结果，但它们可以产生有价值的结果，即满足已知的客户和商业需求。
后记
数字化时代，“敏捷”起到何种作用？Martin Fowler（敏捷软件开发宣言的作者之一，极限编程的早期倡导者）是这样回答这个问题的：时至今日，敏捷思想在行业内广受尊重，客户也常常期望我们助其变得敏捷，“数字变革”是这一变化的重要推动力。人们意识到软件和数字通信日渐成为商业活动的重要部分，不应只作为成本削减的工具。业务与科技之间的整体关系将被重新定向，而敏捷思想是业务数字重定向的核心，在未来发展中将起到重要作用。
