跨越邊界； 看板上的流程是用來跨越的，許多看板的使用者，不管運行了多久的看板方法卻從頭到尾都依據同一組流程來跑看板，這麼做就錯了。要知道；在同一個步驟內追求效率，致力於消除浪費，努力的提升效能降低半成品數(WIP)，這是不夠的，正好犯了限制理論(Theory of Constraints，TOC)所謂的局部優化的徵狀。正確的方式；應該先嘗試運用不同的開發流程，在找出團隊開發上的最大約束之後(例如:單元測試或整合測試)，再針對這個約束去擬定改善策略，以科學實驗的精神(假設-實驗-驗證)來發掘問題並改善問題，這才是運行看板方法真正的精神 —嘗試運行不同的流程。
早期TOYOTA時代的運用看板，是在追求產品製造過程的高效能運作。而 David J. Anderson 先生發明的看板方法(Kanban Method)則是運用在軟體開發上，適合做為敏捷變革前置運作的視覺化工具，它能讓團隊成員因為看見了自己在開發上所表現出來的效能，因而引發改善的意念，藉此激發團隊持續改善的意識。因此在運作上並非侷限在每個欄位的效能或致力於消除queue的浪費上頭，而是以人為本追求團隊開發的整體效能為依歸。
用最小的開發成本為客戶製造最大的價值。上圖借自《用戶故事地圖》作者 Jeff patton 在使用前必讀的起始章節中的說明。它屬於對PO產品負責人的期許，核心概念是人們透過產品的製造、新功能及特性增強來改變這個世界，而促使現在邁進到未來的則是製造產品所依據的思維:『需求正在改變這個世界』。講得更清楚些；是成千上萬的產品負責人透過規劃需求的方法，製造出各種產品來促使人類改變生活方式進而改變這個世界邁向未來。
需求正在改變這個世界
– Jeff Patton
用戶故事地圖的目的
在《用戶故事地圖》裡 Jeff Patton告訴我們:『用戶故事地圖真正目的是造成對需求認知的共識』。我們一群人圍繞著使用者故事地圖，從左到右描述著用戶會採取怎樣的操作步驟，然後再由上往下來討論上層的操作活動，再針對每個細節討論如何實作才能達成上一層的功能任務。然後從專案開始到結束為止，應該依據著需求的變化，大家持續更新著地圖上的任務。讓視覺化的全貌協助我們自始自終讓所有的人都能知道團隊已經完成那些任務現在正在進行怎樣的工作、專案的全貌長成什麼樣子而我們又在哪裡。換句話說；就是因為透明令大家都看見進度，而更是看見後能夠擁有相同的認知；達成了一致的共識。
英國國防部在2009年左右，為了減少友軍誤殺自家人的事件(註2)，決定開發一套戰鬥識別系統(Combat Identification System, CIDS)，避免悲劇繼續發生。採用的需求四分法是一個典型的放棄傳統計畫驅動開發改為價值驅動開發的作法。下圖中左側是傳統計畫型開發考慮的「時間-資源-需求」專案鐵三角。對正到右側的DSDM(Dynamic Systems Development Method)敏捷開發方式，差異在左側不可變的功能並預設可改變的是時間與資源，也就是專案開發必須完成所有的需求才算完成，右側則是站在開發者的立場，視需求功能是可調整的項目，並依此來配合固定的時間與資源量。
所有需求都要做是典型計畫驅動開發的思維
當PO無法抉擇需求的MoSCoW分類時 – 採用不同的使用者類別
計畫是為了更少的開發；這個道理大家都懂，但是你若以計畫驅動開發(傳統)的思維方式來規劃開發方法的話，就是會以在時程內完成所有的需求為目標。而忽略了不是所有使用者都會需要所有的功能的。因此請扭轉你的思維改以先完成哪些對使用者最有價值的需求，也就是價值驅動開發的思維方式。做法是:採用不同的使用者類別(persona)來區分需求，一定有一些需求是大部分的使用者都會用到的，這些便是屬於 Must Have的部分。也一定會有一些需求沒有那麼多使用者都會用到的，這些僅次於Must Have的需求，就可以排進Should Have的部分。至於那些看起來不是非要不可的需求就屬於 Could Have 的類別。在其他的便是Won’t Have了，也就是不會被列入開發工作的需求。
身為敏捷教練；可能一輩子都會不停地在尋找能夠讓敏捷更加敏捷的方法(它可能就是我這輩子的無限賽局了)。其實可以推廣的理念很多，例如 Dan North 的刻意發現(Deliberate Discovery)，就是一個讓敏捷開發更早開始的好概念。應該算是團隊在開始開發行為之前的前置處理動作吧。這種讓開發者在還沒開始動手之前就能先加強相關domain knowhow的做法(增進開發專案的相關知識)，對即將到來的開發作業一定會有著某種程度上的幫助的(與prototype 或MVP應該有著一樣的貢獻)。波士頓諮詢公司BCG的「假說思考」在某種形式上也算是一個前置思考的方法，但要更讓人驚艷。
假說思考是來自波士頓諮詢公司BCG的策略思維方法。(請參考内田和成所著的《假說思考：培養邊做邊學的能力，讓你迅速解決問題》，原著標題是The BCG Way—The Art of Hypothesis-driven Management) 是一種思維模式也是一種顧問需要養成的習慣。就是在解題時從資訊還相當有限的初期階段起，就不斷思考問題全貌與結論的方法。先做假說；這麼做可以有效的減少需要考慮的系統範圍，一旦系統範圍縮小了，就能讓我們更專注在小事件的驗證上，小範圍能便於快速的進行驗證，又能以逐步釐清的方式去看見問題事件的全貌。它符合敏捷開發小增量的核心觀念，讓我們專注的聚焦於小的驗證上頭，逐步去釐清問題的看見它的全貌。
是的，主管需要成為團隊的教練。因為今天組織是以團隊運作的方式為主，已經不是主管一個人所能獨自完成的工作了。主管需要的是去瞭解他們的員工正在做什麼，但是並不是要像每位員工一樣能夠熟練地完成工作。再說；現在的員工並不需要一個權威人物來告訴他們或督導他們做什麼了。相反地，員工需要的是一個能夠傾聽、指導、訓練以及幫助他們的「教練」。身為教練這個角色的首要任務，便是能夠確保團隊成員擁有完成一流工作時所需要的資源。同時；還必須不斷激勵他們學習成長，為他們釐清責任和目標，使他們能提高工作績效，並且在組織內貢獻自己的力量。(參考: 《高績效教練》by: Sir John Whitmore)
隨後布蘭查德又提出進階的「部屬發展模型」Development Level of the Individual 4階段，以員工的工作能力和工作意願，來判斷員工處於哪一發展階段，並據此將部屬個人的發展階段與主管的領導風格連結了起來。因為是藉由不同的工作任務來界定員工處於哪種發展階段，所以當某一項工作任務更換時，就得重新診斷員工的發展階段。(參考MBA智庫百科)
應對無知的二個利器，限制理論與刻意發現。限制理論（Theory of Constraints，TOC）是一種系統思維，它是由以色列學者伊利雅胡·高德拉特所發展出來的一種全方面的管理哲學，主張一個複雜的系統隱含著簡單化。但是它一定存在著某種約束，這些約束造成他無法達到最高的效率，而我們只有透過持續的去發覺並解決最大的約束才能提升效能(註3，限制理論範例)。這是一種針對系統全貌下的持續改善思維。這種思維跟我們說，即便讓你一次再一次的進行重作相同的專案，你仍然會受到某些約束(無知始終是你最大的約束)，它是限制你的效能無法無限制提升的最大約束，TOC這個系統思維工具的最大特色也就是在形容一個系統裡具有著相互關連的動態屬性，當你想要提升系統的效能時，只能持續的去發掘最大的限制(如果你處理的不是最大的約束時，你可能是在做局部優化的動作，對提升系統整體的效能將沒有幫助)，然後改善它，接著再去尋找下一個最大的約束，繼續改善下去。
BDD之父 Dan North 於2003年提出了刻意發現(Deliberate discovery) 的概念，目的是用來應對專案開始時的無知(請參考「無知的無知」)。多年來的成果，是鼓舞了業界發展出來許多好用的工具用來協助我們發覺未知的困擾。下圖右側是精實開發的處理原則: 延遲決策與看見全貌來解決無知，上半部則是一些發展出來的實用工具。
在這個資訊爆炸的時代，我們缺少的經常不是相關資訊而是缺乏過濾相關資訊的能力。有一句對發明家的評語在這裡派得上用場，那就是擁有較寬廣的視野與願意深入理解的心。正是遇問題先看見問題的全貌，然後才去深入探索問題。這是降低模糊性的好方法。對應到精實原則(Lean principle)則是建議我們要盡量延遲決策（Decide as late as possible），避免直覺反應式的直觀決策方式，並以著眼整體（See the whole）的方式來處理問題。
上圖是參考 Targetprocess公司 Michael Dubakov先生在Blog上所發表的著作(註2. 原文)，它是拿來分析軟體開發速度相關元素的極好的參考資料，這裡我僅僅擷取與系統複雜性有關的區塊翻譯成中文。加了一點實作上的考量(原文抽象度太高)，但在右上角我加進了「架構設計」的影響，並給予它和程式技巧區塊一個AND的屬性。意思是好的架構與好的程式技巧都能消減系統的複雜性。而程式設計巧甚至會受到架構設計的制約(限制)，所以我擅自加了一個綠色的區塊跟一個橢圓的符號。因為這也是我最常建議開發單位進行改善時的起始點(所以用三顆星來顯示)。
