你正在以某種身份領導敏捷軟體交付團隊—可能是ScrumMaster、產品負責人或產品經理。你的團隊一直努力與敏捷宣言保持一致，並且你為他們定期建置和發布軟體的能力感到自豪。你深信，由於你的團隊有能力比以前更快地學習、適應快速變化的市場環境，你的產品或服務會變得越來越好。不幸的是，隨著敏捷與公司現狀之間的差異越來越明顯，你的工作也變得越來越具有挑戰性。團隊越敏捷，你就越容易與組織的其他部分產生摩擦。

在學習敏捷、精益、OKR之類的方法和工具時，有一個公認的難題，那就是：一聽就會，一做就廢。在市售的培訓中，課程簡介上往往吹得天花亂墜，帶你實踐、包你掌握，你來了聽著感覺也挺熱鬧，收穫滿滿一筆記本。回去實踐就立刻發現很多細節問題無法解決，勉強做了倆月， 一地雞毛、怨聲載道。現在流行的DevOps、Scrum、SAFe、精益生產，專案管理和OKR培訓……等等，基本都是這種情況。培訓完獲得了認證，但這不代表有任何能力，也不代表你對該領域的知識都理解到位。有種觀點認為，該現象的產生是因為這些知識本身是一個複雜的體系，短期培訓無法涵蓋全面，還需要大量的實踐和後續學習。

腳踝不舒服的你去掛了骨科門診，進入診療室後，發現各種榮譽獎狀掛滿牆，甚至有很多與各國元首握手的照片。當你希望透過骨科專家的知識來診斷你困擾一世的疾病時，卻突然發現專家在翻閱《腦科學》來幫你看病，你是什麼感覺？

產品待辦列表及Sprint待辦列表 這20多個月時間裡，主要做一件事，就是實現從瀑布開發轉型為敏捷反覆運算開發。過程涉及需求管理、工程方法導入、過程自訂、團隊建設、過程改進等等。