分享一下我自己经历过的几间公司：
1. 职涯最初期，事后回想把 scrum 跑得最好的公司
是一间新创公司，Product owner(PO)就是老板本人，
如所有的老板一般，所有他想要的东西都想要最快速度拿到，
而这位PO的优点是，他知道不能要马儿跑又不让马儿吃草，
所以在给他他最想要的东西的同时，他能够接受其他事情延期，
并不会讲出：
我是成熟的大人，我两个都要。
这种屁话。
此外，所谓“他要的东西”，通常是真真正正的 MVP，
PO 决定方向、优先级，但怎么验证 MVP，是整个公司一起决定（没多少人），
大家都找到最小的成本去验证这个功能是否被需要。
在这间公司工作三年，基本上，开发超过两周的功能都是最后有持续在使用的，
我在的期间开发出来的功能，只有最后被更好的版本迭代掉，
没有花了大笔资源（人力）开发，结果却是进垃圾桶这回事。
结论：
曾经与一个前辈讨论过，当一个团队很少开发出不必要的功能的时候，
就是把敏捷的精神做得很好的象征。
我可以说，这间公司是我待过最敏捷的公司，
有趣的是，这间公司在我离开前几个月才开始跑所谓的 scrum。
因此，有没有 scrum、sprint、retro、standup ，
对于是否敏捷，一点关系也没有，这些工具名词，
甚至我可以说，这些名词与行为本身，其实不会帮助你更敏捷，
他还是会让你保持原样。
敏捷的团队还是敏捷、导入了 scrum 之后，可以让团队更透明；
瀑布的团队还是瀑布、导入了 scrum 以后依旧是老样子。
2. 挂著 scrum 皮、骨子却是瀑布
大约十个工程师的开发团队、维护一个公司的重要产品，
100% 把瀑布做成 scrum 的团队，每天有着 scrum 的皮、但在做瀑布的骨。
为什么我这么说？
Scrum 为了敏捷而生、敏捷的用意在于，在“改变中的需求、不确定的需求”的环境下，
保有工程师的产出能力。
我待的这间公司有这样的需求吗？
没有。
敏捷强调尽早验证尽早确定资源是否投入、适时的调整人力资源在产品最需要的方向上。
如果没有这样的需求，
Scrum 就是瀑布，因为你早期验证做完也没人给你 feedback，
那干嘛不直接往最终目标瀑布下去就好了？
这公司，有看板有 scrum 有 standup 有 retro，
但 retro 都在聊大家的心情、谁狗怎么样、关心一下少数族群（我），
有在跑 scrum ，但最后变成了大家互相关心对方心情的“交谈”，
产品方向上有问题吗？我们下个 sprint 重心是什么？有没有什么要砍、要加的？
没人在乎。
3. 瀑布与敏捷混合的公司
最后一间公司就比较有意思，
平常的时候很瀑布，但部分的专案可以跑得很敏捷，
这也是我待过最舒服也最有成就感的公司。
绝大多数的时候把 scrum 跑得很瀑布，
陨石砸下来可以、那瀑布就拉长一点，瀑布不想变长也可以，那就砍功能。
而有全新专案、提高盈利项目的时候，
团队也能跑得很敏捷，尽快做出 MVP、尽快验证、投资人力在最重要的地方。
必须说，从个人生活的角度，瀑布绝对是比敏捷舒服的方式，
因为你很清楚自己要做什么事情，陨石掉下来就加时间或砍功能，
而敏捷是随时都在想要怎么用最小的资源来验证假说，
假说成立以后，该把资源放哪里可以效益最大化。
如果可以，我会想要瀑布敏捷两个交替，
想认真搞产品的时候做敏捷、想让心力休息的话做瀑布（专注在coding即可），
是我最理想的环境。