Scrum 失敗案例（1）：令人噁心的 Daily Report

我對 報告 中介紹的兩則失敗案例很感興趣。由於比較複雜，先評論第一個。

David（某知名大型網際網路公司 engineer，該公司自稱自頂向下實施了 Scrum，結果失敗）：

我們的問題在於，有些高層錯誤理解了Scrum和Agile，導致歪曲了某些東西，使得Agile變得形式化 ... 有個專案經理發現這個東西挺好，就單獨把Daily Scrum拿來進行推廣；結果，這個經理並不理解什麼是Scrum，他把Daily Scrum變成了Daily Report，而其他Scrum的精華部分都沒有推廣

具體的做法是：

每個員工都要在早上固定時間開Daily Scrum，然後把當天的任務告訴給他，讓他來決定工作是不是飽滿。這個把彈性工作制直接給破壞了，引起很多人反感；另一點就是很多人認為這樣的Daily Report太頻繁太低效，而且還有壓榨員工的嫌疑。所以逐漸大家談起Daily Scrum來都是噁心的不得了，於是經理也知趣地取消了Daily Scrum，再到後來在公司內部就沒有人談什麼Agile了。

這就是誤解、誤用敏捷的惡果，簡單粗暴的實施造成了“敏捷”與企業文化的衝突，既破壞了彈性工作制，又激起了員工的猜疑，搞得大家都犯惡心。

這種錯誤當然不幹敏捷的事，把錯用敏捷歸結為敏捷或 Scrum 的失敗、噁心，是不公平的。我想失敗的關鍵原因是，這位經理根本沒有搞清 Scrum 和敏捷的原理，為什麼要這麼做，比如：每日站會。

一，我想進一步瞭解的是，為什麼這位專案經理會只覺得 Daily Scrum 有用，進而創造性的把 Daily Scrum 演變成了 Daily Report，又把 Scrum 的其餘精華部分都拋棄掉？

我猜，很可能是這位經理感到不通過強制手段，自己就沒法控制自己的團隊，所以求救於每日跟蹤、每日彙報，來掌握專案團隊的實際情況。第二個原因是，他要求員工每日“把當天的任務告訴給他，讓他來決定工作是不是飽滿”，所以，他其實在懷疑、擔心自己的員工會偷懶！這種裹著敏捷、Scrum 外包裝的監控、監督措施一經推出，員工們自然就會反感，認為領導的動機不純，有半夜雞叫的嫌疑。

結果怎麼樣呢？非但沒有加強管理者和開發者之間的信任和團結，反而加劇了團隊的分裂，這顯然不是 Scrum 和敏捷的初衷。這位經理的所作所為是不是敏捷呢？當然不是。

翻一翻任何一本敏捷經典教材，我們可以發現，不管 Scrum 還是 XP 的每日站會、每日晨會，目的很簡單，其實就是為了及時的暴露風險和問題，讓經理、管理者通過排程、溝通幫助開發人員排除障礙、提供保障，這本來是一種服務、協作的關係，team building 的絕好機會，可以促進更好更快地實現整個團隊的目標。

為什麼這位經理不通過自以為的 Daily Report 就不能掌握專案的真實進度呢？是不是他在自己的員工中缺乏威信，無法有效地進行溝通、獲得資訊，或是高高在上，工作方式不對呢？我覺著，在這背後可能還有更深入的原因。至少從這個案例的簡單描述中，我們可以感覺到在這個團隊裡，經理和員工之間的關係其實是不融洽的，是一種監控與被監控、防範與被防範、猜疑與被猜疑的關係。從大的方面講，說不定還與這家公司的整個企業文化有關。

在這種管理者和開發者相互不信任的氛圍下，敏捷或 Scrum 的實施能成功嗎？

二，從整個公司過程改進的範圍看，我覺得也存在一些明顯的缺陷。

該公司敏捷實施或改進並沒有主動式的領導，僅停留在隨意的試驗層次上。David 提到曾經有過一次 Scrum 嘗試是成功的：

當時的Scrum Master負責一個大專案的開發，走的比較順利，然後有個專案經理發現這個東西挺好，就單獨把Daily Scrum拿來進行推廣 ...

可見，第一次嘗試是比較成功的。可惜，該公司並沒有認真地組織總結成功經驗，為什麼 Scrum 會有效，什麼是成功的關鍵？也沒有在公司範圍內有系統地進行推廣，處在放任自流的狀態。這樣才發生了某個專案經理突發奇想，覺得這個好，就可以按照他個人所理解的錯誤思路來進行推廣（從這點看，這家公司的執行力很強）。結局是，在整個公司內搞臭了敏捷和 Scrum，這當然不是 Scrum 方法本身的錯。

還有，包括 David 在內的開發人員，其實都看得很清楚：“有些高層錯誤理解了 Scrum 和 Agile，導致歪曲了某些東西，使得 Agile 變得形式化”。那麼，為什麼大家的這種正確意見在專案團隊、公司內部得不到有效的反映，從而避免錯誤的發生、實施改進的失敗？

所以，這個案例的失敗是誰的原因？是那位缺乏經驗的經理一個人的責任？我覺得不是，這只是一個表象。

根源上，我覺得是這家國內知名的大型網際網路公司的制度和文化的問題。不知道作為一家大公司，他們是否有一個專門負責過程改進的部門或人員。我想有了好的制度建設和團隊意識，這種草率魯莽的、缺乏群眾基礎的事情以後應該不會再發生。

擁有 14y+ 開發和管理經驗的
敏捷 OO 教練 張恂
www.zhangxun.com

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13633641/viewspace-231015/，如需轉載，請註明出處，否則將追究法律責任。