本文轉自：Scrum中文網

Scrum中文網原文連結：http://www.scrumcn.com/agile/scrum/18993.html

Henrik Kniberg & Eik Thyrsted Brandsgård

2016年12月

原文授權連結: http://blog.crisp.se/2016/12/30/henrikkniberg/agile-lego

翻譯&審校：

李潔(Jerry Li) 何強 龔正 姚宇巨集(Ella Yao) 陳婧(Elina Chen) 申健(Jacky Shen)

統籌&出品：申健(Jacky Shen)

2017年1月

中譯文連結：http://www.jackyshen.com/2017/01/31/planning-as-a-social-event-scaling-agile-at-lego/

 

— “什麼？一個150人的團隊會議只要（2天）1天？”

— “對啊！每兩個月一次。執行得非常好。”

— “但是為什麼這樣？怎麼做到的？”

背景

樂高數字解決方案部門（DS）由20個左右的團隊組成，負責處理孩子和家長手中各種裝置- 普通電腦，平板電腦，各種app應用，可穿戴裝置，虛擬現實裝置等等進行通訊。我們同時也在展望未來的產品開發，如何去擁抱新的技術，如何將傳統的玩法與酷炫技術，例如增強現實結合起來，或者找一種能夠將一個物理模型“掃描”進遊戲的方法。絕大部分的團隊在丹麥的比隆，但是我們在印度也有一部分團隊。

樂高，從他的核心來說，並不是一個數碼公司。他是一個有著80年曆史和17000員工，高效的進行設計、生產以及營銷實體玩具的公司。像其他公司一樣，樂高也在嘗試適應快速發展的數字世界，一個頻繁變化的世界，而敏捷開發正在逐漸成為主流。

在樂高，數字解決方案部門正處於這個變化的前沿。我們也非常樂意與大家分享我們這一段十分有趣的過程。

問題

回到我們只有5個左右的開發團隊的時候，計劃和工作同步是十分可控的。團隊和產品負責人能夠僅僅通過相互交談就搞清楚需要做什麼。但是當我們成長為15-20個團隊的時候，事情開始變得十分痛苦。

樂高公司作為一個整體有著非常好的投資組合和預算管理流程。投資框架是按照年度來溝通（專案Y需要X個小時），同時真實的內容決策是與財務決策解耦合的，所以各個部門可以靈活地投入人力。

所以在2014年，我們在頂層有著非常穩定的投資管理流程，而在團隊級別，我們有15-20個團隊在運轉Scrum和Sprint。問題在於中間- 專案集層面！

我們嘗試使用Scrum並且用敏捷的方式工作，但是在其之上，我們基本上是一個矩陣型組織結構來做專案。作為一個產品負責人來說，你幾乎把你所有的時間都花費在了各種會議中，以及協調團隊之間的工作以便完成工作，但是最終你還是無法得到你需要的，因為別的團隊有其他的優先順序安排。

作為平臺的產品負責人，你可能有10個人過來問你要一些東西，但是你又無法處理所有的請求。所以，你如何決定哪件事情更重要呢？有些時候，不同團隊可能會製作一樣的東西- 例如，嘿，在我們已經有的五旋轉木馬之外在新增一個過山車會不會很酷？好東西不能太多啊，或者？

總的來說，我們一直在苦苦掙扎於：

跨團隊同步 – 如何能讓各個團隊向著同一個方向前進而不是成為互相的羈絆
客戶合作 – 如何設定切合實際的期望並且在不過度承諾的情況下滿足客戶
釋出計劃 – 如何在跨多個迭代，多個團隊，多個產品的情況下進行計劃和安排優先順序
平臺開發 – 如何保證我們對未來投資，而不是僅僅是完成一堆一次性解決方案
當我們接近2014年結束的時候，我們決定嘗試一些不同的東西。

改變

在2015年1月，我們開始勇敢地徹底調整。我們將整個DS部門演變為團隊嵌團隊的形式，引入了一個共享的迭代節奏，對於依賴管理和資訊同步進行去中心化，同時每8周在房間裡進行一次敏捷計劃活動。這個改變產生了很多積極影響，不僅對於DS部門，並且也影響了與我們合作的其他部門。

現在我們來看看經過一年半的嘗試我們最終得到了什麼效果。

宣告：這仍然是一個正在進行中的旅程，不是一個已經完結的過程。我們仍在繼續改進這個模型 — 例如， 在2016年第3季度，我們將大房間的全員迭代計劃活動從2天縮減為1天。持續不斷更新文章是很吸引人的，但是這樣下去它將永遠無法完成，那麼我們就說這個文章是2016第2季度的寫照吧。:o)

大房間計劃之旅

這是星期三早上，你被邀請到這個神祕的活動中，就是人們一直討論的“PI計劃活動”。你知道它代表著“產品增量計劃活動”，是一種每8周發生一次的計劃事件。你步入一個大體育館，看到了這些：

只是開玩笑…你看到是這樣的：

環顧四周，你看到所有DS交付團隊都在那裡，所有的經理，許多客戶和利益干係人，以及一些像你一樣的好奇訪客。一份大致議程擺在桌子上。

演示時間！

幾分鐘後，伴隨著音樂響起，一個快進的5分鐘的視訊開始展示在過去的兩個月釋出的一些亮點部分，並且響起慶祝的掌聲。

