原文鏈接
作者：Mark Levison
機械的Scrum對比真正的Scrum，差別在哪裏？
最近，我和一個朋友聊到了他們公司實施Scrum的情況。他們有些迷茫！在實施Scrum之前，他們經常爲了訪問一臺測試機而不得不等上一個小時（甚至更多時間）。實施了Scrum幾年之後，這個問題依然存在。同一家公司，卻把測試服務器放在另一個國家，於是經常碰到網絡問題，導致處於運行狀態的測試中途失敗。這是他們開始採用Scrum之前就存在的問題，一直以來，沒有采取任何措施去解決它。
只有當問題存在於我們的環境之中時，用Scrum去解決纔會有效，而且我們必須爲之付出努力。
想一想這個基本原則：在每一個Sprint結束的時候，Scrum團隊被要求產出高質量的可用的軟件（或硬件）。質量要達到可發佈的標準。
在每一個Sprint週期內，任何阻止團隊完成可發佈質量的軟件的事情都算是一個障礙，必須要去解決！
而障礙沒有被解決時，通常的原因如下：
l “完成”的定義不存在，不被重視，或者沒有在一個真正公開的地方發佈出來（通常是團隊所在房間的牆上）。【注】“完成”的定義（Definition of Done）是一個檢查清單，是Scrum團隊用來檢驗一個產品積壓工作項是否真正被完成的標準。
l “完成”的定義直到每個Sprint快要結束、至少能發佈的時候才被頻繁更新和改進；最好可以持續發佈。
l 缺少組件支持，或者不是全功能團隊。Scrum對全功能團隊沒有做明確要求，但要求團隊具備足夠的技能，以便在每個Sprint結束的時候都能將軟件的一小塊功能（不只是一個組件）從頭到尾真正地完成。在Scrum框架下允許成立組件團隊，但這樣做會增加協調的成本。【注】全功能團隊（Feature Team）是一個長期存在、跨功能、跨組件的團隊，它能完整地實現客戶提出的很多功能需求，但每次只做一個功能。
l 有壓力，因爲每個Sprint都被要求交付更多的成果。很多團隊都有一種持續的壓迫感，他們被要求交付遠遠超出他們能力的成果。這種壓力如此之大，以至於他們常常爲了滿足需求而走捷徑。Scrum的設計初衷，就是給做事的人在決定他們能完成多少工作以及如何去完成方面更多的自由。這需要由團隊來表明立場，說清楚他們的能力。只有當團隊張弛有度，有時間暫停、反思和改進，真正的改進纔可能發生。
l 組織上的障礙沒有被消除。舉個例子，多個辦公室之間的網絡問題，多個團隊之間的協調問題，或者在團隊層面無法解決的其他任何問題。
請記住，Scrum是一種發現問題的工具，而不是解決問題的工具。
爲了讓Scrum發揮效力，你的組織必須解決在Scrum實施過程中突顯出來的問題。既然Scrum並不會爲你的組織解決問題，如果你對它暴露的問題不跟進解決，你就不是在真正地踐行Scrum。事實上，你只是在機械地搬弄Scrum。
