敏捷流暢模型
敏捷成功簡要指南
敏捷方法穩固地成為主流,但這種普及並非沒有問題。組織領導者抱怨他們沒有得到預期的效益。本文提出一個流暢模型,將幫助你充分利用敏捷理念。流暢性透過四個不同的區域演進,每個區域都有其自身的效益、所需的熟練度和關鍵指標。
2018 年 3 月 6 日
自 90 年代後期以來,我們一直領導並協助團隊轉型為敏捷開發。在那段時間裡,我們看到敏捷運動從熱情和創新者的程式設計師為中心熱情,成長為一個接管軟體世界的龐然大物。
儘管成功——或者可能正因為如此——敏捷方法並非總是能達到人們的期望。敏捷名人發布文章,例如 Martin Fowler 的 軟趴趴的 Scrum(2009 年)。有人抱怨諮詢公司透過強迫人們接受僵化、不敏捷的流程來牟利。組織領導者擔心他們沒有獲得應有的好處。
在我們協助敏捷團隊的多年中,我們學到了很多關於如何使用敏捷取得成功,以及為什麼這麼多組織沒有看到他們預期的結果。2012 年,我們將這些學習正式化為敏捷流暢™[1] 模型,並在此處發布。在隨後的六年中,應用此模型讓我們學到了更多。現在我們已經更新了這篇文章,以納入我們最新的發現。
使用這篇文章來了解你對敏捷團隊的期望效益;必須進行哪些投資才能獲得這些效益;以及當你的團隊未提供你需要的效益時,該往哪裡看。這可能涉及一面鏡子。
介紹模型
我們觀察到敏捷團隊在學習過程中會經歷四個不同的區域。每個區域都會帶來特定的好處。
- 專注團隊會產生商業價值。
- 交付團隊會按照市場節奏交付成果。
- 最佳化團隊會領導其市場。
- 強化團隊會讓其組織更強大。
每個區域都仰賴一組敏捷能力。能力是一種可觀察的行為,例如「團隊與一位業務代表合作,該代表會提供團隊業務觀點和期望」,這會帶來區域的好處。
在敏捷流暢度模型中,我們最感興趣的是流暢能力:一種在任何時候都展現能力的習慣,即使在壓力下也是如此。任何人都可以在課堂上專注時遵循一組技術;真正的流暢度是一種熟練、例行的輕鬆,即使你的心被其他事情分散時也能持續。
敏捷開發是一種團隊運動,因此流暢度是團隊的特質,而不是個別團隊成員的特質。在實務上,有些能力會由所有團隊成員展現,有些能力則會是少數個人的專長。無論如何,團隊的流暢度來自於團隊成員自我組織的能力,以便在正確的時間將個別技能應用於正確的問題上。
當團隊流暢於所有區域的能力,包括前身區域時,團隊就會流暢於某個區域。儘管團隊會以任何順序開發能力,甚至會同時從多個區域開發能力,但我們觀察到團隊往往會以可預測的順序獲得區域流暢度。