這並不能取代團隊通過Sprint評審和使用者測試等日常反饋。但它提供了一個很好的概覽和激發靈感。它提醒所有人我們這麼做的目的。

閃電演講

下一步，一位經理站起來幾分鐘，分享一些進行中的和將來的重要事項的想法.。接下來其他人站起來做一些鼓舞人心的講話，例如數字兒童安全、一場即將到來的黑客馬拉松、平臺戰略，以及當前的其他熱點話題。有人演示使用新平臺釋出的東西是多麼容易，另一個人執行一個有趣而愚蠢的Kahoot(譯者注：一個遊戲化學習平臺)謎題。

上午過半，全體會議結束了，當人們喝著咖啡閒逛時，他們把每一個環節的評分都寫在一個反饋板上.。為每個主題談話的價值和有趣程度打出1-5分。

— Joe:“看，大多是4分和5分！比上次好多了。”

— Lisa:”除了那第四個話題。啊！“

— Joe:“是的，這大概只跟十個人有關。我都睡著了。”

你可以看到一些小的評論，以幫助改善下一次的演講。有幾個人在爭論我們是否應該進行閃電演講，還是下次直接開始計劃會議會更好。

引導者轉向你。“全體會議就像定時炸彈，得保持簡短和直達重點，要不然人們就會走神。而當正確進行的時候，它可以是一個真正的能量激發，它能夠讓人們感受到上下文語境，這有助於計劃活動。”

團隊突破

下一步：團隊突破。當每個團隊在同時工作，討論在接下來的幾個月交付的關鍵的事情時，會議室被各種嗡嗡聲點燃。一個高層次的計劃，不用太詳細，因為許多意想不到的東西會在未來8周內發生。

每個團隊都有自己的可移動白板和計劃板。大多數團隊成員都站在白板會前面進行討論，與此同時一些人四處漫遊，與其他團隊和利益干係人進行同步。有些人則站在咖啡和零食桌旁討論其他隨機主題。

你注意到一些團隊和角色有團隊T恤或特殊的帽子，以便在人群中更容易發現對方.。印度的團隊在會上有團隊代表，，他們不時地和房間裡的人們溝通，又不時地與印度的其他團隊成員溝通。

乍一看這樣的會議十分混亂，但能量水平相當高。儘管有些人似乎有點壓力或無聊，但是大多數看起來度過了有趣且高效的時光。在現場有大量的自發對話和笑聲，新的連線正在形成，已有的聯絡得到了加強。很明顯，他們以前做過這個，並且感覺到很舒適。

這部分佔據了一天的大部分時間，感覺非常像一個開放空間活動(Open Space)（如果你去過一次的話）。就像在一個開放空間活動時，最重要的規則是兩隻腳定律(Law of 2 feet)。

兩隻腳定律：如果你在現在站著的地方沒有學習、沒有貢獻、也沒有樂趣，用你的兩隻腳，走去其他你可以學習或貢獻或有樂趣的地方。（OK我們添加了“有樂趣”的部分，這不是開放空間的正式內容。）

你注意到引導者經常強化這個資訊：這取決於你，作為一個個體，在這幾天內充分利用你的時間–無論是與你的團隊做計劃，在咖啡機旁聊天，或討論架構。不要等待別人告訴你到底具體該做什麼或去哪裡。

但也有一些限制，所以每個團隊的桌子上你可以看到一個小冊子來描述整個計劃流程和NFR（“非功能性要求” – 細想起來是一個比較奇怪的名字……）。那包括例如法律要求，服務包更新或新的部署流程等所有的團隊都需要考慮的事情。這些非功能性需求是對每個產品增量都是最新的。

基於拉動式的計劃

你注意到一個很重要的細節 – 就是團隊成員（其中的絕大部分）在主動拉取工作，而不是讓工作被動強加於他們。他們決定拉取的數量是根據
以往已經交付的資料及對實際情況的直覺。為了讓這能在實踐中行得通，每個團隊都有一個產品負責人與利益干係人進行協商並且在PI計劃活動之前準備一份已經經過優先順序排序的產品待辦事項列表(Product Backlog)。於是產品負責人和客戶決定事項的優先順序，而團隊則選擇拉取多少。

有些團隊相當獨立，他們擁有自己的待辦事項列表。但是其他團隊，例如平臺組則需要和其他人一起工作，然後從共享的專案群待辦事項列(Program Backlog)中拉取一些要做的功能。

你會發現專案群待辦事項列表被投影在牆面上，同時你也會注意到有各個不同組的成員組成的一小堆人站在待辦事項列表前，協商著哪個待開發功能應該被哪個團隊拉取。

團隊都是半專業化的，每個團隊有自己專注的領域，如樂高身份驗證，雲技術或搜尋。團隊傾向於拉取他們最熟悉或最不令人討厭的功能，所以產品負責人有時需要提醒他們即使與團隊的專業不匹配，也要有人能更好地拉取即使令人討厭但是那些高優先順序的功能。到現在為止，團隊之間已經能夠很好地進行團隊間的負載均衡，以確保我們作為一個整體專注於正確的事情（而不是超級有效地構建錯誤的東西）。團隊成員大多是T型人才，這意味著他們在某種程度上是專攻一點，但同時也具備足夠的廣度來互相幫助。

