Scrum並非戰無不勝，但每一次的失敗，原因往往相同。Scrum能讓問題迅速暴露，隻有看到問題，才能解決問題。任何工作偏離軌道，都要馬上亮起紅燈，一個衝刺接一個衝刺，一個改善接一個改善，朝著目標前進。
當然，正確的模式意味著存在有錯誤的方法，或曰存在著反模式，並非每次實施Scrum都能成功，它也可能會失敗。有趣的是，Scrum失敗時，失敗的原因往往是相同的。
再次強調一遍，Scrum的目的就是讓問題迅速暴露出來。暴露問題通常會很痛苦，有時這種痛苦使組織難以改變。
幾年前，金姆·安泰洛剛開始在Scrum公司工作不久，到我們合作的一家大型汽車公司去參觀，參觀後給我打來電話，反映客戶表現不好，掌權之人沒有權力，公司陷入無休止的誹謗和爭吵之中，似乎安於耗費一個月又一個月的時間爭論應該做什麽，但實際上根本無所作為。我永遠也忘不了這個電話。
“J.J.，不要恨我。”
“為什麽？”
“Scrum在那裏根本行不通。”
然後，金姆開始告訴我阻礙公司成為敏捷企業的因素，以及所有這些因素不太可能改變的原因。
金姆是對的。
所以Scrum公司終止了與那家公司的關係。我們隻能提供幫助，不能強迫人家實施Scrum。
多年來，我一直在列出這樣的問題，它在公司裏反複出現。我發現知道不該做什麽和知道該做什麽一樣重要。以下是這些反模式以及應對之策。
領導者不要半途而廢
Scrum實踐所需的組織變革是巨大的，要有不同的人力資源實踐，不同的報告結構，不同的角色。要在整個組織中實現Scrum，需要高管層有強大的領導力。如果不建立新的行事方式，使之成為公司的工作方式，改革可能在瞬間土崩瓦解，公司最終非但無法身手矯健，反而會弱不禁風。
舉一個個人的例子。我父親在創建Scrum公司之前，在一家名為患者守護員(Patient Keeper)的公司工作。該公司為醫生和醫院製造手持設備，醫務人員可以通過這些設備完成大量工作，比如開藥、安排實驗室測試、查看測試結果等。手持設備還能允許管理層收集財務數據、收取服務費用和提交保險索賠，也深受管理層喜愛。
在患者守護員公司，我父親是首席技術官。他會見了首席執行官，談到將如何使用Scrum來經營患者守護員公司。“很好，”首席執行官說，“但我厭倦了團隊告訴我事情已經‘完成’。唯一重要的‘完成’就是收到醫院的付款，沒有懸而未決的問題。”
接下來，他們花了兩年時間來建立這樣的能力。最終，使多家醫院每一次衝刺都能實況轉播。如今，這種能力被稱為開發運一體化(DevOps)，工具都是開源的，而且在雲端就可以下載。但當年他們不得不從頭開始構建這項技術。
技術構建完成後，首席執行官說，他們現在可以改變每周優先事項了。每周一下午，他都召集產品負責人和Scrum主管們，一起檢查交付進度，修改需要修改的地方，為需要資金的內容提供資金，並重新定位造成麻煩的客戶或競爭對手。人們說首席執行官就像產品負責人團隊的Scrum主管。首席執行官讓首席產品負責人來負責領導工作，隻在出現問題時進行幹預，消除障礙，包括改變出現問題的管理層。我父親說，患者守護員公司就像一艘古老的英國戰艦。產品負責人每周都會移動大炮，對準敵人開火。下一周，對準另一個目標。不到一年，患者守護員公司已經打遍天下無敵手。他們的工作主要是在一家又一家醫院卸載競爭對手的產品，最後，他們的收入在一年內增長了400%。
後來，家父決定全職培訓人們使用Scrum，遂創建Scrum公司。父親留下的負責人讓團隊像時鍾一樣，每一個衝刺都準時培育出新的醫院。兩年後，那位負責人離職，首席執行官聘用一位不懂Scrum的工程主管來頂替離職者。不到一個月，團隊就無法交付了。首席執行官告訴新來的人，如果再這樣，你就要被解雇了。同樣的情況再次發生，首席執行官決定親自接管這個部門，並重新執行瀑布式管理模式，交付過程變得又漫長又痛苦。收入下降一半，患者守護員公司一瘸一拐，堅持走了幾年，方才壽終正寢。這是一個偉大的公司因舊習慣而破產的好例子。
傑夫認為，原因不僅在於新工程主管個人不理解Scrum，還在於他們不理解組織需要不斷改進以保持速度。傑夫在患者守護員公司倒下前一年看到了該公司的危機，並警告他們修複問題。但是管理層隻是希望Scrum能繼續工作，如果Scrum不能繼續工作，他們認為那也不是管理層的錯，是工程師們的錯。然後，當然，工程師們紛紛跳槽。
這種情況我見過幾次。一位高管將新東西投入某個業務部門，甚至整個公司，但沒有來自高層的支持。一旦此高管晉升到另一個部門或跳槽加入另一家公司，新的工作方式就會分崩離析。領導層經常對此感到震驚。讓同樣的員工做同樣的事情，怎麽突然之間其工作方式就不起作用了呢？之所以會這樣，是因為無論在組織層麵，還是個人層麵，都沒有將向Scrum的轉變內化。然而，他們領導的員工很少對管理風向的變革感到驚訝——改變並不鮮見，員工早已見怪不怪。
意欲最有效地實施Scrum，必須從高層領導自身的轉變做起。高層領導全力以赴，在公共、財政和運營方麵把自己的組織轉變為一個能夠在加速變革的新時代運作的組織。Scrum必須自上而下，成為完成工作的默認方式。不要隻是反複說要怎麽做，要反複付諸實踐。如果每次不同的主管進來，你的工作方式都有所改變，那你並沒有真正改變，你隻是假裝在改變。
不是為我，是為完成工作
Scrum通常從一個部門開始，通常是一個有嚴重問題的地方。這個團隊開始快速進步，先聲奪人。領導層就認為問題已經解決，太棒了，但公司的其他業務並未改變。領導層不斷加碼，提出要求、訂單和項目，猶如向辦公室中投擲手榴彈，完全不考慮此舉可能造成損害，不考慮新任務是否應該完成，不考慮新任務與人們正在做的其他工作孰輕孰重，不考慮新任務是否能夠完成。在拉開手榴彈引線之前，領導者務必深思熟慮。
組織的其他成員，包括領導層，都需要改變思考工作的方式。幾年前，我們合作過的一家大型石油公司，正在更換其安全報告設施。這是一件大事，他們嚐試多年，一個又一個項目統統宣告失敗。最後，他們說服來自公司不同部門的兩位雄心勃勃的高管，讓二人再試一試。完成這項工作至關重要，兩位高管也將其視為一次機遇。隻要解決這個棘手的問題，天下非我等莫屬。
其中一位高管得到一本《敏捷革命》，確信這是他們真正完成工作的唯一方法。一些Scrum公司的同事和我飛來，培訓他們的員工，並成立了一批Scrum團隊。一開始非常順利，進展迅速。但之後不斷遇到一個症結：另一位高管。這位高管雖然為得到的結果欣喜，在思想上卻轉不過彎來，不明白改變自己行為的必要性，繼續用過去的方式管理團隊。
Scrum非常善於揭示問題。很快就清楚了，這位高管的決策是個問題，拖慢了隊伍的速度。令我驚訝的是，她最終明白了這一點，也確實改變了。但改變需要把問題和行為的代價暴露出來。
最終，工程準時完成，二人都得到晉升。一開始邀請我們合作的那位高管利用這一成功回到老板那裏，據理力爭，說Scrum不應該隻用於軟件項目，應該用於所有項目，無論是挖井、安裝石油鑽塔，還是通過管道泵油。Scrum會給他們帶來優勢，不能不用。於是，他們開始推廣Scrum。
不過，她所做的第一件事就是確保領導們明白自己必須做出怎樣的改變。
結構債務，不要太過精益
精益原則非常棒，基本上相當於豐田生產係統原則的西方譯本，意在消除係統中的每一個浪費。精益企業研究院將精益原則列舉如下：
價值：產品的價值需由最終用戶確定。
價值流：為每個產品確定所有步驟，盡可能消除不創造價值的步驟。
流動：使創造價值的步驟按緊密的順序進行，使產品能夠順利流向用戶。
拉動：隨著流量的引入，讓用戶在需要的時候從中獲取價值。
完美：明確價值後，識別價值流，去除浪費步驟，實施流通和拉動；再次開始這個過程，並繼續下去，持續改善，直到達到完美狀態，在沒有浪費的情況下創造完美的價值。
企業正確應用精益原則後，將極大提高價值交付的速度，消除價值交付的浪費。
問題是，如果舍棄太多，過度精益，就會從根本上削弱創新力。我見過幾家公司，在生產一種產品時速度驚人，所需人員很少，令人欽佩。但是，除了生產正在生產的產品之外，公司沒有做其他事情的空間。
他們專注於“持續改善”，即專注係統或團隊的增量式改變，一點點持續改善。這很好，但他們隻關注當前的過程，當前的做事方式，沒有考慮這是否仍然正確，甚至根本沒有考慮這樣做對錯與否。豐田生產方式的一個關鍵方麵是“突破性改善”(kaikaku)，即徹底變革，允許改變整個業務：新產品、新策略、新工具。這可以是對市場力量的回應，比如蘋果手機一經問世，突然間，每個人都不得不使用智能手機。但這也可以由內部驅動。通常，隨著改善的漸進式改變，小步驟的進步會趨平，不再有進步的餘地。所以要實施一個項目來改變一切，創建空白寫字板，翻開新的一頁，無論你想怎麽稱呼它，總之，要尋求根本的變革。
但如果機構過於精幹，如果將員工裁減到剛剛好的規模，到了絕無懈怠的地步，也就沒有時間和資源去創新了。我認識的一家公司成了蘋果手機某個關鍵部件的唯一供應商，生產的部件數以百萬計。後來，蘋果想要不同的東西，需要用全新方法進行生產。由於已經使係統變得非常精簡，結果供應商花了好幾個月才適應徹底改變的生產方法。知道嗎？蘋果公司已經選擇與另一家供應商合作，因為後者行動更敏捷。
適度精幹的公司是好的，但如果精幹得太過分，會使公司最終喪失應變能力。
別按照工具告訴你的方式工作
有很多Scrum工具，即管理待辦事項並跟蹤工作進度的軟件。我每周至少會收到一次這種新軟件。這些年來，我自己用過4種不同的工具。每種工具都有自己的怪癖：有的工具希望你估計每項任務需要花費多少時間，有的工具能夠生成你想要的報告，有的需要與係統進行笨拙的交互才能使其工作，有的必須在5個不同的屏幕上勾選對話框才能得到你想要的東西。
我看到一些團隊根本不考慮實際狀況，不管工具的要求是否荒謬，就束手束腳，極力按照工具要求的方式來推行Scrum。工具是按照某種工作方式設計的，很有可能與你的需要有出入。
應對策略如下。我知道你可能需要使用一些工具，但在使用該工具之前，在牆上貼一些便簽，進行幾個衝刺，找出特定團隊如何工作最高效。可以是一些簡單的事情，比如你如何表明某些東西已經準備好，要顯示給產品所有者。或者，是否有基於其他團隊工作的依賴關係，你需要以某種方式使其可見，以便他們知道什麽時候阻礙了你的工作。
隻有完成這些之後，才可以求助於工具，使其按照你的工作方式工作，忽略工具的特性。有些特性你可能本來不打算使用，但更適合你的團隊，不妨試試這些性能。記住，讓機器人為人工作。
怎麽做很重要，拜物教式Scrum
瓦努阿圖是由大約80個島嶼組成的島國，因以下幾個原因而聞名遐邇。它是最早受到海平麵上升影響的國家之一。詹姆斯·麥切納在其1947年出版的《南太平洋故事集》一書中描述過這裏。這本書激發了羅傑斯和漢默斯坦獲得靈感，創作出音樂劇《南太平洋》。瓦努阿圖的幾十座島嶼散布在800平方英裏的大洋上，其中一個島嶼叫塔納島。在塔納島，2月15日是約翰·弗拉姆日。約翰·弗魯姆是島民心中的彌賽亞，將用貨船載滿財富，來拯救這裏。欲知此事的來龍去脈，且聽我慢慢道來。
第二次世界大戰之前，這個島國被稱為新赫布裏底群島，是整個世界宏偉格局中無足輕重的地方之一。突然之間，全球衝突使這些小島變得非常重要。美國海軍抵達後，海軍工程營在叢林中開辟道路，修建機場、基地和兵營。最終大約有40萬軍隊駐紮在那裏。部隊帶來貨物，數十萬噸軍供物資簡直是一場盛宴，如同海嘯般席卷島國。於是約翰·弗魯姆的形象誕生了：“我叫約翰，來自美國，想要一塊糖嗎？”
後來，戰爭結束，美國人離開，放棄了基地和機場，將似乎源源不斷地降落在簡易機場或在碼頭卸載的貨物也帶走了。約翰·弗魯姆形象卻融入當地的宗教，成為將貨物運回的彌賽亞。為召喚約翰·弗魯姆歸來，島民在叢林中仿造了簡易機場，上麵有燈光，有一座由木頭或樹枝或島民能收集到的當地材料建成的指揮塔。島民相信，隻有熱烈、正確地表演這個儀式，約翰·弗魯姆就會回來。我一點都沒有瞎編。
今天，他們仍然在胸前畫上“USA”字樣，手持木槍，模仿軍事隊形跳舞，宣稱約翰·弗魯姆會回來的，他們甚至為此創建了一個政黨。見鬼，就在不久前，一位信徒還曾短暫擔任過駐俄羅斯大使。“拜物教”在過去和現在都是真實存在的。
這種拜物教式的儀式化運動也可以發生在Scrum中。我曾經見識過。人們隻是走過場，裝樣子，奉Scrum指南為聖典，似乎相信Scrum的唯一目的就是Scrum本身。我在五彩繽紛、燈火通明、看起來很有趣的“Scrum室”中遊走一番，問團隊是否在完成每一個衝刺並有所交付。聞聽此言，人人皆麵露不安之色。
我們有一家大客戶，是一個擁有大約5萬名員工的公司，他們決定，既然要做Scrum，就把所有曾經是項目經理的人都召集到項目管理辦公室，讓他們統統成為Scrum主管。
新皈依的項目經理們帶著真誠的信念和熱情，對Scrum的擁抱有點過於強烈，使其變得怪異。他們去上課，去讀書，去參加會議，學習如何玩敏捷遊戲，大談特談做服務型領導的真諦，然後開始工作，搞活動，在托盤裏盛滿便利貼，就像祈禱約翰·弗魯姆歸來的島民一樣，把儀式和啞劇錯當成行動。
沒有人聽取這些新的Scrum主管的意見。在會議上，他們完全被忽視。他們的建議被置若罔聞。他們本人被視為無用的附屬物，空耗時間、空間和金錢，卻毫無成效。
發生這種情況的原因是，照字麵理解，他們的工作描述不外乎“促進Scrum”。僅此而已，沒有人期望他們做其他事情。他們是會議管理員，全都對Scrum知其然，不知其所以然。
他們似乎沒有領會到Scrum是一種完成任務的方法。是的，人們的生活將會更好，有望互相尊重。我也希望人們的工作更有趣，但正如我之前所說的，Scrum主管存在的唯一理由是速度，他們卻沒有意識到這一點。
我問Scrum公司的麥考爾·巴格特如何改正教條式Scrum時，他告訴我：“Scrum主管必須成為團隊中的專家。”麥考爾是一名教練和培訓師，客戶的Scrum主管需要幫助時，我會找他出麵。
“要成為成功的Scrum主管，”他說，“必須不斷溝通。溝通很複雜，說起來容易，做起來難。”
麥考爾說：你必須利用數據和團隊溝通他們的工作情況和表現。如果一個團隊沒有進步，必須向他們展示他們的速度，他們的衝刺承諾，他們是如何工作的，並征詢他們的意見，問他們可以如何改進。必須觀察他們提出的每一個改善意見，向團隊反饋，問他們：“嘿，這樣做是否有效？”
Scrum主管還必須觀察對話的進展情況。麥考爾說，這與團隊成員或產品負責人的思維模式截然不同。好的Scrum主管不關注團隊討論的事情是否正確，而是關注團隊是否以正確的方式討論事情。正確的討論方式會加快工作進展。
以下幾個問題是麥考爾評價Scrum主管的依據：團隊是否在不斷改進？團隊開心嗎？團隊開心是基線。Scrum主管在促進公司進步嗎？如果Scrum主管在消除阻礙團隊前進的障礙，則最後一個問題很容易回答。Scrum主管工作的本質是消除減慢團隊速度的因素。消除減慢團隊速度的因素不僅有利於Scrum主管自己的團隊，而且可能會幫助很多團隊，甚至公司本身。
不要隻是走過場。儀式不是現實。
不要做按菜單點菜式的Scrum
Scrum非常簡單，共分3種角色、5種活動、3種工具、5個價值觀。各個要素都很重要。要實現所追求的生產力的根本改變，必須同時具備以上所有要素。各個要素是相互關聯、相互加強的。我們經常看到團隊缺少一個或多個要素，或者在某些要素方麵表現不佳。
Scrum公司被要求評估Scrum實施狀況或實施一項Scrum項目時，這些要素就是我們的著眼之處。我們經常看到很多團隊，沒有專門的團隊成員，或者沒有全職的產品負責人，或者缺少其他一些基本元素。我們推薦建立一個可見的表格，記錄所有團隊以及Scrum的每個元素是如何被實現的(以及實現得怎麽樣)。
我們通常把表格展示在白板上，使每個團隊的狀態一目了然。在表格中，我們顯示他們是如何做的。他們做得好嗎？他們在改善嗎？形勢在走下坡路嗎？
在每個團隊中檢查這些信息，可以快速掌握Scrum在公司中的狀態，也使得Scrum的障礙顯而易見。Scrum主管可以用它作為障礙列表的基礎，予以優先考慮。最好每次衝刺都這樣做。項目走上正軌後，甚至可以在每次活動結束後做，不會花多長時間。唯其可見，才可以迅速采取行動，解決問題，而不是等到3個月後才發現團隊因為沒有良好的待辦事項清單或因為跳過待辦事項清單的優化，不能按時交付。
目前，可能並不是所有這些元素都一直保持良好的狀態。沒關係，從現在開始，一步步慢慢提高。見鬼，哪怕你隻能努力實現每日立會，僅僅這一點就能讓事情變得可見，並且有所助益。然後，就可以開始逐個處理其他要素了。
但所有這些要素都很重要，都有影響。需要紀律和專注，需要不斷檢查、微調和試驗，才能麵麵俱到。
有一家全球領先的農業設備製造商在這方麵做得相當出色。實施Scrum初期，他們隻做其中的幾件事。從每日立會始，然後添加衝刺計劃，再後來添加衝刺檢查。負責領導在多個國家的8個研發中心轉型的人並沒有急不可待地敲桌子，他隻是每周不停地發郵件，告訴大家這樣做或那樣做的好處，實施這個模式或那個模式。變化是緩慢的，漸進的。但在18個月內，他們的速度加快了8倍。更重要的是，他們正以快得多的速度將原型產品推向市場。他們通過正確執行Scrum，交付了真正的價值，但成功是通過一天天穩紮穩打獲得的。
不要外包
大多數與我們合作的大型組織都進行大量的業務外包。在一些公司，承包商構成勞動力主體。順便說一句，我覺得這樣做愚蠢至極。但是讓我們把重點放在業務外包實踐中的Scrum部分。有人經常會打電話來說：嘿，能給我找50名Scrum主管嗎？需要明天就上崗工作。
我想我可以找50名Scrum主管，而且明天就可以上崗，並因此賺很多錢。但我認為把Scrum這樣的核心競爭力外包出去是非常糟糕的想法。如果真想使企業重生，Scrum將起關鍵作用，使你知道做什麽，怎麽做。倘若把怎麽做外包出去，就不會使知識內化。
我不是說你不應該報名參加培訓和指導。你可能需要，但也要確保自己的員工接受培訓。你們需要有獨自進行Scrum的能力。在Scrum公司，我們弘揚一種信仰，就是要建立能夠組建、指導、維護和加速自己團隊的真正偉大的公司。我們的工作就是輔助所服務的機構建立這種內在的能力，使之不再需要我們的扶植。我告訴我們所有的教練和顧問，我們的工作就是把永久的變化拋在身後。但是，最重要的是，我們一定會離開。
Scrum是一個非常簡單的框架，但在石油天然氣公司實施Scrum與在銀行或研究實驗室實施Scrum情況大不相同。當然，它們之間存在共性，但每個組織，就像每個團隊一樣，都有自己的文化、思維和行為方式。正如一種尺碼不能適合所有人一樣，一種方法也不能適用於所有情況。
不要租用能讓公司變得偉大的人才。要培養讓公司變得偉大的人才，讓培養人才成為你所做一切的一部分。
頑固的障礙
幾年前，我在矽穀訪問了一批新的科技、社交媒體和互聯網巨頭。我在其中一家科技巨頭公司做了演講，然後問在座的各位，你們最大的障礙是什麽？什麽情況最能拖慢你們的速度？什麽妨礙讓你們抓狂？
一個勇敢的人站起來說，部署的工作不斷積壓，排起長隊，已經8天了，還在增加。我們卻被告知要構建更多的產品功能，而不是去修複交付中的瓶頸。
我問房間裏的人這是不是真的。大多數人點頭讚同，有幾個人鼓掌。
我問在座的Scrum主管，是否讓管理層看到了這個問題。他們說，報告過，但被告知不要作聲。
6個月後，這家著名的大公司(我不能說出這家公司的名字，因為進入公司大樓之前，他們讓我簽署了一份保密協議)因為產品交付的速度不夠快，解雇了首席執行官。
看出問題容易，但解決問題難。有時要花很長時間才能修複一個非常棘手的問題。然而，必須著手做些事情來解決問題。如果不這樣做，員工就會知道你沒有認真對待。
我鼓勵領導團隊做的是設置一個看得見的障礙告示板，放在人們常來常往的顯眼之處，首席執行官的門口就是不錯的地方。在告示板上，應該標明障礙相應的級別，附上負責解決每一個障礙的經理的照片，並顯示從提出障礙到解決障礙已經過去多少天。倘若不能在首席執行官門口的告示板上麵找到障礙，你就要親自去追蹤障礙。
一次，一位老朋友打電話給我。當時他正與數十名記者和編輯致力於一個遍及全國的重大新聞項目，他被難倒了。事實上，整個項目都陷入僵局。他們有些事情需要批準，但批準一直沒有實現。副總裁很忙，要麽不回複郵件，要麽說告訴Scrum主管我很快就會處理，但是我現在有一個非常重要的會議，必須馬上參加。
我告訴我的朋友用便利貼，把所有需要完成的工作都貼在牆上，讓告示板顯示那張不動的便利貼是如何阻礙其他工作的。然後拿出手機，拍張照片，不僅發給當事副總裁，還發給其他各位副總裁。要友善，要彬彬有禮。但是每一天都要這樣做——嘿，隻是要確保您知道我們仍然受阻，非常感謝您在這方麵的幫助，完全理解您日程繁忙。朋友花了3天時間，問題才算解決。
解決出現的問題，或者至少開始修複問題，向人們展示你正在如何修複問題。這樣，你就可以清楚地展示你讓公司走敏捷路線的決心。
專注於有效的東西，你的生死取決於產品負責人
產品負責人是團隊與外界之間穩定的接口，要負責很多事情，也要為很多事情擔責。他們決定市場需要什麽，以及團隊交付產品的順序和速度。
但事實是，有時這份工作不被重視。或者公司將職位名稱從業務分析師改為產品負責人，但不更改職位描述，換言之，除了稱謂的變化，其他一切照舊。或者公司找來一位非常忙碌的經理說，嘿，你現在也是產品負責人了，但是繼續做你原來的工作。或者有高管堅持要做產品負責人，但沒有時間與團隊互動。或者把高級技術人員任命為產品負責人，但是高級技術人員同利益相關者或者用戶之間缺乏互動。如果用一貫的方式做事，就會得到以往一貫的結果。優秀的產品負責人是用Scrum製勝的關鍵。
Scrum公司的首席產品負責人帕特裏克·羅奇這樣描述產品負責人的作用：“你正在帶領一支探險隊進入未知世界，成功與否將取決於你的計劃，生存與否取決於你激發周圍人創造力的能力。你難免遇到大麻煩，這是一個需要承擔嚴重後果的角色，也是令人興奮的角色。”產品負責人責任重大，此言不謬。
讓一群出類拔萃的人做著出類拔萃的工作，速度非常快，但做出的東西卻不被認可，或者做事的方式南轅北轍。這是我所見過的最悲哀的事情，不妨舉兩個例子。第一個例子是諾基亞公司。短短數年，諾基亞公司就從行業霸主淪落為無關緊要的公司。他們有十分優秀的Scrum團隊，身手敏捷，甚至還組建了諾基亞測試團隊，來測試各個團隊是否真正敏捷。測試團隊專門探究如下問題：你的衝刺時間有多長？有產品負責人嗎？有燃盡表嗎？有按照優先順序排列的待辦事項清單嗎？
如果你所做的隻是按照選項打鉤，就可能產生誤導，任何測試都不例外。諾基亞有非常優秀的Scrum團隊，交付速度之快令人難以置信。當然，蘋果手機上市之後，諾基亞出類拔萃的Scrum團隊以難以置信的速度交付的產品卻成了不被市場認可的東西!這是因為產品負責人對市場的重大變化反應不夠快。諾基亞之敗，錯不在團隊，錯在產品負責人判斷失誤。
第二個例子。我與一家金融服務公司合作，幫助他們在雲端完全重建交易係統。他們希望能夠升級防欺詐保護係統，因為罪犯更新了實施欺詐的方式，而且更新的速度比他們快。他們麵臨相當高的風險，因為他們有數百萬的客戶和數千萬次的交易，這隻是每天的交易次數，如果重建不能在那個夏天的特定日期推出，他們將不得不支付給第三方供應商一大筆錢，讓供應商代理他們處理交易。這筆款項數目高達數千萬美元，堪稱高得出奇。
推動這個項目成功的真正關鍵是一群傑出的產品負責人，他們毫不動搖地專注於在正確的時間獲得正確的待辦事項清單，不允許積壓工作。產品負責人對每個衝刺負責，並不定期地把整個項目的燃盡圖發給我。燃盡圖幾乎完美地傾斜到他們必須命中的日期，最終他們如期完成任務。到黑色星期五，新係統完全投入運行：每秒可處理600項交易，50毫秒的響應時間，超過99.9%的係統開機運行時間。現在他們可以無縫地改變防欺詐模式，這一項目每年為他們節省3800萬美元。同時，他們停掉了第三方供應商，一年又節省4000萬美元。這就是稱職的產品負責人所能做的事情。
優秀的產品負責人可以從根本上改變組織的軌跡。記住，產品負責人必須果斷，能夠根據不完整的信息快速做出決定；必須知識淵博；必須對相關領域和市場足夠了解，以便做出明智的決定。無論是對團隊，還是對客戶，他們都必須隨叫隨到，對團隊和客戶各投入一半時間是一個標準的經驗法則；如果做不到這一點，他們可能是利益相關者，而不是合格的產品負責人。他們必須被賦予行動的權力，擁有做出正確決策的自由和權力，並在決策時得到領導層的支持。最後，他們必須負起責任，因為無論團隊做什麽，成功與否都與他們息息相關。
懂得什麽必須發生，什麽不必發生
戴夫·斯萊特是Scrum公司的低語者，負責培訓產品負責人，屬於那種說話溫和、作風彪悍的人。戴夫見過很多公司死於產品負責人，所以開發出一個工具包，幫助解決這一問題。在這裏我想分享的是我認為作為一名產品負責人最重要的部分：決定不應該做什麽。
戴夫設計出一套練習，他稱之為“校準圖”，我稱之為“痛苦之牆”。首先，讓產品負責人離開房間(畢竟，他們隻需要花50%的時間和團隊在一起)，去寫下希望團隊做的最重要的事情。產品負責人離開後，讓團隊成員寫下團隊實際在做的事情。最後，將產品負責人和團隊集合起來，比較所寫的內容。戴夫說，大多數時間，團隊都會考慮事情的優先級，但他們正在做的事情中有很大一部分是低優先級的，是沒有人真正希望做的事情。
戴夫指出，解決辦法很簡單。要教會產品負責人用不同的方式來考慮待定項，明確在特定的時間需要什麽，戴夫稱之為最低交付量。待辦事項清單寫得正確時，產品負責人和團隊成員所寫的內容會完全一致。這個練習通過強調一個標準來推動團隊一致性，驗收標準專門用來回答一個簡單的問題：“我知道什麽時候該完成什麽事。”
正如戴夫所解釋的，這個測試“不會告訴團隊他們必須做什麽”，而是向團隊明確“他們不必做的事情”。決定不做什麽遠比決定做什麽重要。隻做現在需要做的，隻做本次衝刺需要做的，不要眉毛胡子一把抓。
數據不在乎你的意見
我在商界經曆過的最奇怪的時刻發生在一個不起眼的辦公園區，這裏簡直是建築師們平庸能力的縮影。身臨其境，你難免心生疑問，想知道建築師們是否會對自己乏味的能力感到特別自豪。
不管怎麽說，在這座平淡無奇的建築裏，有一間平淡無奇的會議室，隻是因其空間闊大而引人注目，有30多名高管坐於一張巨大的馬蹄形桌子周圍，開年度計劃會議，決定明年要做什麽項目。我很想看看他們怎麽做。
一位高級副總裁把一個電子表格投影到牆上，上麵有一堆項目，沒有真正按優先順序排列，隻是他們覺得必須做的事情，他們稱之為“大石頭”。高級副總裁環視一下房間，每個人都有成摞的文件和打開的筆記本電腦，電腦上是各式電子表格，不時有助手在各位高管耳邊竊竊私語。高級副總裁說：“是這樣，我們在未來一年裏有50萬小時的工作時間，其中包括雇員和承包商在內。薩拉，你已經拿到列表上的第一項。你認為你需要多少小時？”
莎拉查閱了文件、筆記本電腦，谘詢過助手：“2.5萬小時。”
另一位副總裁插話說：“2.5萬小時夠用嗎？問題很棘手。”
“好吧，那就定為3.5萬小時吧。”
會議就這樣進行。對於給出的數字，沒有給出任何理由。除了在會議室裏胡亂猜測之外，沒有做任何有意義的估算。順便說一下，在過去的一年裏，有12塊“大石頭”，他們不多不少，隻完成了其中的1塊。
我知道，且不論為完成這3.5萬小時的工作，需要多少人，組建多少團隊，更不論團隊是否分布於世界各地，隻要會議一結束，莎拉的團隊就要為名單上的第一個項目做準備了。無論估計準確與否，都要為這3.5萬個小時安排預算、要求和日程。
我的同事喬·賈斯蒂斯給我講了一個更荒謬的故事，我們不妨稱之為一種“獨特的”關於項目和預算的決策方式。喬當時在與一家全球製造商合作，被邀請參加來年的規劃會議。規劃會議在一艘遊輪上舉行，沒錯，就是在遊輪上舉行。結果會議變成了一場豪飲派對。“就這樣，這些醉醺醺的人一邊在遊輪舞廳裏飲酒，一邊決定明年的工作重點、預算，以及誰負責哪個項目，”喬告訴我，“簡直太瘋狂了。這背後沒有任何理由，沒有邏輯，沒有數據，隻有一群醉醺醺的高管。”要知道，這群醉酒者正在敲定的是高達數億美元的預算!
知道嗎？上述兩家公司可謂竭盡全力，力爭把事情辦好。問題出在他們沒有運用恰當的數據。
Scrum創造大量的數據：速度、過程效率、幸福度等。但光有數據還不夠，必須使用數據，了解團隊的速度。讓負責做一項工作的人評估該項工作，一個衝刺接著一個衝刺，實時跟蹤進度。如果工作開始偏離軌道，你很快就會知道，能及時糾正。
金姆·安泰洛開始在一家跨國製造公司工作時，他們內部條塊分割非常嚴重。每一位副總裁都把自己負責的一部分業務當作自己的領地來管理。這導致公司的不同部門獨立地多次製造完全相同的產品，而且不告訴其他部門。公司工作缺乏優先順序。金姆開始與公司領導層進行合作時，發現有2000種不同的產品正在開發中。均攤下來，每個員工大約負責兩個產品。
為了避免重蹈覆轍，他們組建了產品負責人團隊，認真審視自己在做什麽。他們把產品數量降到大約200種，由20個產品團隊負責。這個級別的產品負責人團隊實際上是一群首席產品負責人的產品負責人，每個人的團隊中都有多名首席產品負責人，每個首席產品負責人又都有自己的產品負責人團隊。這樣，一個大組有3個級別的首席產品負責人。
這些產品負責人每周聚集一次，了解工作進展狀況，討論發生什麽會改變事情的優先順序。每個季度，決定哪些項目將得到進一步資助，哪些不會。對於每一個產品，他們都深入研究，根據Scrum團隊提供的數據，分享他們的推測，判斷可以交付什麽產品。他們隻能得到當前一個季度的資金。幾個月後，他們必須回來展示學到的東西，明確接下來要解決的問題，認定可以推出產品的時間。隻有這樣，才能得到更多追加的資金。
有時候，他們會認識到他們真的不應該做什麽，或者認識到一個原本認為不重要的產品變成了真正重要的產品。因為他們是迭代地、連續地在一年的過程中進行投資，而不是在年初對將要發生的事情知之甚少時確定所有的項目投資，所以，如果開始出現問題，他們可以迅速扭轉局麵。他們能夠根據實際結果預測，而不是盲目猜測，在非常高的級別上改變優先級。他們使用數據驅動決策，而不是根據意見來驅動，這使得整個組織的優先級劃分變得簡單易行。
讓我再舉個例子，看看透明度能為你做些什麽。我們與一家大數據公司合作過，該公司的首席執行官掌管幾個項目，分散在許多團隊中。具體講，有幾十個團隊。團隊要做一堆事，她想知道團隊在一個特定項目上的速度，而不是團隊的速度。她要解決的問題是團隊多快能完成這個特定項目。
我們告訴她，這不成問題，她所要做的就是把各隊的估計數字加起來。“但是你不能在各個團隊之間比較和估算速度。”首席執行官說，“你就是這麽告訴我們的。”當然，我們這麽告訴過她，但關於全盤估算我們知道什麽？它是錯誤的，所有的全盤估算概莫能外。但就此公司而言，我們有足夠多的團隊來進行評估，通過比較，差異就會浮出水麵。
他們給相關待辦事項貼上“重中之重項目”標簽，讓各個團隊進行一個個衝刺，獲得團隊之間的燃盡圖。因此，她每周都能看到團隊在以多快的速度完成這個特定的項目。
為了討論，讓我們假設他們在幾周內每周燃耗掉這個重中之重項目的20%～25%。燃耗率看起來很好，他們很有信心按時交貨。但是奇怪的事情發生了，首席執行官一周一周跟蹤觀察，數據在一段時間內都很好，然後在幾次衝刺中急劇下降。發生了什麽情況？畢竟，探明異常是首席執行官的首要任務，所以我們進行了調查。結果發現，另一位高管為團隊安排了其他優先事項，減緩了團隊在重中之重項目上的速度。
因為首席執行官在預期發布日期前幾個月就了解了情況，所以可以采取行動，讓曲線回到正確方向。她第一次覺得自己可以真正掌控自己的組織，知道所關心事情的現狀。她不需要狀態報告或PPT不停地說項目處於綠色狀態，直到截止日期前兩周左右，項目狀態卻突然亮起來紅燈。她不需要意見，也不需要精心製作的報告，她有數據。
使用Scrum，可以獲得大量數據。可以做實驗，並快速查看結果。經驗係統不斷地檢查和適應：探索、響應、評價、探索、響應、評價。無論是團隊級別還是企業級別，實時完成這項工作都很重要。在某種程度上，這是一張安全網。你不會在一個長達一年的項目上冒數億美元的風險，你隻是在衝刺。隨著條件的改變，可以隨時改變主意。
大多數組織的經營狀況很糟糕，糟糕有糟糕的好處。最大好處是很容易迅速改變，能產生巨大的積極影響。我之前討論過，但我想把相關內容放在一處，以便易於您找到。這些措施幾乎可以在一夜之間從根本上提高團隊的開發速度。
小團隊：3～7人的團隊是理想的，團隊越大，減速越顯著。
穩定的團隊：把項目交給人，而不是人交給項目。
參考過往的工作量來估算目標：隻承諾上次完成的工作量。
專注的團隊：讓團隊切換任務，會降低速率。
每日立會：每一天、同一時間、同一地點。
中斷緩衝區：要有應對意外的計劃。
清晰的待辦事項清單：明確需要完成什麽。
良好的內務管理：一旦發現缺陷立即處理，絕不拖到第二天。
蜂群模式：一次隻做一件事。
徹底完成：在每次衝刺結束時，工作都被全部徹底完成。
合作：每個人都應該聽到彼此的聲音。
如果這些方麵你全都還不具備，可以從其中一個開始。一點一點，一個衝刺接一個衝刺，一個改善接一個改善，朝著實現這些目標前進。可能有些情況你無法控製，無法實現所有的目標，不過沒關係。
如何做你所做的事情很重要。如果決定不做某件事，就需要知道決定的代價，代價常常是不可見的。但你必須看清世界的本來麵目。因為如果看不到問題，如果不能談論問題，如果不能質疑問題，就不能解決問題。
我真心希望你能解決問題，我希望人們生活在能夠充分發揮潛能的世界裏。一旦你完成了從接受到行動，從被動到強大的轉變，你工作的世界將不再和以前一樣。我想生活在這樣一個未來，在那裏，對人類潛能的浪費被視為不必要的悲劇。我想對我們正在創造的東西感到驚訝。
你可以做到。你的決定是一種選擇，未來並不是一成不變的。
回顧
當心反模式。你有沒有聽人說過“我要找出一份最糟糕的做法清單並加以遵循”？當然沒有。並不是每次實施Scrum都能成功，它可能會失敗。有趣的是，Scrum失敗時，失敗的原因往往是相同的。
按照菜單點菜式Scrum的問題。是的，即使是糟糕的，或者部分的Scrum也可以提高生產力，但效果有限。Scrum非常簡單，共分3種角色、5種活動、3種工具、5個價值觀。各個要素都很重要。為了實現所追求的生產力的根本改變，必須同時具備以上所有要素。各個要素是相互關聯、相互加強的。
領導力。意欲最有效地實施Scrum，必須從高層領導自身的轉變做起，全力以赴。Scrum必須自上而下，成為完成工作的默認方式。因為如果不建立新的做事方式，並使之成為公司的工作方式，改革可能會在瞬間土崩瓦解，公司最終非但無法身手矯健，反而會弱不禁風。
要數據，不要意見。Scrum會創造大量數據。但光有數據還不夠，必須學會使用數據。你可以做實驗，並快速查看結果。經驗係統在不斷地檢查和適應：探索、響應、評價、探索、響應、評價。
不要外包。不要租用能讓公司變得偉大的人才，要培育人才。讓培育人才成為你工作的一部分。倘若把怎麽做外包出去，就不會使知識內化。
待辦事項清單
√確定你或你的組織目前采用了多少反模式，把它們寫在便利貼上，貼到牆上。隻有消除反模式後，才能移除便利貼。