所在位置:首頁 -- 項目管理 -- 正文

如何在分布式團隊實現敏捷


發布時間:2017-4-1  來源:admin

 本文要點

介紹分布式敏捷框架

了解如何在分布式團隊中管理文化

了解如何在企業中組織分布式工作

分布式敏捷組織的實際案例

實現更好的分布式組織的問題、品德和實踐

現如今許多組織都有分布式團隊。由于公司是全球性的,現代化的通信手段可以讓人們不拘泥于在“辦公室”工作,許多新的勞動力選擇游民化工作。分布式團隊成為高績效的團隊是非常可能的,只是需要付出更多努力來克服距離帶來的內在挑戰。

這篇文章是系列文章《分布式敏捷:如何與分布在全球的團隊合作》的第一篇,這一系列的文章對文化差異給分布式團隊帶來的影響進行了探討。你可以通過訂閱RSS接收通知。

在過去的十年內,我一直在學習如何以一種有成效的方法管理分布式團隊。2004年我去了印度,并深深愛上了這個國家。我決定創辦自己的公司,我想要為荷蘭公司提供外包服務(我來自于荷蘭)。二十一世紀早期的主流業務是美國公司外包業務給印度。但是在歐洲,只有少數先驅在嘗試提供外包服務。我在印度拜訪的時候,IT產業在印度的巨大能量讓我感到很驚訝。我也發現,作為荷蘭人想要和來自文化差異如此巨大的地方的人一起工作會是很大的挑戰。從簡單的開始,我決定先和烏克蘭的團隊進行合作。但我的夢想一直以來沒有改變:我想回到印度創辦我自己的公司,讓它運作起來。

尋夢之路艱辛,我為自己所做的錯誤決定付出了昂貴的代價。在2005年的時候還沒有scrum和敏捷(雖然已經出現了scrum和敏捷方法,但還沒有很多公司開始使用,我那個時候也不知道這個方法)。我們遵循于固定的日期、固定的價格、傳統的項目管理和基于瀑布模型的開發的方式。我覺得如果能請阿姆斯特丹的項目經理和當地的客戶合作并管理烏克蘭的團隊,那一切都會更好,當然我當時沒有這么做。之后看來,我的經驗法則是基于瀑布模型的項目有80%的概率是項目一切正常(可能會有小的延遲),而有10%的概率是雖然完成了項目,但付出了很多額外的工作。讓人頭痛的是剩下的10%概率,要順利完成項目,必須把所有技術高超的人員集中在一起才能成功。所有事情都和預期有偏離(不僅僅是針對你,也針對你的客戶)。

在之后的階段,我開始嘗試讓專門的團隊負責產品工作,而不是項目工作。由于你可以創建跨地點、跨組織的“一個團隊”,一切變得更好。你可以使用敏捷和scrum來管理合作。根據我過去幾年的積極經驗,我寫了一系列有關管理遠程團隊的書籍。書是由全球的從業者一起撰寫的,他們把自己的實際經歷寫進了書里,但我覺得我們產業需要更多的例子。

現在有很多敏捷框架,顯然最受歡迎的是scrum,規模化框架也受到了更多的關注。許多框架告訴我們在同一個地點工作是最好的,我也非常認同。但是不幸的是,很多公司不能這樣運作。為了填補這個空缺,給人們提供能管理分布式團隊的框架,我和其他三個人一起開始開發分布式敏捷框架,他們分別是:John Okoro、Savita Pahuja和Arjan Franzen。

我們還在初始階段。我們認為把這個框架的大部分內容開源出來是有必要的,所以我們四個臭皮匠希望早期階段的成果能夠得到社區的反饋。我們開發的框架包括八個“板塊”:

1.文化

2.組織

3.產品

4.團隊

5.架構

6.工程實踐

7.溝通

8.工具

每個板塊都有三個元素:

A、問題:組織可以用來評估當前狀態的一系列問題

B、品德:促進分布式合作的行為

C、實踐:已經完成的工作,由從業者進行分享的內容