我們曾經把產品待辦列表列印在卡片上，貼在一個實體的板子上，像這樣：

……但這有點繁瑣，因此我們想出了一個解決辦法，就是直接在產品待辦列表管理工具中線上處理，直接投影在牆上。雖然直接動手少了，但由於我們比如有六個團隊共同做平臺開發，這樣更容易跟蹤直到任務結束。

看看周圍，你會注意到一些團隊的桌子上有大螢幕，用電子化的方式顯示他們的待辦列表，而其他人大多使用實體工具。

團隊白板

每個團隊都有一塊可移動白板上，用於物理的團隊白板。

隨著計劃的成型，白板會逐漸被填滿。

不同部分的含義也不同：

這基本上是團隊對於接下來4個迭代的高層次的計劃（每個迭代是2周，因此產品增量是8周），也是敏捷計劃活動的主要產出。

— “呃…你們僅僅每8周釋出一次？”

— “不，8周只是我們專案集層面的計劃週期。 釋出週期是完全獨立的，有些團隊釋出更頻繁，有些釋出更少”。

當然，計劃一直在變，這取決於每個團隊環境的易變性如何。但是擁有一個計劃仍然有用，因為它驅動著圍繞優先順序、相互依賴性、團隊容量等各方面的對話。需求將永遠超過容量，因此團隊和客戶需要共同努力，在艱難的權衡下做出決策。為了幫助計劃活動，團隊使用“昨天的天氣”這個方法。簡單來說，就是他們檢視過去的PI資料，顯示他們完成了多少(故事點)。這些簡單的資料被用來檢查現實情況，以避免過度的承諾。我們曾經因過度承諾而產生了很多問題，進而導致質量不好,錯過了最後期限,以及客戶和團隊之間的不信任。面對不確定性，最好是開始時略少承諾，稍後再拉取更多的工作而不是過度承諾，然後不得不推遲工作的完成。

“PI目標”是團隊的粗略承諾，理想的情況是以基於影響的（“我們將實現業務結果X”），而不是基於輸出的（“我們將提供功能Y”）。但大家的情況總會有所不同。彈性目標是團隊可能完成的事情，或希望完成，但沒有足夠的信心來承諾完成。

— “但是等等，”承諾“究竟是什麼意思？”

很高興你問這個問題！承諾的PI目標意味著：

“基於我們現在所知道的，我們確信我們可以實現這一目標。
“我們有額外的容量處理不確定性”。那需要多少額外容量？取決於：
我們所涉及的工作量有多不確定?
我們對環境（改變優先順序等）有多麼不確定？
這個承諾有多重要？它越重要，我們可以承諾的其他目標越少。
“我們將盡最大努力去完成我們做過的承諾，但我們不能100％確定。”
“如果任何時候我們不相信可以完成這點,我們將盡快讓利益干係人知道”。
過去，承諾通常意味著“有人代表你做出一個不切實際的許諾。解決這個問題”。它不僅傷害了產品質量和積極性，而且使計劃和預測變得很困難。

風險板

隨著計劃的進行，團隊開始甄別可能導致承諾失敗的風險、潛在的問題比如“新許可證將無法按時交付”。這些被張貼在散佈在房間裡的風險板上，每個專案或主要的活動都有一塊風險板。一些風險可以通過與正確的人溝通來內部解決，而其他風險則需要升級，並在第一天結束時留在板子上讓管理層進行評審。

過去，風險傾向於要麼被忽略，要麼所有的都太快地委派給管理層（導致其變成瓶頸）。通過以自下而上的方式視覺化風險，團隊獲得了更多自主權，並升級他們真正需要幫助的風險。有時，減輕風險的成本是巨大的，並有不成比例的影響，所以最好只是接受風險。承認和接受風險消除沮喪，並使團隊安心，所以他們可以專注於交付而不是擔心。

依賴關係白板

很快你會注意到牆上掛了一塊真心巨大的白板。看起來就像是引力的中心，
因為總有一大群人圍著它在議論紛紛。一開始白板上什麼也沒有，但是第一天結束時，白板上就掛滿了一堆亂糟糟的便利貼，便利貼之間用…呃…
紅色紗線連在一起？！貼紙，剪刀，紗線，什麼鬼？

我們管它叫“依賴關係白板”（有時候也叫“專案集白板”）上面展示了誰、什麼時候、從誰那裡、需要什麼。仔細看看…

每一列是一個團隊，每一行是一個迭代（2周）。便利貼代表了依賴關係，從藍色到粉色。“為了交付這些（藍色貼紙），我們需要你們提供那些（粉色貼紙）”你會注意到會有很多討論，都是關於什麼東西在哪個迭代、會被交付到誰那裡。

這不是任何人單獨擁有的白板。這個板一開始由引導者放上去，但是接下來
團隊就會完全自組織地工作，把他們工作的依賴關係都可視化出來給大家看，並且把這塊白板當作一個握手協議，來決定誰需要去和誰對話。這個
白板是一個集中的工具，用來使去中心化的合作成為可能。

— “那麼，團隊會把所有計劃要交付的功能放上去嗎？”

— “不，只有那些具有依賴關係的功能。我們曾經把所有的東西都放到白板上去，但這樣一來白板就變得異常凌亂，大家都看不懂了。我們得出的結論是大家只關心依賴關係，所以我們只專注於這一點。獨立的功能在團隊各自的白板上呈現，不會在這裡。”

