Ron Jeffries 的提醒，大家在以 scrum 進行軟體產品開發時，要避免本末倒置、倒行逆施。
“When a team does not have the necessary and less than obvious technical skills to produce a shippable Scrum Increment week in and week out, the Scrum process almost inevitably goes dark.”
如果你是工程人員，更建議你先從 極限編程(extreme programming) 著手。
事實上我們看過這麼多的客戶，極少看到 agile/scrum 落實內化很好，但極限編程跟人員的工程技能低落的。
大部分順利的路，是從極限編程做得不錯，再引入 scrum 的。可以參考我自己的 scrum 序章：https://tdd.best/blog/my-beginning-of-scrum/
也有一種很特別的例子，是 agile/scrum + XP 併行推進的，這個比較考驗大家對目標的認同，對相同方向上的施力，而且一開始就認知自己組織內可能各方面能力都需要提升，才能在這持續改善的路上持續學習，知道這條路本來就充滿荊棘挫折，但只要我們能越來越好，就總比之前好上不少。
Ron Jeffries 是誰：https://en.wikipedia.org/wiki/Ron_Jeffries
極限編程 三大頭之一，敏捷宣言 17個簽署人之一，同時也是 Scrum Alliance 的 CST 培訓師。
在我們多天的 scrum 相關培訓中，通常就會有一半以上是實際的開發協作過程。
--
最近一年也讓我試著換另外一個角度來看，
「改善比較容易，還是加班比較容易？」
「學 scrum 比較容易，還是學單元測試、重構、TDD 比較容易？」
最直接的方式，做個調查，多少公司以 scrum 方式進行開發，而多少公司內有落實 unit test 與持續重構。這個比例拉出來，就不意外為什麼大部分看到的都是 Dark Scrum 了。
開發人員總是訕笑著 PM 永遠都給著不合理的時程，然而他們也總是以「沒有時間」當藉口來掩飾自己技能上的不足。
如果你是在開發軟體產品，那整體就是 領域(產品) x 協作(溝通) x 開發 (交付) ，而且真正做東西出來的核心，還是開發交付的部份。
這一塊夠扎實，即使是瀑布，也可以有一定的成績。
敏捷瀑布比較 在 [分享] 瀑布式VS. 敏捷式思考的成家買房計畫 - Mobile01 的推薦與評價
敏捷 式思考的成家買房計畫 ... 而這種思考行為模式, 在軟體開發上, 叫做瀑布式開發, 就是用計畫驅動你的行為 ... 因為這裡的人比較熱衷於行情預測。 ... <看更多>