Jonathan Kohl是一位咨询顾问、作家和知名博主，他提出了这样的观点：时下团队在工作中身处的或正在构建的技术环境，与过去那些曾诞生了许多通用开发流程的环境已经有了很大不同。他鼓励团队在检查流程时保持清醒和活跃，并让自己做好准备，以能够适应当今他们工作中身处的现实。
他最近在Better Software杂志上发表了一篇题为“事物不断变化（流程也需调整）”的文章，并给出了一些在移动设备上使用自动化测试的例子：
广泛使用自动化单元测试，是一项得到普遍认可的敏捷开发实践。在过去十五年中，我们见证了这一领域中单元测试工具、框架、实践和知识体系方面的大爆炸——亲身经历这一过程也是件令人兴奋的事情。然而，在移动开发框架方面，自动化单元测试得到的支持程度很低。当我们习惯于在Web或其他较老的技术中，享受这些工具所带来的好处时，移动开发框架中的匮乏会成为让人们感到困扰的因素。对移动设备来说，状态至关重要——无线网络条件、设备的运动和传感器优化、人机交互、情感和知觉，甚至其他一些事情，例如天气和光线的变化等等。但实际上，自动化单元测试无法真正解决其中任何问题……由此，我熟识的移动开发者们倾向于很少依赖自动化单元测试，转而大量使用其他质量实践作为补充。
他提倡根据当前的需求，谨慎地运用多种不同技术；并建议团队做好准备，在选定的过程方法的“规则”之外进行探索。他说道：
我的一些敏捷教练朋友几乎丧失了理智，关切地观察某个移动开发团队是否使用（如果确实有的话）单元测试——只是为了发现团队使用了不同的工具，而且这些工具能够更好适应其最终用户要求的质量准则。移动团队一开始大多使用标准开发流程和工具集，随后会发现不足或是缺乏特定领域的支持，并且会调整流程。
Laurant Bossavit在其著作“The Leprechauns of Software Engineering”中对软件工程方面的某些“根本事实”提出了质疑，他对于遵循近期Google+的一条thread里的流程或方法的空谈也表达了类似的观点。对于当今在团队中发现的许多行为，以及在许多组织机构中采用OO之后所发生的事情，他进行了对比并表示：
“在任何敏捷流程中，我都可以让自己戴上耳机整天躲在屏幕后面”是“我可以使用任何面向对象语言编写过程代码”的新的体现。
他继续探讨了以往敏捷有多么处于实践的前沿：
那时候，敏捷是全新并且激进的；如果遇到某位对敏捷有兴趣的人，我们可以非常确定他们具有好奇、有积极性、聪明的特性，一言以蔽之，他们是与众不同的。他们并不一定完美或是能够自动成为任何环境中的绝佳人选，但至少他们远超同侪。
然而现如今的现实情况是：
敏捷不再是“激进的”，如果有人因为敏捷能让自己遇到不同寻常的人而对其产生兴趣，那么我可以完全理解他在寻找某些别的扮演这一角色的东西。
他并不赞成把事情丢给敏捷不管，而是建议投入时间和精力来确保从敏捷方法获得最大收益。这需要努力以及谨慎的思考：
类似地，只是因为有太多的误报（假阳性数据）——人们宣称预“敏捷”结合，却鲜有真正的经验或倾向——并不意味着这个标签是没有价值的。它意味着我们应该关注表面现象下面的内容，并找出那些难以评估的事情，去关注有价值的信号而不是那些廉价的。
同理，在那些最大声宣称自己拒绝敏捷的人之中，许多人将不可避免地进行模仿——练习一种在恰当时机改变自己花纹的古老的进化艺术。而只有那些没能拥有由艳丽色彩所象征的昂贵却又是实质性的属性的物种，才会练习这项艺术。
在文章中，Kohl总结道：
如果我们已经实现了一个流程，而且在最初的成功后，我们发现了质量问题、团队成员陷入困境、或是持续地延迟和超出预算，那么或许应该检查问题的根源是否在自己身上。不要谴责团队成员，而是去检查流程：它或许不再适用；它是否帮助团队中的所有人创造价值，或是已成为大家的阻碍？同时，牢记我们需要创造价值，不仅是为了客户、项目干系人和公司老板，还为了我们的团队成员和我们自己。任何不能积极创造价值的方面都会成为问题。
作者：Shane Hastie