你發現了一個明顯的瓶頸（CIT那一列，企業IT組），同時看到了如何最有效地解決這個瓶頸的熱烈討論，而且也有些討論是關於長期如何降低這個瓶頸的影響。

— “那是什麼？”你問引導者。

— “ CIT是獨立於DS的一個單獨組織，所以一開始的時候，他們並沒有參與計劃活動。但是經過前幾次PI計劃活動後，很明顯的是，CIT才是依賴關係最重要的部分。大家對它抱怨很多。因此我們在依賴關係白板上加了CIT這一列，並且請他們派出代表，來參加PI計劃活動。”

— “這有幫助嗎？”

— “有，幫助很大！互相指責少了，互相合作多了，’我們和他們’的說法少了，’我們和我們’的說法多了。”

CIT和DS的人在白板前面對面的討論，關於如何最好地利用我們珍貴的瓶頸（當然，也討論了怎麼樣從長期來說，減少這個瓶頸）。看起來很糟，但是大家會告訴你“以前更糟！你應該看到我們做的改進！比如說，把東西移到雲上來減少依賴。雖然這個是很耗費時間的。”

依賴關係白板的底部幾行明顯是空著的。我們管它叫IP（“創新和計劃”）。那個迭代是預留給計劃外的創新、前三個迭代的溢位、還有類似於下一次PI計劃會議及培訓以及其他冒出來的事情。

一個工程師指出“目前，我們在達成我們所承諾這件事上已經做得好多了。我們有了容量資料（故事點等），所以我們不太可能會過度承諾了。但是，IP迭代也會像是我們的緩衝一樣，即使有些事情搞砸了，我們也有空間去讓事情恢復到正軌。更重要的是，承諾都是在討論和協商後做出的，而不是被強加在我們頭上的。”

— “ 好的，那麼創新做的怎樣？那是IP迭代的I的部分，對嗎？”他笑了。

— “這部分通常都被忽視。但已經比早期好多了。上一次PI的IP迭代中，

我們做了一次黑客馬拉松，很多又酷又有用的東西在那之間誕生了！有些團隊永遠都能為創新擠出時間，讓其他這次IP迭代中做不到的團隊羨慕不已。”

另外一件讓你好奇的事情：

— “開完會後，依賴關係白板怎麼處理？”

— “收起來， 帶回辦公室，貼在一面牆上。”

— “ 然後呢？”

— “ 每週或者每兩週我們做Scrum of Scrum。每個團隊的ScrumMaster們聚集在板前討論，並把已經解決的阻礙和依賴劃掉。”

他給你看了一張照片：

— “印度的團隊呢，他們怎麼看到板呢，假如白板只掛在比隆？”

— “我們還在解決這個問題。。。”

— “那下一次PI計劃呢？白板怎麼辦？”

— “扔了。每次PI計劃我們都會新建一塊依賴關係白板。這會給我們帶來新的視角，讓我們在白板上嘗試新的格式或者結構不會受之前的做法的影響。”

計劃草案集會

在幾個小時看似混亂的切分計劃會議後，引導站到臺上宣佈計劃草案集會開始了。在他總結形式的時候，大家安靜下來（大部分人也已經很熟悉怎麼做了）。

— “我們會依次進行四個7分半鐘的短會。每個短會上，一個團隊成員
都會站在團隊白板前給大家講他們的計劃，其他人可以去參加別的團隊的短會，聽他們的演講。”

他會啟動一個7分半鐘的大型計時器，然後演講就開始了。每個計劃白板前聚集一小堆人，一起聽並且討論那個團隊的計劃–他們打算交付什麼以及理由。依賴和風險都會被討論，有時候，也會發現新的問題。別急，明天我們會有時間來解決這些問題。

— “為什麼是7分半鐘？為什麼是4個短會？”

— “我們做了很多不同的嘗試，這個是目前我們覺得最好的。剛剛好
我們有足夠的時間去獲取到資訊，而不至於覺得無聊，或者陷入到細節中去。”

7分半鐘後，鈴聲響起，第二個短會就開始了。大家會跑去另一個團隊去聽他們的計劃。就這樣，四個短會一共是半小時。

— “好吧，所以說每個人都可以選擇參加四個團隊的短會並瞭解他們的計劃？”

— “完全正確。”

— “那專案的全景呢？知道所有團隊的計劃不是更有用嗎？”

— “對有些人來說，是這樣的。但是對絕大部分人來說，不是的。所以只需要選四個你最感興趣的團隊。假如你想知道更多，你可以在明天的休息時間去拜訪更多團隊。”

— “你一直都是這麼做的嗎？”

— “不是，過去我們會按順序來做計劃草案的分享。所有人都坐下，每個團隊輪流起來給所有人介紹他們的計劃，引導者用攝像頭把他們的白板投影到一個大螢幕上。一旦找到合適的工具後，這個過程很順利。但即使嚴格限制時間，要把所有20個團隊都過一遍，也要至少一個小時的時間。”

— “哎媽這麼長”

— “可不是咋滴。雖然我們盡力讓他變得有趣，但還是淪落為瞌睡會！一些人會仔細聽，但是大部分人都在百無聊賴的玩手機，或者趴在桌上，希望這個會議趕緊結束！大家確實關心別的團隊在做什麼，尤其是有所依賴的那些團隊。但那最多也就是3到4個團隊，他們不需要知道所有的團隊在做什麼。所以我們決定不再強迫大家去了解所有人的計劃，而是建立一種基於拉動的方式，讓他們自己選擇。用集會的方式效果就好多了！”