根據我們的經驗,這八個板塊是可以推動分布式工作更加流暢的助燃劑。這是持續改進的循環。根據公司的規模和復雜性以及分布式組織的成熟度的不同,每個板塊產生的影響也不同。如果想要確定痛點,確定需要關注哪個板塊,我們的框架提供了一系列擴展的問題。然后我們定義了每個板塊能實現的品德,這些品德幫助創建“分布式敏捷文化”,即一系列行為準則。許多人就會問“那我們之后該怎么辦?”。我們的實踐幫助回答了這個問題,每個環境都是獨一無二的,能從幫助到別人的實踐中學習是解決特定的分布式挑戰的最佳方案。

我們框架的共同貢獻者John Okoro和我將詳細介紹兩個板塊:文化和組織。在文章之后的內容中,我們也會更詳細地描述其他的板塊。文章將作為InfoQ迷你書發布。

我們也期待得到讀者的意見和反饋。如上所述,開源模型是分布式敏捷框架的根本。框架是以精益和敏捷原則為基礎的。

文化

擁有來自不同文化背景的成員的分布式團隊不可避免地面臨著合作的挑戰。文化有不同層次(國家、地區、公司、團隊)。在我們的模型中,文化指的是國家層面的文化。組織和團隊會在單獨的板塊中討論。要理解文化差異的影響并找到組織它們的方法,可以使用以下的一系列問題:

我們是否經歷著文化差異的影響?

我們有“我們和他們的差異”這樣的規范嗎?

我們如何處理差異?

我們要如何讓差異顯現?

如果文化開放,人們心意相通,那將多么舒適!

在同一地點工作和分布式工作文化差異的影響是什么?

我們的組織中有多少階層?

各個文化是如何看待階層差異的?

我們期望能做到哪種程度的“自組織”?

要怎么做才能實現每個人都達到相同“自組織”的水平?

語言的不同會造成多大的影響?

每個人對說“不”都有相同的理解嗎?

一些例子。大多數國家在管理家庭、社會、公司的方面等級階層都各不相同。在一些亞洲國家,等級階層非常重要。人們習慣于“聽命”于父親、老師和老板,因此“積極性”水平普遍比較低,沒有人提出對權威的質疑和對上司的質疑。而在美國和歐洲,大多數國家崇尚“平等”的文化。比如說在荷蘭,我們鼓勵人們質疑假設,并提出自己的想法,想法來自于組織中哪個階層的人并不重要。Hofstede的模型稱其為“權力距離”,某種復雜的度量系統對國家進行分級。從這個簡單的描述,你可以看出印度(77)和印度尼西亞(78)分數很高,而荷蘭(37)和美國(40)分數較低。

另一個例子是開放程度。作為荷蘭人,如果我對你的行為有疑問,我會直接告訴你我的想法。我相信通過分享我的想法,我們可以一起找方法來解決。但是在亞洲社會里,人們并不習慣這樣。他們更愿意編造故事,迂回地討論他們的擔憂,但不直截了當地解決問題。作為荷蘭人,我可能不會理解亞洲人給我的信息,因為我已經習慣了沒有經過加工的、最真實的信息。這樣做會造成關系的緊張與合作的壓力。

上周,Hugo在印度尼西亞的日惹組織了會面。我們討論的主題之一就是開放程度,因為它是scrum的價值之一。Hugo也和約二十五名印度尼西亞人進行小組會談討論。就和其他小組一樣,也有些人很善談。討論開放程度話題的人各有不同:有的很害羞,不喜歡說話(不這么開放);有的很習慣說英語,而有的不是(所以他們看起來不這么開放,但如果他們用自己的語言,他們就可能會表現得“比較開放”);有些人在團隊中角色比較微妙,所以他們覺得自己不方便很隨心所欲地發言。Hugo已經非常習慣了(在印度的時候他也有相同的經歷,他和來自不同文化的人一起工作了超過十年)。但是當沒有經驗的荷蘭人(非常善談,非常直接的人)要和印度尼西亞的工程師一起合作,這就會帶來挑戰。

我們定義了五種有助于縮小文化差異的品德:

同理心:接受差異,“充滿”同理心