只要保留版權公告,您就可以自行使用此圖表。下載橫向版本 (PNG、PDF);縱向版本 (PNG、PDF);或詳細版本 (PNG、PDF)。
選擇你的區域
每個流暢度區域都會帶來新的好處,因此模型似乎應該被視為成熟度模型,其目標是達到最大的成熟度。那將是一個錯誤。與成熟度模型不同,成熟度模型中更成熟總是更好,流暢度模型描述了一系列選擇。每個區域都代表一個完全成熟的選擇。每個區域都會帶來價值。
將流暢度想像成搭乘公車。當你搭上公車時,你會購買一張前往你想要到達區域的車票。較遠的區域並非本質上更有價值;它只是花費更多,而且需要更長的時間才能到達。有時你會購買前往郊區的公車票,因為你想要去大型賣場。有時你會購買前往市中心的車票,因為你想要看戲。兩者並非本質上更好,一切都取決於你那天需要什麼。
類似地,儘管每個區域都有價值,但每個區域也會帶來挑戰。投資超過你的需求可能會招致組織的反彈,甚至可能毒害人們對敏捷理念的整體看法。
仔細考慮對你來說正確的權衡取捨,而不是簡單地假設越多越好。
團隊適用的區域取決於組織。傳遞或最佳化通常是最佳目標,但專注和強化也可能是好的選擇。
-
專注區域代表敏捷基礎,而流暢的團隊為透明度和團隊合作帶來顯著的優點。儘管專注流暢度不包括永續技術實務,但這是展現成功並為進一步投資創造支持的好方法。這也適用於某些數位代理商等不長期維護其軟體的團隊。
-
對於需要修改和增強其軟體超過幾個月的團隊,傳遞流暢度通常是更好的選擇。此區域代表敏捷永續性。傳遞團隊缺陷低、生產力高,且能回應業務需求。此處的流暢度對大多數團隊來說是寶貴的躍進。
-
希望設定市場變革步伐或預見市場中斷威脅的組織,將受益於選擇最佳化區域。最佳化代表敏捷的承諾:創新的業務敏捷性。儘管它有顯著的回報,但也需要對組織結構進行破壞性變革。在小型、靈活的組織中進行這些變革通常最容易。
-
希望創新管理理論和實務的領導者,特別是在中小型組織中,可能會發現強化區域最適合其團隊。此區域是敏捷的未來。尖端的敏捷實務似乎朝著那個方向發展。但是,請注意,此區域需要研究尖端的管理理論並發明新的工作方式。
即使在單一組織內,不同的流暢度區域也可能適用於不同的團隊。我們將在本文稍後描述每個區域涉及的投資和收益。在閱讀這些區域時,請記住每個區域都有自己的成本和權衡。仔細考慮適合您的權衡,而不是簡單地假設越多越好。
達成流暢
流暢度更像是習慣而不是技能。儘管培訓可以教授基礎技術,但流暢熟練度核心的熟練輕鬆需要幾個月來進行深思熟慮、周到的日常練習。它來自於透過實務學習的深思熟慮投資。
後續區域涉及的熟練度往往需要比早期區域的熟練度更多時間。團隊越早開始處理區域的熟練度,團隊就越早能流暢掌握它們。敏捷熟練度也相互支援。因此,最好選擇您想達到的流暢度區域,並同時開始練習該區域所需的所有熟練度,以及所有先前的區域。
最好選擇您想達到的流暢度區域,並同時開始練習該區域所需的所有熟練度,以及所有先前的區域。
(當然,你隨時都可以改變主意。從一個區域開始,然後再針對不同的區域,並沒有什麼壞處。只是需要花費較長的時間。)
當團隊練習其熟練度時,流暢度會時好時壞。熟練度並非從一個區域有條不紊地進展到下一個區域,而是會在所有區域平行發展。你可能會很快看到令人鼓舞的跡象,但真正的流暢度所具有的精通度和可靠性可能會令人沮喪地緩慢。熟練度會停滯不前,忽高忽低,並以不同的速度進展。
影響團隊流暢度最大的因素之一是組織支援。延續公車的比喻,團隊必須搭乘公車前往他們的流暢度區域。沒有人可以代替他們。但組織必須購買公車票。期望流暢度卻不提供適當支援的組織註定會失望。更糟的是,支援不足可能會造成人員流動,並營造出阻礙改善的犬儒企業文化。在踏上流暢度之旅之前,請確定你的組織已做好提供旅程所需支援的準備。
組織將進行的最大投資之一是時間。真正的流暢度需要比任何人預期或想要的更長的時間。根據我們指導團隊的經驗,團隊需要花費兩到六個月才能在「專注」區域變得流暢。取決於程式碼中的技術負債數量,到達「交付」區域需要再花費 3-24 個月。「最佳化」流暢度可能需要再花費 1-5 年,取決於組織信任度和改變報告結構的意願。
區域 | 好處 | 投資 | 學習自 | 達到流暢度所需時間 |
---|---|---|---|---|
專注 | 更深入了解團隊的工作;能夠重新導向。 | 團隊發展和工作流程設計。 | Scrum、看板、非技術性的 XP | 2-6 個月 |
交付 | 低缺陷和高生產力。 | 在技術技能發展期間生產力下降。 | 極限編程、DevOps 運動 | +3-24 個月 |
最佳化 | 價值更高的交付和更好的產品決策。 | 將業務決策和專業知識轉移到團隊中所耗費的社會資本。 | 精實軟體開發、精實創業、超越預算 | +1-5 年 |
強化 | 跨團隊學習和更好的組織決策。 | 開發管理組織的新方法所需的時間和風險。 | 組織設計和複雜性理論 | 未知 |
失去流暢
穩定的團隊自行失去流暢度的情況很少見。根據我們的經驗,造成流暢度流失的是外部干擾。
流暢度流失最常見的原因是,新管理階層決定敏捷方法不符合他們的願景。在沒有組織支援和無法繼續實踐他們所學到的知識的情況下,團隊流暢度會迅速流失。這通常伴隨著專業知識的流失,因為不滿意的團隊成員會尋求新的職位。
員工流動率是流暢度下降的相關原因。成員流失或增加過多的團隊可能會難以維持其所學。這對於每個專案都組成新團隊的組織而言,是一個特殊的問題。
快速成長和強制流程也會導致流暢度下降。成功的初創公司經常會遇到這個問題。當規模較小時,初創公司通常會本能地在最佳化,甚至強化區域中運作。(他們不一定在每個能力方面都流暢,但他們的本能會將他們推向這些區域。)一旦初創公司開始快速成長,他們經常會引入官僚主義和流程,而這些流程會意外地損害流暢度和文化,而這些正是流暢度的促成因素。
同樣地,在個別團隊中成功使用敏捷理念的公司,有時會在其團隊中強制執行擴充架構。這些架構中的大多數僅設計用於支援聚焦流暢度,而有些架構的設計更偏向於管理吸引力,而非敏捷卓越性。這使得在後續區域中發展和維持流暢度變得困難。
這並不是說特設成長是正確的答案。成長、擴充和流暢度之間的關係是一個複雜的主題,值得專門撰寫一篇文章。就目前而言,我們只會說,要在大規模中獲得流暢度,你必須在每個個別團隊中都具備流暢度。當你評估擴充選項時,請考慮你的選擇如何支援和阻礙你想要的區域的能力。
組織流暢
在敏捷組織中,組織的工作是由具有共同目標和相互依賴工作的協作人員團隊完成的。因此,流暢度源自團隊。個人或組織可能會對團隊的流暢度有所貢獻,但他們無法自行流暢。
儘管組織本身無法流暢,但討論組織促成的流暢度是有道理的。團隊流暢度不僅取決於團隊成員的技能。它還取決於管理結構、關係、組織文化等。不要犯下將團隊缺乏流暢度的錯誤歸咎於個人,或假設一個高技能的個人將保證流暢度。組織背景通常更為重要。
當團隊在流暢度發展中遇到障礙時,他們通常會在一些特定能力上遇到困難。有時問題在於缺乏知識或技能,而培訓和指導就是團隊所需的一切。
更常見的是,團隊的發展實際上受到組織約束的阻礙。你可以透過對多個團隊進行流暢度診斷來檢查組織約束。(敏捷流暢度專案在 agilefluency.org 提供診斷選項。)如果多個團隊在相同的技能上遇到問題,則表示存在需要組織層級投資和變革的系統性問題。
在後續各節中,我們將描述每個區域所需的技能和組織投資。當你閱讀它們時,請思考你的組織準備促成哪些區域,以及它目前設計為阻礙哪些區域。
「專注」團隊產生商業價值
摘要 | 敏捷基礎 |
好處 | 更深入了解團隊的工作;能夠重新導向。 |
投資 | 團隊發展和工作流程設計。 |
學習自 | Scrum、看板、非技術性的 XP |
時間 | 2-6 個月 |
流暢的專注團隊以凝聚的團隊形式合作,擁有共同的目標。他們會從贊助者、客戶和使用者將從其軟體中獲得的利益來思考和規劃。這與才剛開始敏捷旅程的團隊形成對比,後者傾向於從技術考量(例如軟體層)來思考,而且通常以個別貢獻者的身分工作,並執行個別指派的任務。
專注:團隊會從贊助者、客戶和使用者將從其軟體中獲得的利益來思考和規劃。
Scrum、看板和極限編程的非技術部分是團隊用來達到專注流暢度的敏捷方法範例。使用者故事是最常見的團隊採用技術之一。其他技術包括待辦事項、回顧、時限(例如 Sprint)和團隊任務看板。專注團隊也會關注互動概念,例如心理安全、團隊憲章、小組學習和同儕回饋。
流暢於此區域的團隊會展示他們正在處理的內容,以及從商業價值觀點來看,其進度如何,至少每月一次。這是專注團隊的核心指標:這並非你應從流暢團隊預期的唯一利益,但這是檢查團隊是否流暢的輕鬆、快速方法。如果你無法了解團隊的商業優先順序,或如果這些優先順序無法反映團隊實際正在處理的內容,則表示團隊尚未流暢。
預期的利益
透明度 | |
核心指標 | 團隊至少每月一次展示其正在處理的內容,以及從商業價值觀點來看,其進度如何。 |
降低風險 | 管理階層知道團隊何時建立錯誤的事物,或沒有進展,並有能力積極介入。 |
成就 | |
提高生產力 | 團隊會定期反思、調整和調整其工作習慣,以提供更多價值。 |
提高投資報酬率 | 團隊將工作重點放在對業務來說最重要的事情上。 |
提高投資報酬率 | 團隊每月在業務優先事項上取得漸進式進展。 |
協調一致 | |
提高生產力 | 協作溝通可減少團隊成員之間的誤解和交接延誤。 |
專注的好處來自於有效的溝通、協作團隊合作和持續的團隊改進。這些類別的流利程度並非技術挑戰,但對某些人來說,轉變為團隊文化可能很困難。團隊成員必須學會從業務成果而非技術的角度來規劃。他們需要學會為整個團隊的成功負責,而不仅仅是他們的個人貢獻。經理必須學會支持團隊合作,而不是個人獎勵和任務規劃。
區域專長
回應業務需求 |
團隊與業務代表合作,由業務代表提供團隊業務觀點和期望。 |
業務利益相關者可以依賴團隊根據業務代表對下一個最有價值事項的看法來工作。 |
團隊規劃其工作,並以其業務代表理解和重視的區塊顯示進度。 |
團隊的業務代表至少每月可以看到並可以改變團隊的方向。 |
管理層使團隊能夠以一種可以無限期回應業務需求的速度工作。 |
有效地作為一個團隊工作 |
團隊產生自己的日常任務和計畫(基於其業務代表的需求)。 |
團隊成員認為他們的計畫是團隊的工作,而不是個人的工作。 |
團隊成員共同承擔完成計畫的責任。 |
管理層將計畫視為團隊的工作,而不是將責任分配給個人。 |
追求團隊偉大 |
團隊接受並持續改進其工作的共同方法。 |
團隊意識到團隊成員關係如何影響其成功能力,並積極嘗試改善它們。 |
團隊意識到其工作環境如何影響其工作能力,並積極嘗試改善它。 |
投資/價值權衡:一群獨立的個人貢獻者需要兩到六個月的實踐才能轉變為協作的、基於團隊的工作方式。他們的流利程度不僅取決於他們的努力,還取決於其組織的投資。正如我們之前所說,團隊可能會駕駛他們的流利巴士,但他們的組織需要購買巴士票。
對於許多經理和組織來說,最具挑戰性的投資是非金錢的。讓團隊有效地作為一個團隊工作可能需要改變管理行為,讓團隊成員全職投入團隊,並重新設計物理工作空間。特別是,經理必須從管理個人貢獻轉變為管理工作系統——指導團隊流程、工作習慣、技能和環境,以便團隊在沒有明確管理參與的情況下做出正確的決策。
我們看到許多組織選擇不進行這些投資,但仍然期望其團隊流利。在這些情況下,團隊能力發展緩慢,很少能達到完全流利。如果你的組織無法進行必要的投資,敏捷方法將會令人失望。
常見的組織投資
選擇具有適當技能、背景且願意合作的團隊成員。將他們 100% 分配給他們的團隊。 |
建立一個以生產力為重點的共用工作空間,強烈建議使用實體團隊室。如果實體團隊室不可行,則提供豐富互動的虛擬工作空間,並接受這將會降低效率。 |
確保具有業務優先事項和客戶價值專業知識的人員可以擔任團隊的業務代表。 |
移除阻礙有效團隊合作的障礙,例如競爭排名、個人獎勵和分散式團隊。 |
指導和訓練團隊成員培養「專注」的熟練度。 |
訓練經理創造一個支持團隊合作的環境,以及如何管理工作系統,而不是個人貢獻。 |
作為這些投資的回報,你將更清楚了解團隊的工作內容,並且能夠引導他們將 20% 的工作用於提供 80% 價值的部分。
「交付」團隊在市場節奏中出貨
摘要 | 敏捷永續性 |
好處 | 低缺陷和高生產力。 |
投資 | 在技術技能發展期間生產力下降。 |
學習自 | 極限編程、DevOps 運動 |
時間 | +3-24 個月 |
流暢的「傳遞」團隊不僅專注於業務價值,他們也透過盡可能頻繁地出貨來實現價值。這稱為「依據市場節奏出貨」。「傳遞」團隊與「專注」團隊的區別不僅在於他們的出貨能力,還在於他們能夠隨意出貨的能力。
傳遞:團隊可以在業務需要時,以最低的風險和成本發布其最新工作成果。
極限程式設計 (XP) 開創了許多「傳遞」團隊使用的技術,並且至今仍具有重大影響力。幾乎所有流暢的團隊都使用其主要創新,例如持續整合、測試驅動開發和「無情的」重構。
近年來,DevOps 運動將 XP 的理念擴展到現代的雲端環境。該運動的持續傳遞和持續部署技術被大多數「傳遞」團隊使用。其他有用的技術包括演化設計、集體所有權以及配對程式設計或暴民程式設計。
精通「傳遞」的團隊會建立低缺陷的軟體,可以依據組織的需求頻繁出貨。如果一個團隊無法隨意發布,他們還沒有達到流暢的程度。
預期的利益
透明度 | |
核心指標 | 團隊可以在業務需要時,以最低的風險和成本發布其最新工作成果。 |
降低風險 | 生產週期的系統性缺陷會在早期被發現。 |
增加滿意度 | 團隊會根據需要為經理和客戶提供有用的發布預測。 |
成就 | |
提高生產力 | 團隊的缺陷率低,因此浪費在修復錯誤的時間較少,而投資在改善上的時間較多。 |
提高生產力 | 團隊的程式碼庫技術負債低,這使得變更更便宜且更快速。 |
提高投資報酬率 | 團隊在市場節奏中出貨,在市場能承受的頻率下擷取價值。 |
協調一致 | |
提高生產力 | 缺陷率和技術負債低有助於工作滿意度和士氣,進而改善留任率和生產力。 |
交付 是技術最密集的流暢度區域。有很多技能需要學習。有些技能,例如測試驅動開發,屬於「花時間學習,花一輩子精通」的類型。團隊成員將受益於極限程式設計、DevOps 和敏捷軟體品質大師所描述的技術學習和實踐。經理需要確保團隊由具備所有所需專業知識的人員組成,並且他們需要與利害關係人合作,建立重視深思熟慮的工作勝於權宜之計的期望。
區域專長
回應業務需求 |
團隊的產品相關程式碼是生產級的,其所有最新工作至少每天傳遞到生產等效環境中。 |
團隊的業務代表可以隨意發布(或以其他方式啟用)團隊的最新工作。 |
團隊應要求向其業務代表提供有用的發布預測範圍。 |
團隊與其業務利害關係人協調,以一種可以讓他們以低成本無限期維護其程式碼和其他人工製品的方式開發其程式碼和其他人工製品。 |
有效地作為一個團隊工作 |
程式設計師認為程式碼和類似人工製品屬於團隊,而不是個人,他們共同承擔變更和改善它的責任。 |
設計、開發、出貨、監控、維護等團隊工作產品所需的所有日常技能,團隊都可以立即取得。 |
追求技術卓越 |
在使用程式碼和類似人工製品時,團隊成員會將其技術品質至少稍微提升到比他們發現時更好的程度。 |
生產發布是自動化的,手動工作不超過十分鐘。 |
團隊製作生產級程式碼,無需手動測試階段。 |
所有團隊成員都意識到他們的專業和技術技能如何影響他們達成團隊目標和降低維護成本的能力。他們積極尋求改善這些技能。 |
投資/價值權衡:培養團隊成員的技能直到流暢需要時間和大量的努力。提供流暢通常在專注流暢後 3-24 個月出現,具體取決於團隊收到的指導量和其程式碼庫中的技術負債量。具有大量技術負債的大型系統可能需要更長的時間。
培訓課程可以介紹提供流暢所需的觀念,但學生通常難以將課程範例轉化回他們現實世界中的問題。在許多情況下,流暢還需要聘請熟練的從業人員教練與團隊合作處理其現實世界專案。此外,當團隊學習新技能並償還現有程式碼中的技術負債時,生產力通常會下降。
常見的組織投資
在團隊成員學習新技能時提供降低生產力的時間。 |
將非程式設計技術領域(例如 QA 和運作)整合到團隊中。 |
提供敏捷技術實務的培訓。 |
聘請熟練的從業人員教練指導團隊進行現實世界的作業。 |
儘管有成本,提供流暢的好處是顯著的。流暢的團隊會產生極低缺陷的軟體,並將技術負債降至最低,這表示他們有更多時間提供功能。需要時間才能償還現有的技術負債並讓好處顯現,但一旦發生,你會看到更快的開發時間、更高品質的軟體和大幅改善的回應能力。
「最佳化」團隊領導他們的市場
摘要 | 敏捷的承諾 |
好處 | 價值更高的交付和更好的產品決策。 |
投資 | 將業務決策和專業知識轉移到團隊中所耗費的社會資本。 |
學習自 | 精實軟體開發、精實創業、超越預算 |
時間 | +1-5 年 |
流暢的最佳化團隊了解他們的市場需求、你的業務需求以及如何滿足這些需求。或者,就像在創業環境中,他們知道他們需要學習什麼以及如何學習。與提供團隊相反,最佳化團隊不僅有能力提供給市場,他們也知道什麼要提供給市場。
最佳化:團隊了解他們的市場需求、你的業務需求以及如何滿足這些需求。
大多數敏捷方法旨在幫助團隊達到專注或提供流暢。若要獲得最佳化區域的流暢,請從提供基礎(例如 Scrum + XP + DevOps、看板 + XP + DevOps 或僅為 XP + DevOps)開始,並在該基礎上分層產品中心技術。
精實創業和精實軟體開發(儘管名稱相似,但它們是不同的方法)都是不錯的起點。經理將受益於熟悉超越預算。從那裡,準備尋找並嘗試以產品為重點的敏捷技術。有用的主題包括客戶探索、持續產品探索、設計思考、故事對應和適應性規劃。
精通最佳化的團隊了解他們的市場。他們知道他們為何要建構某項事物,而不僅僅是他們要建構什麼。至少,與精通最佳化團隊的對話將清楚說明他們的產品在市場中的定位。團隊將定義自己的指標(或其他進度指標),他們將能夠為這些選擇辯護,並且他們將有計畫改善他們的市場地位。
如果團隊不具備這種對其產品和市場的了解,或者如果他們產生的價值低於其機會成本,則他們尚未精通最佳化。作為推論,精通最佳化的團隊將與領導階層協調,取消或調整低價值產品和計畫。
預期的利益
透明度 | |
核心指標 | 團隊描述其產品在市場中的定位以及他們將如何改善其定位。 |
降低風險 | 團隊與領導階層協調,提早取消或調整低價值專案。 |
成就 | |
提高投資報酬率 | 團隊交付符合業務目標和市場需求的產品。 |
提高投資報酬率 | 團隊從市場回饋中學習,以預測客戶需求並創造新的商機。 |
提高投資報酬率 | 團隊具備廣泛的專業知識,可促進最佳成本/價值決策。 |
協調一致 | |
提高生產力 | 團隊的廣泛專業知識消除了交接,並加快了決策制定。 |
提高生產力 | 團隊與其組織之間的相互信任導致快速、有效的協商。 |
最佳化流暢度最大的挑戰之一是讓團隊真正控制其產品方向。最佳化團隊和交付團隊之間的區別在於,在憲章的約束下,最佳化團隊自行決定要資助什麼以及將精力集中在哪裡。經理需要將此權力委派給團隊,這通常是組織難以改變的地方。
最佳化團隊和交付團隊之間的區別在於,最佳化團隊自行決定要資助什麼以及將精力集中在哪裡。
當然,為了擁有這些決策,團隊需要有洞察力才能做出正確的決策…或至少知道哪些實驗將幫助他們找出正確的決策。獲得該專業知識通常涉及將非開發人員納入全職團隊成員。常見的範例包括產品經理、業務分析師和主題專家,但也可以包括行銷、銷售或客戶支援人員。
這些結構性變更需要組織的高層許可。這可能很難獲得。儘管您可能很想聘請新員工來填補職缺,但通常更有效的方法是納入已經了解您業務的獨特優先事項和約束的員工。
開發人員和 QA 人員,尤其是公司資歷較深者,可以成為出人意料地有用的產品專業知識來源。當您尋找人員為您的團隊帶來業務專業知識時,不要忽視訓練資深技術人員所需的業務技能的可能性。銷售拜訪和客戶拜訪是提供新觀點的好方法。
區域專長
回應業務需求 |
團隊根據與管理階層共同確定的業務指標成果描述其計畫和進度。 |
團隊適當地與內部和外部利害關係人合作,以確定何時以及是否發布預測具有最佳投資報酬率。 |
作為一個值得信賴的自主團隊工作 |
團隊與管理階層協調,以了解和完善他們在實現業務策略中所扮演的角色。 |
團隊共同承擔責任,並接受實現他們與管理階層確定的業務成果的責任。 |
管理階層賦予團隊自主實現其業務成果所需的資源和權限。 |
管理階層確保團隊了解其市場並實現其業務成果所需的所有日常技能都體現在全職團隊成員中。 |
追求產品卓越 |
團隊與其客戶和市場互動,以了解產品需求和機會。 |
團隊對業務機會提出假設並進行實驗以測試它們。 |
團隊以一種方式計畫和開發其工作,使他們能夠在不到一個月的通知下完全更改計畫,而不會浪費。 |
投資/價值權衡:賦予團隊決策權和相應的專業知識會對現有的組織結構構成挑戰。這可能需要幾年的時間,這不是因為所需的技能,而是因為經理和組織領導者必須學會信任他們的團隊使用敏捷理念,然後才能做出影響他們的權力、控制和熟悉的工作方式的改變。
投資於這些變革需要了解積極的政治技能和對回報價值的深刻信念。倡導者需要花費他們的社會資本才能實現這一目標。經理可能需要指導來支援高績效敏捷環境,在這種環境中,他們的職務從戰術決策制定轉變為定義團隊方向和協調跨組織協調。
常見的組織投資
將團隊 100% 投入特定產品或市場。 |
納入商業和主題專家作為全職團隊成員。不要假設一個人就足夠了。 |
賦予團隊對其預算、計畫和成果的責任;根據成果而非對計畫的遵守程度來評斷他們。 |
讓經理能夠並期望他們在組織中協作,以消除團隊績效的障礙。 |
指導經理了解高績效、自我組織的敏捷團隊如何改變管理工作的性質。 |
最佳化流暢度可減少溝通成本、消除官僚交接,並能快速回應變動的商業環境。其投資會破壞現狀,因此並不適合每個組織。但是,對於那些希望引領其市場變革步伐的組織而言,投資最佳化流暢度值得考慮。
「強化」團隊讓他們的組織更強大
摘要 | 敏捷的未來 |
好處 | 跨團隊學習和更好的組織決策。 |
投資 | 開發管理組織的新方法所需的時間和風險。 |
學習自 | 組織設計和複雜性理論 |
時間 | 未知 |
最佳化團隊具備了解和滿足其市場需求的能力,強化團隊在組織中也扮演了更重要的角色。
強化:團隊了解自己在較大的組織系統中的角色,並積極努力讓該系統更成功。
強化團隊以三種方式為其組織做出貢獻。首先,他們了解自己是較大系統的一部分。他們了解自己的目的如何與其他團隊一致,以達成更宏偉的策略。他們積極努力讓該策略更成功。
其次,他們有意在組織中傳播專業知識。他們尋找機會將自己的技能貢獻給其他團隊,並尋求機會向其他團隊學習。
第三,組織在團隊間分配方向性決策。領導者設計出深思熟慮的結構,以提煉團隊的集體見解,並將這些見解引導至組織改善。
我們在世界各地的組織中看到強化方法的曙光。Valve Software、Semco、Zappos 和 AppFolio 等公司正在這個領域中進行實驗。我們也看到團隊自我選擇和開放空間策略會議等尖端技術在領先的敏捷團隊中獲得關注。話雖如此,這個區域仍處於推測階段。我們認為這可能是敏捷的未來,但我們不知道它確切的樣貌。
儘管我們不完全確定這個區域將採取什麼形式,但我們已經看到足夠的範例來得出關於流暢團隊可以提供的優點的結論。
預期的利益
透明度 | |
核心指標 | 團隊在業務其他計畫的背景下描述其工作,讓產品可以相互平衡。 |
降低風險 | 團隊提出並協助解決跨組織瓶頸和問題。 |
成就 | |
提高投資報酬率 | 團隊參與多團隊活動,以最佳化組織價值流程。 |
提高生產力 | 團隊認知到他們何時可以貢獻到其他團隊的工作,以及何時該工作更為重要,並將他們的努力重新導向以協助他們。 |
協調一致 | |
提高生產力 | 團隊與其他團隊和組織的其他部分交叉傳播觀點、背景、學習和創新。 |
此區域最適合領導者想要處於管理理論與實務尖端的組織。它需要在組織理論的領先領域工作,並發明新的方式將其應用於敏捷團隊。
如果此區域適合您,請研究複雜性理論,例如 Cynefin 和人類系統動力學,以及組織設計的新想法,包括開放空間敏捷性、社會階層制和全息階層制等替代治理結構。
即使您不希望在此區域流暢,此空間中開發的一些技術也值得考慮。就像流暢的交付團隊將具備一些最佳化技術的熟練度一樣,您可以從強化技術中受益。我們直接體驗過的兩種技術是團隊自選和策略性開放空間會議。兩者都值得試行。
對於大多數組織而言,強化流暢度可能最好先遠觀,至少在最佳化流暢度觸手可及之前。然而,對於已經強調精實原則和系統思考、傾向於將決策權分配給團隊,並且重視有遠見的方法和創新流程的小型組織而言,強化區域提供了一個大膽的挑戰和一個有趣的難題。
應用敏捷流暢模型
正如喬治·博克斯所說:「所有模型都是錯誤的,但有些模型是有用的。」敏捷流暢度模型是現實世界的一個簡化視圖。儘管有簡化,我們發現它準確反映了大多數組織的需求。即使它不是完美的匹配,我們所描述的好處、熟練度和投資都是有用的對話主題。
您可以通過三種方式應用此模型:首先,使用它來了解您的組織需要進行哪些敏捷投資。投資不足不僅會導致進度緩慢,還會造成持久的犬儒主義和怨恨。我們見過太多這樣的失敗案例。使用此模型來確保您的期望和投資保持一致。
投資不足不僅會導致進度緩慢,還會造成持久的犬儒主義和怨恨。
其次,如果您沒有看到您預期的流暢度,該模型可以幫助找出問題所在。進行診斷以找出團隊遇到困難的熟練度,然後提供培訓和支援。(敏捷流暢度專案在 agilefluency.org 提供診斷選項。)如果多個團隊在相同的熟練度方面遇到問題,問題可能是系統性的,因此請考慮組織變更。
最後,該模型是調整有關敏捷方法對話的有用方式。關於敏捷思想的討論很容易陷入對具體方法、工具和實務的爭論。相反,使用該模型來促進對人們想要實現什麼以及他們將如何實現的討論。
敏捷流暢度模型圖表 可供您調整 以用於您的簡報。您還可以分享這篇文章以建立有關團隊熟練度和組織需求的對話。對於衍生作品,例如重新發布熟練度清單,請與我們聯繫以取得許可。
如果你需要協助套用模型或診斷流暢性挑戰,敏捷流暢專案有聯絡人和額外資源。請造訪 agilefluency.org 以取得更多資訊。
結論
在我們與敏捷團隊和組織合作的過程中,我們發現團隊在了解敏捷方法及其組織獲得的益處時,會遵循典型的進程。我們將此進程分為四個流暢性區域。每個區域的特徵在於獨特的益處和不同的採用挑戰。
-
第一個區域,專注,要求團隊學習如何共同合作,專注於創造商業價值,而非僅完成技術任務。作為回報,組織對團隊的工作有更深入的了解,並有更多機會以正面的方式影響該工作。此區域反映敏捷基本原則。
-
第二個區域,交付,要求團隊投資學習廣泛的軟體開發技能。此區域反映敏捷永續性。這些技能並不容易獲得,但隨著時間和適當的組織支援,團隊將具備建立和發布低缺陷軟體的能力,頻率高到市場可以接受,這為組織創造了新的機會,以獲得軟體開發投資的回報。
-
第三個區域,最佳化,代表敏捷的承諾:一個團隊隨著市場狀況的變化而調整和轉變,並共同承擔責任,打造您的投資所能購買的最佳產品。在此區域達到流暢性表示商業專家必須加入團隊成為全職貢獻者,而組織結構的這種改變可能具有挑戰性,但它會因團隊服務您業務的能力提升而獲得回報。
-
第四個區域,強化,代表敏捷的未來。強化團隊與其他團隊合作,以改善整個組織。達到此區域需要創新思維和願意嘗試。
所有這些區域都提供益處,每個區域都是某些團隊的正確區域。使用模型激發對話,了解您的組織希望支援哪些區域。一旦您選擇了區域,請考慮達到流暢性所需的投資,並全力承諾進行這些投資。
團隊需要時間來培養其能力。他們會斷斷續續地發展,向前和向後移動,並達到停滯期。從一開始就盡可能多地練習能力。流暢性區域代表自然停滯期,您會看到明顯的益處和需要克服的挑戰。
請注意,組織背景可能會阻礙流暢性。密切注意以相同方式影響多個團隊的系統性問題。這通常表示需要進行組織變革。
我們已經見識過團隊一次又一次地經歷這些流暢區域。透過與您分享我們的經驗,我們希望您能更深入地了解敏捷方法的可能性,以及更了解它們帶來的挑戰。願您和您的團隊取得越來越高的流暢度,以及越來越大的成功。
區域 | 好處 | 投資 | 學習自 | 達到流暢度所需時間 |
---|---|---|---|---|
專注 | 更深入了解團隊的工作;能夠重新導向。 | 團隊發展和工作流程設計。 | Scrum、看板、非技術性的 XP | 2-6 個月 |
交付 | 低缺陷和高生產力。 | 在技術技能發展期間生產力下降。 | 極限編程、DevOps 運動 | +3-24 個月 |
最佳化 | 價值更高的交付和更好的產品決策。 | 將業務決策和專業知識轉移到團隊中所耗費的社會資本。 | 精實軟體開發、精實創業、超越預算 | +1-5 年 |
強化 | 跨團隊學習和更好的組織決策。 | 開發管理組織的新方法所需的時間和風險。 | 組織設計和複雜性理論 | 未知 |
本文的版權為 2012-2018 James Shore 和 Diana Larsen 所有。保留所有權利。
腳註
1: 敏捷流暢度是 James Shore 和 Diana Larsen 的商標。(我們曾遇到其他人使用「敏捷流暢度」一詞,卻錯誤地陳述我們的模型,因此我們覺得有必要註冊商標以防止這種情況發生。)
進一步資訊
- Diana Larsen 敘述了一個 十分鐘的敏捷流暢度模型概觀。
- James Shore 在 NDC 2013 上關於敏捷流暢度的 演講影片。
- Diana Larsen 解釋了 為什麼敏捷流暢度模型不是一個成熟度模型。
- Martin Fowler 關於 敏捷精髓和流暢度 的演講影片,總結了敏捷開發和流暢度模型的基本要素。
致謝
作者感謝 Arlo Belshee、Lisa Crispin、Jutta Eckstein、Martin Fowler、Steve Holyer、Ron Jeffries、David Lokietz、Mary Poppendieck、Justin Redd、Linda Rising、Nancy VanSchooenderwoert、Rebecca Wirfs-Brock 和 Woody Zuill,感謝他們對本文 2012 年版的早期草稿提出的周到評論。他們也感謝 Ellen Gottesdiener、Jakob Wolman、Jutta Eckstein、Lisa Crispin、Martin Fowler、Matteo Vaccari 和 Ramakrishnan Sitaramnan,感謝他們對本文 2018 年版的早期草稿提出的周到評論。
重大修訂
2018 年 3 月 6 日:實質性更新,增加了效益、專長和投資。
2012 年 8 月 8 日:首次發布於 martinfowler.com