你到處走動，聽別人的演講。大家討論他們的計劃、依賴、技術、風險等等。感覺真的就像是一個集會！

引導者再次過來並指出：

— “注意到房間裡能量高漲了嗎？那是我們主要的反饋環，說明
我們做的是對的。假如能量很低，大家開始撤出了，那不論我們做什麼
都是錯的，我們需要改變形式。於是保留那些激發能量的部分，拋棄那些讓人無聊瞌睡的部分。”

你注意到其實有兩個引導者，兩人結對，輪流上臺講話。他解釋說：

— “我們一直都會結對引導這個活動。這樣，當一個人在引導的時候，另一個人可以退後一步，觀察一下能量水平，然後想想有什麼可以改進的。結對也可以給我們留有一些餘地，假如一個人生病了，那招入一個新的引導者也會更容易。”

管理層評審和問題解決

第一天結束的時候，大部分人離開了，只有主管們留下。管理層評審的時間到了！

在巨型依賴關係白板旁邊，風險白板排成一排，然後主管們圍成一個半圈。

所有人都受平臺的進度影響，所以他們從那裡開始。平臺產品負責人總結他們的計劃，提出一個折中的艱難決定。

— “壞訊息。我們沒法再這個PI裡面同時交付A和B”。

但是兩個任務都非常重要，缺少任何一個都可以造成廣泛的不良影響，大家爭論的很熱烈。引導者從中幫忙調解矛盾和關注點。主管們討論了他們手上的選項，每個選項的優缺點，最終決定先做A並推遲B。好幾個團隊明天都會因為這個決定而調整他們的計劃。

然後，他們按個過每個風險白板。保留在白板上的風險都是團隊自己無法解決的，因為它們涉及到公司的其他部門，或者超出了團隊的控制。這些主管現在需要負起責任並決定怎麼做，而且他們很有動力這麼做，因為只有搞完了才可以回家。。。

你注意到風險白板上的列。一個主管解釋說：

— “ROAM框架在這個對話中很有用。我們每次討論一個風險，做決定，然後把他們移到四列中的某一個列裡面去：已解決（R），已認領（O），已接受（A），或者已緩和（M）。所以回家的標準很清晰。所有的風險都必須被討論，並且移到相應的ROAM列裡面去。”

過完每個風險之後，他們會決定誰負責在第二天早上給大家總結這個結果。

如果你記得那本關於公僕式領導力的書，就會意識到，這樣的方式讓主管們更向公僕式領導力的模式靠近。團隊看到主管們承擔起責任來並且幫助解決問題，這會在他們之間建立起了信任。

引導者也證實了這一點。

— “管理層評審以前是很混亂的，也很消耗精力。首先，以前我們沒有
風險白板，所以討論通常都沒有結構且耗時很長，做出的決定有時候甚至還會被忘記。後來我們用了風險白板，當時有太多風險被升級了。慢慢的，團隊自己開始承擔責任（當然是在主管們的鼓勵下），然後因為升級的風險少了，主管們也更願意，更有能力去承擔那些風險負起責任來。”

第2天 – 使計劃穩定

第二天吃早餐時，你問某人：

— “為什麼還需要第二天？你們不是都已經完成計劃了嗎？每個團隊都已經制定了計劃，依賴關係都已經確定了，風險都已經被處理了…現在還要做什麼？”

— “計劃還需要完善。昨天我們回家時，仍然還有很多沒有解決的問題。現在經過一晚上的休息，我們會繼續迭代完善計劃和解決問題，否則這些問題就會在下游爆發並搞砸迭代。”

— “那麼你們總是花2天時間來做計劃？”

— “到目前還是這樣。但是我們已經做的非常棒了，而且第2天能量相當低，因此我們未來可能會嘗試只做1天。”

後話：我們這樣做了，發現用1天時間做計劃確實更有效！先自己想想看。稍後再對此進行更多的介紹。

早餐後，經理們站出來展示和分享他們對昨天形成的計劃草案的反饋意見，總結管理層評審所作出的關鍵決策，並解釋他們將如何處理升級給他們的關鍵風險。

出現的一個大問題是不穩定的測試環境，幾個團隊都已經把這件事情識別為一個大風險。負責該領域的主管得出這樣的結論：“我們清楚這個問題，本次PI中，大多數任務都在優先提高穩定性——可向X團隊瞭解更多資訊。但需要花費幾個月時間才能得到一個真正穩定的環境，因此到現在為止我們只能接受這個風險。”不盡如人意的訊息，但是團隊們稱道的是問題已經被承認並且至少情況在向好的方向發展。有些團隊會調整他們的計劃，以考慮一段時間內測試環境仍不穩定的情況。

隨後，團隊繼續採用昨天的形式做計劃。較早完成計劃的團隊可以開始進行其他工作，那些存在大量依賴的團隊繼續和其他團隊合作，搞清楚需要誰在什麼時間做什麼事情。

引導者們鼓勵人們就算已經完成了自己那部分計劃也仍然留在現場。這些人可以繼續做其他的事情，諸如編碼、處理郵件之類的。