開放程度:討論文化差異的影響

認知度:認識到差異

對人的信任比過程更重要

透明度

有同理心的人更喜歡設身處地為他人著想。他們可以完全代入他人的生活,理解他或她的信念、理論和參考標準。他們也更喜歡接受人與人之間的差異,他們喜歡多樣性,他們笑納多樣性,他們從不拒絕多樣性的存在。有同理心的人可以促進分布式合作。這就是說如果團隊中有一些有同理心的人是非常有幫助的。舉個例子,團隊中需要有同理心的角色是scrum master。

開放程度受到擔憂、缺乏信息、延遲、被“困住”的影響。組織文化越開放,人們合作起來越簡單,人們對文化差異、團隊“狀態”和工作進展的意識也越強。大多數的知識工作都是需要創造力的,并不適合按部就班的過程。成功也取決于參與其中的人,如果有相互信任的人,管理文化差異也會變得更簡單。工具可以幫助他們自組織差異,但過程并不能。

透明度能幫助人們檢查并適應。當把項目的信息和進展與所有人分享,那誤解就會減少。當我知道承諾的進展時,我就不需要尋求特定某人的意見(這是文化上主觀的)。有了工具的支持,針對特定的用戶故事展開討論,及時獲得準確的信息也變得更容易。

在上面小組討論的例子中,我覺得自己是有同理心的。作為促進者,我了解小組中每個人開放程度不同,我尊重每個人。這很好。我想要變得開放,而不是遲鈍。我也相信每個人都盡力做到最好,一些人雖然沒有說話,但吸收了討論內容,有些人很開放地分享自己觀點,主導著討論。我盡力讓每個人參與到談話中來,但我也發現自己需要學習印度尼西亞語才能更有效地主導這樣的討論。這個組是臨時成立的,如果我要和他們在真實項目中合作,我就要花費更多時間安排好小組內方方面面的問題。

組織

隨著技術推動著全球化合作的發展,企業也變得越來越分布。人們開始在家工作,項目團隊也分布在不同地點。要跨地點協調工作,敏捷原則起到了幫助的作用。團隊成員和利益相關者的互動很頻繁,并基于模式互動。利益相關者、用戶或客戶和開發團隊緊密合作。組織根據scrum框架創造角色、事件和工件。但決定要在什么位置放什么角色,協調不同時區的人完成工作并不容易。不在同一個辦公室工作給保持工作一致性帶來了挑戰,也不一定能看到每個團隊(成員)的表現。以下是在組織層次可以提出的問題:

問題

我們采用什么開發框架?(scrum、LeSS、Kanban、SAFe等等)

怎么調整框架,適應我們的分布式團隊設置?

角色:把什么角色放在哪里?(比如說代理產品負責人)

事件:我們組織的事件有什么不同?(比如說,如果時區不一樣,可以使用視頻進行記錄)

工具:什么工具可以支持分布式框架?(選擇JIRA還是sticky board)

我們創造分布的團隊(每個人都是遠程或是分布的團隊)還是在同一地點工作的團隊?

我們如何衡量成功?我們的kpi是什么?

如何在所有團隊成員之間有效地分享知識?

我們如何分享產品視角、路線圖和用戶反饋?

如果我們要合作,怎么在戰略、戰術和運作層面保持一致?

對于分布的敏捷團隊來說,最主要的挑戰之一是如何利用好產品負責人和利益相關者。團隊常常茫然無措,因為他們不知道做什么。負責產品的人是每個組織里最忙碌的一批人。他們需要均衡用于開發團隊、利益相關者和管理之間的時間。他們通常會屬于多個產品團隊。與產品負責人一起工作的團隊有更多的機會可以和他們互動,但是遠程團隊就沒有這個機會了。此外,遠程團隊幾乎不能與他們的軟件產品的用戶對話。他們不能了解產品視角、路線圖和相關的計劃。因此,他們與自己創造的產品之間沒有“情感聯系”,這也會影響動力和質量。組織需要思考關鍵角色的分布,以及開發團隊與用戶和利益相關者聯系的方法。我們還要思考如何在分布式組織中分享知識和產品信息。

