(這是 Three Years of Scrum at Socialtext 這篇文章的中譯，接續上集的內容。)
改善 Standup 集會
彼此支援的互助方式，意味著開發人員不需要等開會，就能即時解決自己工作中的阻礙。
這樣一來，當我們每次在 Standup 集會上要列出自己遇到的阻礙時，實際上… 根本沒有任何阻礙。
此外，儘早消除阻礙還有另一個好處：我們通常都能完成每天的工作承諾。因此，“我昨天做了什麼”以及“上次 Standup 上我說過要做的事情”的實際內容是相同的，因此第二個狀態的更新也顯得多餘。
最後的結果是：原本每天要討論的三件事，最終被減少到一件。
突然之間，我們的開會時間大幅縮短，通常只需要 8-12 分鐘，有時候甚至更快。
為了加速集會進行，我們會在各自的微博上提前記錄內容，再由系統自動集中到共筆頁面上。在 Standup 集會裡，我們會直接將頁面進行畫面共享。當大家都習慣這樣的工作方式後，大部份人的狀態彙報通常只有一句：“就是各位看到的這樣”，或“沒什麼新內容，搞定”。
精通 Scrum 的專家看到這裡，可能會認為我們不太對勁：整個團隊似乎根本沒有溝通。但我認為實際情況正好相反：團隊的溝通非常順暢，只不過溝通都是在 Standup 之外進行的。我們每天的工作都列在看板系統上：這塊看板實際上就是一個自動產生的共筆頁面，其中列出我們目前流程中需要執行的每項工作，例如這樣：
（Socialtext 的看板內容節錄。此處的 WIP 是指“開發中的工作”。同一頁裡還包括“準備中”、“品管中”，以及“等待核可”等未顯示的部份。）
通過看板了解狀態，並隨時消除阻礙，這些做法使得 Standup 程序變得沒那麼重要。它像是解決早期問題的古老機制，已經不再適用於團隊的現況。
事實上，情況正是如此。當年 Schwaber 和 Sutherland 兩人在 EasleCorp 公司創建 Scrum 方法時，他們需要解決的具體問題是這樣的：各項需求之間彼此衝突和影響的程度如此之高，以至於技術人員根本無法開展工作 — 他們甚至無法發佈任何一項產品。
因此，您可以將 Scrum 模型裡的“衝刺周期”理解為改變過程中的喘息時間，或者直接想成是“請給我們一個月時間做出實際工作，然後再來修改計劃。”
最近一年多來，這樣的問題已經再也沒有在 Socialtext 出現過。於是我們繼續改善工作流程。
進一步改善流程
從 2007 年起，我們嚴格執行為期兩周的“衝刺周期”。這個模式運作了兩年多，直到 2010 年初為止。在這段時間裡，我們共進行了 52 次為期兩周的“衝刺”，其中 48 次準時發佈為新版的產品。（如果您想知道細節的話，有兩次失敗的衝刺是因為聖誕節和新年的延誤，一次是由於品質問題導致延期發佈，還有兩次是因為功能未臻完善，不適合發佈。）
這兩年間，我們也遇到了各種挑戰 — 有五六次升級造成運作上的瑕疵，需要開發人員提供支持。但產品的整體素質依然很高，同時幾乎沒有顧客抱怨功能上的問題。
在將我們的工作拆分為小塊的過程中，我們自己的技能也得以提高，同時對於功能可以正式完成的時間估計也更加精確。結果我們發現，如果將工作拆分為幾乎相同規模的小塊，通常根本不需要估算工作量，就能測量出預計的完成時間。
一旦所有工作項目都高度一致，團隊的流程就可以從“只要以高品質成功完成，我們可以每兩周發佈一次”，變成“只要這塊工作完成，我們就可以發佈” — 與此同時，管理層對於專案準時完工依然可以保持充足的信心。
如此一來，我們逐漸從傳統的 Scrum 模型轉變成“塊狀工作”法，也可以稱做“看板法”。
在這段時間裡，我們也對每天舉行的 Scrum 集會進行改進，首先在周三添加了“工程話題”環節，之後則將集會改為每天進行，但並不要求必須全員參加。（“工程話題”包括傳統員工會議裡常見的活動：宣布人員招募訊息、公司策略討論、層出不窮的員工意見建議、測試人員發現的潛在問題等。）
幸虧有了看板，會議的焦點不再是“我目前正在做什麼”，因為大家都可以一目了然地看到每個人正在做什麼。現在我們討論的是接下來需要做什麼，何時以及如何調整優先順序，以滿足每天的需求。如此一來，我們不再需要討論如何完成目標和任務，以及我們被什麼卡住，而是轉為討論團隊正在面臨哪些挑戰，以及我們可以採取的措施。
雖然沒有任何一種流程是完美的，但我必須說，我喜歡這種方式的發展方向。
請不要誤會本文的意圖。我並不是說傳統的每日 Scrum 方法不好，我也並不是要推廣說我們的方法更好。準確來說，我只是想提供某種類型的最佳實踐紀錄。
筆者認為，要形成良好的流程，需要不斷地反省、調整，再做出改變。成長過程中可能會承受痛苦，但決不要放棄追求改善：沒有最好，只有更好。您肯定也明白這一點。
變得“更好”，並不意味著原來的方法就是錯誤的。 Scrum 方法並非一成不變，而是一種不斷持續改進的流程。就像煮一碗湯，您可以品嘗它、改進它，讓它每次的味道都變得更好。
一旦走上這條道路，您就不僅是在開發軟體，更是在創造文化。
創造文化的過程或許艱難，也許會充滿挑戰與辛酸。
不過，最終還是值得的。