— “有時候其他依賴你們的團隊會出現新問題，如果你們仍然在現場，問題就能很快得到解決。”

在某些情況下，部分團隊成員會回家，現場留下少數代表以便為其他團隊所用。

到下午早些時候，計劃已經穩定了（或者已經到達他們的要求了），是時間進行最後的計劃評審了。我們仍然採用相同的4場會話形式，團隊繼續可以到處遊走和聆聽彼此的計劃。彩色樂高塊被用於指示從昨天開始計劃是否發生了大量變化，這就像是狀態標識，可以幫助人們決定去聽哪些團隊的計劃。

信心投票

在草案計劃集會順利完成後，團隊回到各自的桌子，主持人宣佈進入信心投票時間。“對於達成PI目標，你有多大的信心？”每個人舉起1-5根手指，1表示“毫無信心”而5表示“信心滿滿”。

環顧四周，你看到大多數團隊都非常有信心達成承諾。然而有少數幾個團隊表現出缺乏足夠的信心，這時候主持人會邀請他們說點什麼。總之，能量非常低，你幫不上什麼忙但是想了解——這樣做到有什麼實際價值？

迷你回顧

日程最後一項是迷你回顧。每個團隊都坐下來討論計劃活動本身，從上次以來改進了什麼，下次應該改進什麼。此外，每個團隊成員對整個PI計劃活動的價值進行獨立地和匿名地評分（“我的時間花得有多值”），5分為最高分。

之後，除了ScrumMaster和引導者，其他人都回家。ScrumMaster和引導者們在改進看板前圍成半圈，一個接一個，張貼來自他們團隊的個人評分，總結反饋意見和改進建議。

每個人都完成陳述後，他們後退一步並觀察看板，找出模式和主題。大部分人都喜歡這個活動（大部分都是4或5的評分），認為時間花的值得。

— “等等！這難道不都是內些開發人員嗎？我曾認為開發人員是討厭開會的？”

— “是的，在剛開始開展計劃活動的時候，我們都有過擔憂。但即使在第一次，評分結果都超出了我們的預期。看起來，人們認為這是一件實際工作而非是一次會議。”

儘管有一些2分，甚至有幾個1分，但是大部分人都對下次如何改進，給出了可執行的反饋。他們喜歡在大房間內做計劃的想法，他們更關注這個活動如何執行。還有對時長的關心。

這次在迷你回顧中出現的一件事情是信心投票。這實際上有多少用處呢？有些人希望對此進行調整，另外一些人認為這是在浪費時間應該去掉。經過討論後，他們同意進行一次試驗 – “下次PI規劃時我們跳過信心投票這個環節，看看我們是否會懷念它。”

後話：下次PI計劃時我們跳過了信心投票這個環節，正如開始猜想的那樣，我們並沒有懷念它。團隊對計劃的承諾不是外界強加的而是自主自發的，這就意味著他們有足夠的信心，使得投票變得多餘。再見吧，信心投票！這只是我們如何通過不斷試驗和調整活動形式以最大化價值產出和最小化浪費的眾多例子之一。

更遠的後話：在2016年第3季度，我們嘗試了1天版的規劃活動（同樣的活動，但是把2天壓縮成了1天），並且看到無論是能量還是評分上都有明顯的改善。所以我們繼續採用1天版。但是普遍的共識是，開始時我們可能需要2天作為墊腳石，直到我們學會如何更加有效地開展工作。

就是這樣。結束了。團隊們帶著各自的團隊看板和風險看板回去。引導者們留下來相互做一個簡短的交流，草草記下一些關於下次有哪些不同做法的筆記，然後開始收拾依賴看板和其他東西。

就這樣，現在你已經看到了一個PI計劃活動！希望你喜歡它。

現在，讓我們後退一步。

除了大房間計劃外，還有什麼變化？

太多了！儘管PI計劃是我們帶來的變化的重心，但明顯還有更多的東西。“真正”的工作實際上是發生在PI計劃活動之間的。

在PI期間，團隊通常以常見的Scrum儀式，例如迭代規劃、每日站會、待辦項梳理、迭代評審以及迭代回顧，來進行Scrum以及2周的迭代。我們也有共享的PI演示和回顧。但在此我們不想讓你迷失於具體的細節。本文聚焦於PI計劃活動，描述我們正在嘗試實現的自下而上的去中心化協作。PI計劃就像是一面反映整個過程和文化的鏡子。

值得強調的一項活動是PI預計劃，產品負責人們聚集在一起討論，為即將到來的PI特性進行優先順序排序。在每次PI計劃前，我們有三次這樣的預計劃會議。在會上，特性從一個標題演化為可理解的特性，並按照價值、時間緊急程度以及工作量進行排序。如果想了解更多，請研究延遲成本（Cost of Delay）或者加權最短工作優先（WSJF，Weighted Shortest Job First）。如果你想真正深入瞭解，請檢視Don Reinertsen的著作《Principles of Product Development Flow》。

PI計劃活動的實際目的是什麼？

用一個詞來描述：對齊

PI計劃是一個大房間計劃活動，其目的是讓團隊們彼此進行對齊。

大房間計劃的價值與你們有多少依賴直接相關。當然，最好是設計你的團隊結構和架構，儘量減少依賴和避免需要進行大房間計劃之類的事情。但如果你有一幫團隊開發同一款產品，或者共享技術、密切相關的產品（就像我們的情況），那麼大房間計劃就超級有用。