要創建有成效的分布式組織,以下列出的品德可以有所幫助。

品德

敏捷性:對模型抱著開放的態度,避免官僚主義

自組織:讓團隊自己發現問題

在同一地點工作的團隊更方便

和利益相關者直接聯系:避免中間人(產品負責人應該促進團隊和用戶之間的交流,而不是當兩者之間的傳話筒,不要團隊領導,不要等級階層)

維基是關鍵,選擇正確的工具分享知識、視角和反饋

在不同地點的跨職能團隊

在不同地點調整敏捷轉換視角

Kaizen(持續改善)代替Kaikaku(突破性改善)

將這些品德用于上面提到的“茫然無措”的例子:我們可以使用敏捷原則來組織。我們將權力交給團隊,而不是建立嚴格的規則和報告系統。通過回顧,團隊可以發現阻礙他們的問題。授權的、自組織的團隊可以公開地將這些阻塞與產品負責人和利益相關者溝通。有了優秀的產品負責人和迭代改進,團隊可以找到分享產品信息、路線圖和用戶反饋的方法。

業務團隊的人和開發者每天合作,這可以避免產品負責人成為中間人的問題。使用視頻會議軟件或在同一地點工作,開發人員可以和用戶以及利益相關者溝通。如果組織鼓勵團隊使用像維基一樣的工具是有所幫助的。免費提供這些產品,分享產品視角、路線圖和相關文件就變得更容易。

另外一個值得關注的分布式敏捷組織領域是不要做得太多太快。用日語來說就是Kaikaku,突破性改變。這就是說徹底改變你的團隊,改變團隊職務和角色,以適應敏捷框架。這會導致你的團隊感覺到改變起來很疲憊,團隊也不能有效工作,他們陷入“形成”和“動蕩”的循環之中(團隊通常會經歷形成、動蕩、規范和運行的循環階段,建議盡可能實現規范和運行狀態)。

舉個最近的案例,John熟悉的一家大銀行嘗試采納敏捷方法,在各個地方使用Kaikaku方法。給所有的經理賦予敏捷教練的職位(盡管他們對敏捷沒什么了解),并一下子做出巨大的改變。盡管銀行一開始覺得用Scrum方法工作取得了很大的進展,但大概18個月之前,組織和團隊突然前進不動了,陷入了改變疲憊期。之后改變的進展越來越少,阻力越來越大,迫使銀行停下激進改變的腳步。此后銀行采用了更加健康的Kaizen方式。根據John所知,對于這家銀行來說,這個方法更加可行,并持續到了現在。

推薦使用kaizen(持續改進)方式進行改變,而不是改變組織中每個人的角色和職位,做出小的增量改變,改善你的分布式敏捷團隊。你的團隊也會喜歡這種方式,這種方式對人很尊重(這也是“Lean Thinking House”兩大支柱之一)。作為普遍的經驗法則,Kaikaku方法和革命性變更在新的組織和初創公司中更能發揮效用,因為這些組織或公司不存在或僅有少量的“包袱”需要處理。

總結

當所有人在一起工作時,分布式組織面臨的挑戰就不會出現。可能在一起工作時也會碰到一些挑戰,但影響力大大縮小。我們的框架將主要挑戰分為八個板塊。我們討論了當人們和團隊遠程工作的時候,“文化”和“組織”中發生了什么。為了幫助人們評估他們的組織,我們在每個板塊中也設置了一系列問題。在之后的文章中,我們將分享其他六個板塊。我們非常愿意收到你對框架、問題和品德的反饋。

中国比特币暴涨 上海时时十一选五 赛车pk10违法吗 青海快三走势图免费下载 北京赛车pk走势分析 天津快乐十分走势图技巧 幸运飞艇历史开奖图 福彩3d摇奖机下载 排列五走势图带线 牛彩网首页 2019年六仺彩开奖结果05期 pk10计划人工在线计划 58w北京麻将 欢乐赛车彩票软件 白小姐开奖结果开 安徽快3冷号遗漏查询 云南时时开奖结果