Scrum 方法乍看簡單，但長期採用它會產生怎樣的影響呢？Matt Heusser 花了一些時間反思，並寫下三年來每天在 Scrum 團隊裡工作，所經歷的實際情況。
(這是 Three Years of Scrum at Socialtext 這篇文章的中譯。)
這年頭，從樓上扔下一塊磚，都能砸到幾個向您推薦如何使用 Scrum 方法過渡到敏捷開發
的專家們。這項工作非常重要，我也很高興看到有人這樣做，但本文的重點不在這裡。
相反的，我想講一講我們公司 Socialtext 採用 Scrum 方法的真實故事。
我在 2007 年秋天加入 Socialtext 時，我們才剛開始使用敏捷流程。在接下來的三年多裡，我們不斷針對開發流程進行改進。
本文的重點，並不在介紹敏捷開發的具體轉換過程，而是介紹 Scrum 方法，特別是每天的
關於 Socialtext
Socialtext 的總部位於矽谷的核心地帶，主要負責營銷方面的運作。
雖然產品管理、工程總監，以及少數開發人員在總部上班，但絕大部分的技術人員，都是在遍布全球的分部，或是在自己家裡進行工作。
我們開發的產品，是給企業用的社會軟體。應用這個平台，可以在任何能上網的地方工作。這種靈活的工作方式讓團隊獲益匪淺：我們可以不受地理位置的限制，招募到最能勝任工作的人。
如果您由於地理位置或時區差異等原因，不確定 Scrum 方法是否適用，請別擔心；我們以前也有過這些疑慮，但後來都找到了合適的解決之道。
促進溝通協作
許多 Scrum 團隊認為開會是高成本、又容易浪費時間的事，因此嚴格限制團隊的溝通時間。我們嘗試了一種不同的策略：盡量降低溝通成本。
為了讓溝通更方便，我們團隊採用了 Astertisk 這項開源工具作為
一開始，我們採用定期兩周的開發周期，並且每周三次在下午一點舉行立會。
在 Scrum 模式裡，每個人在立會裡輪流報告三部分的訊息：我昨天做了些什麼，我今天打算做什麼，以及目前遇到的阻礙。
阻礙會大幅降低生產力，因為每位成員每天通常只專注於單一項目，所以如果項目卡住了，會讓開發人員變成非常昂貴的花瓶。
不過，即使是被卡住一天，也令人相當頭疼。要等一整天，在下次會議上再告訴別人，這個方法並不怎麼高明。因此，我們決定使用微博和聊天室作為彼此求助的管道。
此時團隊面臨一個決策：如果我們允許遇到阻礙的團隊成員打擾其他同事，那麼可能直接對他人的工作產生影響。好比說在聊天室裡提到某人的名字時，會讓他的電腦發出提示音，打斷他目前正在進行的工作。
最後我們決定允許這種打擾，因為被卡住會造成更大的浪費。
同時，我們也運用各種協作工具，例如用 GNU Screen 共享畫面、用 VNC 進行圖形界面測試，來進行
(請繼續閱讀下集。)