伴隨著迭代，每個團隊都有一個2周的計劃範圍。PI計劃增加了一個更高層次的規劃範圍，在這裡團隊聚集在一起展望未來（2個月，一個“產品增量”），但不關注細節。

訣竅是抵制住制定精確、詳盡計劃的誘惑。就算是粗略的正確也比精確的錯誤好。

注意，產品增量，並不像聽起來那樣是一個大爆炸的釋出版本。它是一個同步點，一個時間和地點，團隊們聚集在一起，彼此對齊。這與釋出週期是完全無關的。不同的團隊以不同的週期釋出，這取決於他們工作的性質。因此我們按節奏規劃，按需釋出。

PI計劃解決了團隊間不對齊以及由此引起的挫折和浪費問題。這是一個讓人們奔向同一個目標的承載平臺，同步一幫某種層度上自組織團隊的一個“大心跳”。

沒什麼能比得上面對面溝通。在PI計劃期間，資訊共享和決策的數量是非常驚人的。在同一時間和地點把所有人員召集在一起並給予信任和授權，使得這件事成為可能。任何你需要交流的人此時此刻都在房間裡。無需傳送日曆邀請或者等待合適的會議時間，只需要上前溝通。

如果沒有計劃活動，我們就需要一堆單獨的協調會議、電子郵件和電子表格來完成同樣的事情，這增加了等待時間以及錯誤理解。團隊會在大房間計劃活動中產生骨架，並在PI規劃會議後（迭代期間）討論工作細節。

PI計劃的另一個好處是，它提供了徹底的透明性，揭示了大規模軟體開發所固有的複雜性。這可能會嚇到外部利益干係人，但他們能更好地理解和尊重團隊，因為他們的工作實際上是試圖馴服複雜度這個怪物。

那麼有什麼壞處呢？嗯，容易被人討論的是成本問題，但實際上這並不是一個大問題。無論人們是否在PI計劃中，都要支付相同的工資。唯一真正的開銷費用是場地和食物，相比獲得的價值來說這只是一筆小小的費用。

一個心理學上的缺點是，如果你是一個控制狂人，你無法做到心平氣和，以及得出清晰的計劃。整個設計可能會讓人感覺非常混亂和無組織。

然而，一旦你習慣了這種方式，那就會意識到會議提供了一個極好的整體概要，讓你舒適地感覺到目標可以被達成，同時還允許你放大你覺得特別重要的領域。剩下的你只需要相信團隊，留給他們就可以了——畢竟，他們都是非常聰明和敬業的人，否則幹嘛僱傭他們。：）

這件事情帶來了什麼影響？

沒有什麼事情是完美的，但總的來說產生了相當積極的影響，看起來沒有人想回到過去的做法。

重複勞動更少了。團隊們之間的協作更加協調，因此在重複勞動上浪費的時間更少。
依賴性問題的更少了。團隊們在相互阻塞等待上浪費的時間更少了。團隊們也更加順暢地與其他部門和利益關係人合作。
主管們能夠更快地調整優先順序和解決障礙，因為他們比以往更加解實際情況。
客戶的信任得到了改善，因為他們比以往更加理解團隊在做什麼以及為什麼這樣做。
計劃變得更容易，承諾的達成率也更高，因為團隊們和投資組合計劃者們都清楚我們的實際產能和能承諾的工作量。
更重要的是，這提升了團隊成員們的積極性。當困惑和浪費減少時，工作也就變得更加有趣。而受到激勵的人會把工作做得更好。因此這是一個良性迴圈！

我們看到的另一個影響是，樂高的其他部們觀摩了會議活動，特別受啟發，並開始探索如何在自己的部門實施這些原則和做法。事實上，敏捷如同病毒一般在公司內部傳播開來，而PI計劃活動的高度透明性就像一個催化劑。

儘管如此，這依然是一件複雜而又艱苦的工作（我們樂於稱之為“艱難的快樂”），還有很大的改善空間。但通過朝同一個目標越發對齊，獲得更多授權的團隊，更好地為客戶設定了正確的期望，以及更好地識別了相互之間的依賴關係——這一切都讓我們意識到我們已經更好地以正確的方式交付正確的東西。

這一切是如何開始的？

你還沒走？想知道這一切是怎麼開始的嗎？好的，下面是背後的故事。
九十年代後期的生活是美好的。屈指可數的幾個人（我們今天稱之為跨職能團隊）用些GIF和HTML就能夠精心打造出樂高的線上業務。但是隨著數字化的提升，交付數字化解決方案所需的人員也越來越多，開發工具也變得更加高階。大約15個團隊規模時，我們真的是相互交錯但卻又朝不同的方向使勁。

最初，我們試著設定了一堆專案經理，但事實上無助於問題的解決。他們總是表現得像是事後諸葛亮。典型症狀是：不斷地更新計劃以及向指導委員會申請追加預算或者延遲釋出。

2009年左右我們在團隊級別引入了敏捷原則，現在我們仍然堅信這些原則，但是我們真的不知道如何大規模應用敏捷。某位專案經理聽說了“大規模敏捷框架”，就去參加了學習。當他回來時，他對此進行了分享，然後我們就沒有再管它…已經好幾年了。

