Re: [請益] Scrum壓榨工程師

分享一下我自己經歷過的幾間公司：

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即可），

是我最理想的環境。

--

我的結論是，
與其扒著 scrum 這個詞不放，
我更在乎的是一個團隊的敏捷與否，
而一個團隊是不是敏捷，其實聊個十分鐘就能感覺出來。

至於工作能不能開心、能不能有 WLB，
主要還是看團隊氛圍，而不是瀑布還是敏捷。

從做產品的角度，敏捷絕對能提高產品存活的機率，
從工程師能維持專注的角度，瀑布能讓工程師更穩定的走在自己的規劃上。

可惜的是，絕大多數的我們沒辦法影響自己身處的團隊，
我也曾經天真的覺得，我體驗過敏捷團隊的好處、希望能帶給團隊正面的影響，
最後發現，一個不需要敏捷的團隊，是不可能把敏捷給跑好的，甚至說，

「為什麼要敏捷？」

如果一個團隊真實得不需要敏捷，那又何必強推呢？

想通了這個問題，
我就開始能接受大家把 retro、standup、planning 亂搞了。

--