分享一下我自己經歷過的幾間公司：
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即可），
是我最理想的環境。

推

這文章真讚

推

大師返璞歸真惹

推

要有feedback才是重點

推

推

推這篇

好文推推 感謝分享

要敏捷不就為了可以在人才徵召上寫「我們公司跑敏捷我們很潮喔」嗎

推

推推精闢

推！

這篇不錯

推

推推

推

推推

推

推分享~原來是這樣

推

推 這篇的心路歷程體會滿棒的

推

敏捷或瀑布不是重點，員工有WLB比較重要。臺灣有太多公司只知道毫無意義的瞎卷而已…

推

推

推

推，我覺得你可以巡迴演講了

推

推

那如果專案owner被主管意見綁架怎辦？ 我比如為了滿足各事業體許願而做出來的功能

推

推這篇

如果許願不用付出代價，那遲早變成隕石

我也覺得應該去演講洗腦那些高官

推

推

推

11樓正確

你已經成為敏捷大師了

推 反墣歸真

很多團隊，大老闆其實才是實質上的PO他會花錢找大師來教團隊敏捷開發跟scrum，但是自己不聽也不參與scrum lol

推這篇！

推

遇過聘請外國Scrum大師進來導入敏捷專案執行一段時間後, 就高歌離席了。留下了一堆手足無措的開發人員，與專案經理。(已將畢生所學傳授給你們，剩下就看個人造化)

還是那句老話【沒有對錯，只有適不適合】，適合就是好的

掛名還是得收個過路費的,哈

對的 到最後最欠教育的還是PO

講的真好

推

推

推

推

推

推推