但是突然事情有了轉機。經過與一些團隊的討論後，專案經理們相信這個框架可以幫助我們。所以召集了各部門的所有主管來介紹這個框架。他們並不完全相信，但似乎它可能會有幫助，而且似乎也不太可能使事情變得更糟，那麼為什麼不試一下呢？因此，某位高階主管推動了這件事情，並申請了經費對整個部門120人進行培訓。

我們進行了三天的培訓，包括一次模擬練習。第二天，我們對此的信任有了極大的提升，製作了一份專案集待辦項清單，並安排了首次PI計劃。這是一個嘈雜、侷促和混亂的開始。但是，令我們驚訝的是，活動得到落地執行，並且效果好於我們原先的顧慮。

以下事情幫我們獲得了最初的成功：

團隊們希望做出效果。如果團隊們不買賬，我們就會慘敗。儘管對框架的某些部分持懷疑態度，但他們確實投入其中並且盡力使之成功。
已有的敏捷經驗。團隊已經執行敏捷多年了，並且組織中相當一部分人都明白敏捷原則。這是敏捷規模化的良好基礎。
管理層買賬。管理層提供了足夠的支援和信任，使得事情得以成功。雖然沒什麼高階主管直接參與，但他們接受了相關的風險，提供了活動開展的空間，並確保我們有足夠的經費來支援每個相關人員的教育和培訓。
不教條的方式。雖然我們以大規模敏捷框架為工作基礎，但我們並不迷信框架。由於我們的團隊們是工作於不同的產品和服務上，因此對多團隊工作於同一款產品的情況進行了優化。因此，每一次新的PI，我們都會定製和調整過程，新增需要的元素，移除不增值的元素。這就給了人們一種主人翁的感覺，他們可以看到過程和框架都為他們服務，而不是反過來。
現在在幹嘛？你們目前面臨的挑戰是什麼？

我們還在不斷試驗。每一種改變要麼使事情得到改善，要麼使它們變得更糟，要麼沒有區別。但我們保留有效的和拋棄無用的，所以隨著時間的推移事情日趨完善。

最大的改進是在開始，現在的變化較小，並且我們似乎也已經找到了一個可持續的工作流程。目前以小的調整和權衡為主。畢竟房間裡有這麼多人，我們不可能真的確保每個人都極其高興，但至少我們可以確保沒有人極其不高興。

我們最大的挑戰是，我們工作於一堆不同型別的事物。雖然我們是一個部門，大多數情況下使用相同的工具和技術，但我們並不是在構建一個渾然一體的產品。理想的情況下，我們希望基於特定的產品或者價值流組成一些較小的團隊–我們組織設計上的大一統理論。這樣就會有一些較小的PI計劃，而不是龐然大物般的會議。但我們還沒想出解決方案，我們已經習慣了讓每個人都在同一個房間裡做計劃的便利。

結果，我們很難在PI計劃上只聚焦於一兩個有著清晰故事線的主題。相反，我們最終會為不同的團隊和利益干係人提供一系列不同的目標。這就令主管們不滿意，因為他們想要一個有著清晰故事線的團隊工作事項。團隊也很不滿意，因為他們想要清晰地理解上下文和整體優先順序。這是個先有雞還是先有蛋的問題。

儘管試驗和調整過程看起來像是一件好事，我們有時仍然會捫心自問：我們真的是在優化正確的變數嗎？還是我們只是為了改變而改變？例如，如果PI計劃已經不再是最大的限制，我們真的應該繼續努力改善它嗎？到目前為止，我們真誠地相信我們正在改善正確的事情，但是偶爾反省一下也是好的。

另一個挑戰是動力。在開始的時候，對於變化每個人都很興奮（或焦慮），能量很高，並且感覺也很好。在PI計劃中小的變化和驚喜可能是個好東西，能讓人們保持思考。我們只需要時刻提醒自己，事情總是會改善的。

結束語

希望本文對你有用！當然它對我們很有用–給了我們一個藉口來真正地反思我們所做的和所學的:o)

請記住，我們的方法不是大規模敏捷的“答案”。這只是一個例子，一個正在進行中的旅程的快照。敏捷全都是關於持續改進的–它是一個方向，而非一個終點。

然而有件事情是可以肯定的。如果我們試圖從一開始就計劃好整個變化，我們將一事無成！相反，如果你想讓改變發生，那就從現在開始，設定某個目標，然後開始試驗。這一切都是關於人的–如果他們在進行變化，如果他們支援這種想法，那麼你就會取得進展。否則沒戲。

不要羞於使用現有的流程框架，或借用其他公司或案例研究的想法（比如這個）。沒有必要重複發明輪子！只要確保你能調整成適合自己的上下午就可以。雖然不會找到滿足你所有需求的完整解決方案，但你可能會找到某些能驅使事情往正確方向發展的東西。

祝你好運！

Henrik Kniberg
[email protected]
http://www.crisp.se/henrik.kniberg
https://twitter.com/henrikkniberg
http://blog.crisp.se/author/henrikkniberg

Eik Thyrsted Brandsgård
[email protected]

Jacky Shen
[email protected]

 

反饋？疑問？

 

請使用中譯文部落格評論或原文部落格評論或直接聯絡我們。大部分都會看，但不幸的是我們不能保證給予響應。人生太短，總不能事事迴應:o)