1

團隊目標或任務不明確

敏捷章程中關于目標的部分：愿景、使命和使命測試

2

團隊工作協議不明確

敏捷章程中關于一致性的部分：價值觀、原則和工作協議

3

團隊環(huán)境不明確

敏捷章程中關于環(huán)境的部分：邊界、承諾資產和前瞻性分析

4

需求不明確

幫助發(fā)起人和相關方制定產品愿景?？紤]使用實例化需求、用戶故事地圖和影響地圖來構建產品路線圖。讓團隊和產品負責人一起來明確需求的期望和價值。逐步將路線圖分解為具有更少具體需求的待辦事項列表。

5

用戶體驗不佳

開發(fā)團隊的用戶體驗設計實踐應在早期就讓用戶經常參與。

6

估算不準確

通過分解故事來讓故事變小。讓整個團隊使用相對估算進行估算?？紤]通過敏捷建?；虼烫絹砝斫夤适?。

7

工作分配或工作進展不明確

幫助團隊認識到要自我管理工作?？紤]用看板面板查看工作流程。考慮利用每日站會，根據看板查看工作進展。

8

團隊面臨障礙

仆人式領導能幫助消除這些障礙。如果團隊不知道他們都有哪些可選方案，就要考慮聘請教練。有時，團隊或仆人式領導無法消除障礙，團隊就需要上報故事。

9

由于產品待辦事項列表不夠完善，導致工作廷誤/超時

產品負責人和團隊—起研討故事。為故事創(chuàng)建—個準備就緒的定義。考慮分拆故事以使用更小的故事。

10

缺陷

考慮對特定環(huán)境有效的技術實踐。它們可能是：結對工作、產品集體負責制、普適測試（測試驅動方法和自動化測試方法）以及穩(wěn)健的完成的定義。

11

工作未完成

團隊確定故事完成的定義，包括驗收標準在內。另外，還要為項目補充發(fā)布標準。

12

技術債務（代碼質量降級）

重構、敏捷建模，普適測試、自動化代碼質量分析、完成的定義

13

產品復雜性過高

無論是軟件項目還是非軟件項目，都要常常鼓勵團隊思考:“最簡單的有效方法是什么？”，開應用“簡潔，即盡最大可能減少不必要的工作，這是一門藝術”的敏捷原則。這樣做將有助于降低復雜性。

14

團隊合作過程進展緩慢或沒有改善

在每次回顧中，選擇的改進項目不要超過三個。讓仆人式領導幫助團隊學習怎樣整合這些待改進項。

15

前期工作過多導致返工

不要做過多的前期工作，而要考慮讓團隊通過刺探來學習。另外，在項目開始時衡量在制品(WIP)，看看哪些部分團隊并不需要設計，只需要交付價值。縮短迭代，并創(chuàng)建一個穩(wěn)健的完成的定義。

16

錯誤的開始，前功盡棄

讓產品負責人成為團隊不可分割的一分子。

17

產品待辦事項列表雜亂無序

按價值排序，并考慮延遲成本按持續(xù)時間(CD3)和其他價值模型劃分。

18

倉促/等待，不均勻的工作流程

計劃要對應團隊的能力，而不是超出能力所及。要求人員停止多任務，為一個團隊專注工作。請團隊利用結對、群集或群體開發(fā)等方法，平衡整個團隊的能力。

19

相關方要求無法滿足

仆人式領導與這個相關方（可能是產品負責人)一起工作。

20

意想不到或不可預見的延誤

讓團隊更頻繁地檢查，使用看板面板檢查工作流和在制品限制，了解需求對團隊或產品的影響。也可以在障礙板上跟蹤障礙和障礙消除情況。

21

孤立的團隊，而不是跨職能團隊

讓項目人員作為跨職能團隊自我組織。使用仆人式領導技巧幫助管理人員理解為什么敏捷需要跨職能團隊。