时间来到 2015 年前后，敏捷在国内开始进入收获的季节。2016 年度中国软件开发者白皮书中统计有 64% 的团队使用了敏捷管理工具，当然这里不是指已经有 64% 的团队开始实践敏捷，只是可以理解为有六成的团队认为宣称自己使用了敏捷管理工具是一件有面子的事情。阿里云栖社区在 2017 年发布的数据中，45.6% 的团队在规模流程模式上采用了 Scrum 敏捷开发，同理也可以理解为有更多人认为 Scrum 敏捷开发是好的。这种数据描述的是一种观念，表达了当时的行业从业者怎样看待这些理念，反应的是一种认可。
15 年之后在敏捷的基础上又有了很多发展，当然国际和国内要分开来看。在美国、澳洲发展的脉络是开始思考软件架构怎样可以更适合小团队（微服务设计），怎样让软件的生命周期更加完善（DevOps），怎样将敏捷的快速反馈机制向上延伸到业务（精益、持续交付）等等。而在中国则出现了一些变体，因为国内行业不具备这些能力，在最开始没有打好基础，08、09 年一些企业实施的敏捷其实是在“补课”，虽然有一些成效但远远没有到位，变成了中国特色敏捷。由于没有到位，只好换个名目再立项，摇身一变成微服务，再过一年变成 DevOps，之后又叫精益，结果实际上每年做的都是同样的事情，还在做最基本的用户故事、持续集成、自动化测试等等内容。一个行业在刚开始发展时，因为规模还不大，全面提升行业能力比较容易，这样也利于以后的发展，但是中国软件业在刚开始起步的时候没有做到这一点，规模却越来越大，同行全凭本能在工作，没有套路和方法，一些大型企业和项目全部陷在泥潭里，人人都在加班又解决不了问题，那么既然解决不了问题，就解决提问题的人，于是 Scrum Master 应运而生。正常逻辑应该是代码写的不好就提升自身能力写好代码，Scrum Master 就是引导团队成员，给成员赋能，虽然能力依然没有提升，不过至少起到了心理安慰的作用，在泥潭中也要和自己友好相处嘛。
