顯示具有 software developmemt 標籤的文章。 顯示所有文章
顯示具有 software developmemt 標籤的文章。 顯示所有文章

3/14/2021

如何用教練(coaching)的方式引導團隊成員



作為主管,帶領引導團隊朝組織期待的方向前進有很多種方式。其中,「教練式引導」針對特定團隊成員行為改善的其中一種方式。

主管對於團隊成員的引導方式大概有四大方向:教練coaching, 導師mentoring, 領導leading 與管理management。在軟體團隊中,領導與管理是主管一定會做的,而教練coach與導師mentor就會視團隊的實際情況而定。

管理management:簡單的說,是直接或間接以組織所賦予的權力,以具體的方法,要求成員達到結果或者某種行為。舉例來說:「某甲,明天早上十點請到會議室去和某乙討論某專案」就是個具體的管理作為

領導leading:簡單的說,以自己的行為加上組織賦予的權利,以身作則的達到團隊合作的結果。舉例來說:「某甲,我明天早上十點會到會議室去和某乙討論專案,一起和我去吧」

導師mentor:一般來說是比較有經驗的成員,在執行自身的任務的時候,順便分享給相對沒經驗的成員。也許會回答問題,也可能教導做法,或者也分享經驗。通常由主管指派資深成員做mentor,但主管也有可能自己作為mentor角色。導師通常會比學生更厲害或更有實質經驗

教練coaching:以「口說」或者「間接」的方式,激勵或指引成員達到具體的結果。這具體的結果,幾乎100%是有成員直接完成。教練不一定比學生更厲害或更有實質經驗,但通常會更有「口說教學」經驗。例如在世界排名頂尖的職業網球選手,都有雇用教練陪伴指引戰術與練球,但那些教練過去甚至不見得是職業網球選手。

角色區分有時候並不那麼重要。例如管理與領導常常是混合進行,而在軟體團隊中mentoring coaching 當然也常混用。更常發生的例子是,主管指派一個導師mentor給新進同仁時,實際上常常混合了leading/mentoring/coaching。混合並不是壞事情,但如果資深同事,可以透過區別自己的角色,進而使用不同的工具達到目的,那效果會更好!


這篇文章僅只專注於教練式引導。



教練式引導的基本方式: GROW

最最基本的教練式引導模型是Grow,它有四個循環的階段:

GROW: Goal, Reality, Options, Will (what)

目標Goal:

教練和學生要決定一個具體的目標。這個目標可以是組織需要的目標,也可以是學生個人的目標。目標必須是可清楚辨別結果的。例如,網球選手想在四大公開賽進入前四強。在學生剛加入團隊時,可能會訂出目標是「了解現在的系統」,這其實並非清楚可辨別的結果,教練應該和學生花時間,討論具體的結果,例如「根據現在bug清單,修好一個bug並送出Pull Request之後通過團隊所有其他成員的code review並且合併到master branch」。雖然一次可以訂多個目標,但建議還是少量目標為主。

現況Reality:

教練和學生列出和具體目標相關的現況。例如網球選手此時世界排名是200,過去平均多久打一次正式比賽,平均練習時間等等。

以軟體開發團隊來說,現況可能是剛剛加入團隊,才剛剛有git的權限,過去的文件還沒看完,對某些專業領域還不了解,還不知道哪些問題應該問哪些人等等。

現況的描述是相當私人化,對於某些人來說可能還先牽涉到部分自我敏感的資訊,尤其是自己弱點。在還沒有互信的時候,此階段執行要特別謹慎。


執行選項options

了解現況之後,教練就要和學生討論選擇做法。這些做法當然是「學生」要去做的。以網球教練為例,可能會建立心肺功能的健身菜單,也可能會安排練習賽,也可能會為了強化發球。通常可執行的選項會多過可用的時間。當然就要和學生討論哪些選項應該要做,那些不做。

軟體開發團隊也會設定這些選項,但更著重要選項的優先順序,也就是哪些要先做,那些之後再做。

意願will/what:

監控執行,特別是監控執行意願。一個剛加入團隊的新鮮人,初期在意願上通常不是太大問題。如果已經在社會打滾多年,因為換工作的關係加入一個新團隊,作為教練或主管,就要稍微留意一下是否有意願或者動機的喪失。

這GROW是個循環,教練不見得一定要告訴學生這個模型,如果可以說明清楚是最好。根據實際情況,循環的長度會有不同,可是軟體開發團隊中的教練應該盡量控制在1~2週之間,切勿太長。


教練的功能

GROW模型優點是相當簡單,容易理解。缺點是教練實質功能在這個模型比較隱晦。在執行此模型時,也可參考以下重要功能:

建立互信

建立互信是教練最最重要的功能,沒有互信的情況下,很難達到教練完全的功能。

軟體開發工作上的互信應該會比運動型的教練容易一些,只要執行以下三點:(a)自己保持清楚明確的溝通 (b)永遠花時間跟確保完整傾聽對方 (c) 固定時間回饋  通常就能有一定的互信

因材施教

在軟體開發團隊中,教練vs學生,通常是一對一。而每個學生的情況截然不同,因材施教是顯而易見要達到的。因材施教在非技術的領域比較難,最好的方式可能還是縮短GROW的循環時間,如此可以在短的時間修正互相之間的不了解。


建立安全網

運動類型的教練都有其專業能力,可以判斷目前學生是要突破肌耐力極限,還是快要受傷應該休息。甚至某些運動項目,例如體操,就還真的有實際上的"安全網",因為受重大傷害絕對不會對目標有幫助。

就軟體開發團隊來說,安全網其實很重要,但相當隱晦。例如對於相對沒有工作經驗的人,教練應該在「現況討論」時,列出更細節的項目,例如估計時間的時候要估計完整的時間,包含unit test跟撰寫文件的時間。這些實質細節項目,其實會讓新鮮人更清楚並且有信心的做事。

安全網也有可能是透過工具,先行體驗犯錯,而減少日後在真實情況下犯錯的機會。例如,即便團隊沒有要求,教練也可以和學生討論使用某些靜態程式碼工具,在送出PR review先自己找看看有沒有顯而易見的問題。

建立安全網在某些時候是個極為重要的任務。一個教練要謹記,教練成功的原因,是因為學生成功了!不會有一種學生失敗了但是教練成功了的情況。因此安全網是個避免災難式失敗的保險方式。


鼓勵人心

真誠的鼓勵其實對大家都有幫助。尤其是在完成目標之後。因此目標的設定,最好是許多短期目標構成長期目標。舉例來說,如果網球選手的目標是進入四大賽的前四強,但目前世界排名還200,短期目標可能是先在最近的幾次三級比賽獲得冠軍。

軟體專案的目標甚至可以是逐日設定,所以鼓勵也可以逐日發生。所以當教練必然要花一些時間陪著學生。

時間分配

軟體團隊身兼教練的人,通常不會和運動類型的教練一樣是全職的工作。每個人在團隊都應該要有產出,兼職的教練也不例外,所以時間分配在學生的身上恐怕要特別注意。

最基本是要和主管討論時間分配。如果要不影響工作進度,一般的原則,每天15~20分鐘,再加上偶爾中午一起吃飯的時間就應該是上限。

這裡的15~20分鐘,指的當然是學生和教練一起執行檢討GROW模型的時間,並不包含假設教練身兼導師一起和學生工作的情況。

尋找外援

以有世界排名網球選手來說,年紀稍長的教練幾乎不可能跟他打練習賽,所以教練可能會透過自己的人脈(例如同個經紀公司)找到同等級的職業選手來打友誼賽。而更厲害的教練可以說服更高一級的選手來和自己的選手練習。

就軟體開發團隊來說,教練有可能比學生在專業領域還要厲害很多。然而也有可能由於教練資歷太深,反而對最近幾年的新的開發工具並不了解,教練也可以直接安排其他成員專門對某工具對學生直接教學。


其他教練模型

市面還是有很多不同的教練課程與書籍闡述不同的工具和模型。可以參考這裏 





9/08/2019

如何指派工作 (成為主管的31堂課)


作為團隊領導者,自然會遇到任務分配,指派工作任務的情況。軟體開發團隊也不例外,雖然敏捷式開發方式中的Scrum方法論,是希望在每個Sprint中採取「自己認領」工作,但其實極少有團隊可以完全做到這點。

指派工作任務最完美狀況是:團隊成員對主管有100%的信任,同時對組織中短期目標也有深切體會;並且都有完整的技術能力可以達成任務;而且所有人對於專案與時間管理都有經驗;而更重要的是,每個人都士氣高昂,迫不及待地完成任務。很遺憾的是,這種情況幾乎不會存在,好的軟體主管必然認知到的是,自己的任務必然是在於讓團隊成長前進,往好的地方邁進,而非期待自己「已經處於」一個完美的團隊。

如果你是個軟體團隊的主管,常常在夜深人靜時自己抱怨自己的環境與團隊,並且自認為委屈,那麼你就是屬於「期待自己已經處於完美團隊的主管」,這通常不會是讓事情變好的心態。

指派工作的方式看似很多,但重點只有幾個:

(一) 指定清楚的目標


指定清楚目標表面上很簡單,但主管自己其實需要考慮是這件事的真正目標,和指定任務的項目。

舉例來說,如果軟體主管指定任務目標為:「A工程師,請把某個AWS的一組VM,從micro升級到xlarge。」這看似清楚目標,但升級機器,必然不是目標,升級機器要達到的結果才有可能是目標,更有可能的是結果後的結果才是目標。

例如,稍微清楚描述目標:「A工程師,我剛收到通知明天由於行銷活動,我們網站流量應該會暴增,為了讓我們能處理高流量,請把某個AWS的一組VM,從micro升級到xlarge。」

但是,更好的方式其實是,清楚目標先指定,然後再討論出來。例如:「A工程師,我剛收到通知明天由於行銷活動,我們網站流量應該會暴增,為了讓我們能處理高流量,我們在AWS上的各種VM和使用的服務,有需要做哪些改變呢?」

當然,目標本身一定要涵蓋作法/行動。沒有具體行動的目標也沒有意義。

(二) 時間視為最重要衡量方式


時間是衡量所有事情的最重要的方式,在清楚指定或者討論目標作法之後,所有的行動必須以時間為衡量方式。而時間除了長度,還有實際完成時間。

例如:「A工程師,根據我們剛才討論結果,我們需要升級所有120個VM,這需要2小時,並且是在後天早上10:30am之前完成」

(三) 寫下來!


指派工作的另一個重點在於,所有任務指派一定要文字化或者圖形化,即便是很簡單的瑣碎小任務,也應該用一張紙寫下來。現在專案管理工具其實很多,例如JIRA。當然也可以用它來指定所有任務。


12/24/2017

沒有QA?如何確保軟體開發品質



任何軟體專案或產品,達到高品質是開發團隊必然的目標。不過高品質並非垂手可得,它需要團隊的共識和努力才能達成。

確保品質有很多方式。過去常見的方式是瀑布式開發方式(waterfall)中,在程式設計師確定code complete之後,靠QA/QT/QC(註1)來執行測試,並且在測試週期中,驗證是否符合設計規格,並記錄追蹤問題(bug),有時候甚且扮演催促修復的角色。因而,特別是大型團隊,專門「處理」品質的QA角色十分重要。很多時候,團隊可能面臨沒有QA的狀態,此時要如何確保品質呢?

為什麼會沒有QA


有時候,環境造就沒有QA的局面。例如,新創公司可能也只有5個人,無法有專責QA。又例如,大型企業中因資源分配不均,導致某些專案無法有專責QA。

但更多時候,沒有QA指的是,沒有能做「真正QA工作」的人。也許團隊裡面有許多人持有QA的職稱。但很可能僅做到QC/QT的工作(註1)。實務上,在軟體開發團隊中,實際做的事情其實比職稱來的重要。就品質的角度而言,QA大部分的時間應該花在開發循環「前期」或者「中期」。以Scrum中的Sprint來說,在kick-off時,QA應該花最多時間在定義DOD,決定產出的評斷標準,在sprint每天活動中,QA應該花時間在檢視產生的程式碼(code review)並且透過每個工作產出,主動改善現有品質。換言之,QA應該比單純的程式設計師,更會程式,更知道系統的交互作用細節,並能透過直接或間接修改程式,直接影響開發過程中的品質。因為,開發前中期的品質修正,效果好,成本低,遠比開發「後期」再來幾個測試循環來的有效!

簡要的說,能真正做QA工作的人,必須能比程式設計師團隊更會寫程式。起碼也要是「曾經」非常會寫程式。

如果團隊不巧沒有這樣的人,有三種方式可以在沒有QA的情況下確保軟體開發的品質:

方式一:Scrum

Scrum方法論中,概念上每個Scrum成員都是「同樣質量」。換言之,Scrum進行中重視的是產出,每個SPRINT的結果是「可交付的東西」。而Sprint中間要完成的細項,應該將品質涵蓋入內,而由自行取得該任務的人,完成其保證。

有許多作法和上面這段熬口的說明有關。首先,DOD (definition of done) 除了涵蓋unit-test之外,其實應該也涵蓋整合測試。如果不涵蓋整合測試,就應該另外有一個任務是專做測試。並且,每個story完成中,必定涵蓋這個story應該要有的使用測試(用以檢驗規格)以及回歸測試(用以檢驗是否有副作用)。這些測試,可以單獨成為一個工作,也可以作為DOD的一部分。

無論如何,基本概念是:「人人應該都可以生產程式碼,當然人人應該都可以測試」。實際執行時,或許有些人比較常「拿到」測試工作,但這並不代表這些成員就只是進行測試而已。有些人比較常拿到「寫程式性質」的工作,但並不代表這些人不負責品質。

Scrum的團隊重視每個Sprint的共同結果,此結構也讓沒有QA也能達到高品質。因此Sprint的長度不能太長,太長就會落入「團隊中自行區分QA和Engineer」的後果。


方式二:Pair Programming


Pair Programming是指兩個人一起用一台電腦,一個鍵盤來共同寫程式。這作法在2000年左右發展的Extreme Programming被大大推崇,不過能有決心推動的團隊並不常見。

由於Pair Programming讓每段程式碼至少都會被兩個人看過,而且在頭腦中想過。它可以避免大部分的低級錯誤(拼錯字),也可以避免懶人錯誤(程式風格,漏寫unit-test),然而,更重要的是它讓兩個程式設計師的真實想法,在執行同件事情的時候被「好好溝通」。而這更大幅避免對設計或需求的誤解。

Pair Programming似乎有效率和產能上的疑慮,但無論如何,它確實是在沒有QA的情況下,確保開發品質的絕妙方式。強烈建議閱讀一下wiki上的Pair Programming最下面的參考論文。



注意!

前兩個方式雖然符合敏捷開發的精神,並且能從系統結構層面,解決問題。然而,這兩種方式都必須要有結構性的改變,除非是剛剛成立的新團隊,要造成結構性的改變很困難,而且,即便做的好,也得花上其他心血才能有「能見度」,有能見度,才有所謂的功勞。

有兩個古時候的例子:

(a) 鶡冠子扁鵲:扁鵲曰「長兄最善,中兄次之,扁鵲最為下。」魏文侯曰:「可得聞邪?」扁鵲曰:「長兄於病視神,未有形而除之,故名不出於家。中兄治病,其在毫毛,故名不出於閭。若扁鵲者,鑱血脈,投毒藥,副肌膚,閒而名出聞於諸侯。」

(b) 孫子兵法:故善戰者之勝也,無智名,無勇功,故其戰勝不忒。

然而,對於一個軟體專案的主管而言,這些結構性的改變才是自己真正的價值。即便價值很難被衡量,但價值會永遠存在自己的手上。

如果短時間難以改變環境,可以考慮以下的方法三:

方式三:Part-time & Automation


工讀生(part-time student)和自動化測試(automation)似乎是兩個不同主題,但就確保軟體開發品質而言,把他們當做「一件事情」來處理,會有驚人的效果。

簡單的說,就是雇用3至4個優秀的工讀生,每週上班2-3天,組成工讀生團隊,執行測試任務,並且在熟練測試任務之後,開始進行測試自動化撰寫,並且在小組長(team leader)帶領下視情況參與更多品質管理的事情。這聽起來是個繁複的事情,但執行起來,遠比方法一二簡單。



其步驟如下:

(a) 選定一位以後想要朝專案經理或主管方向前進的優秀資深工程師,讓他作為工讀生團隊小組長

(b) 到各大學相關科系徵求大四以上的長期工讀生,一般來說,只要能妥善說明對他們未來就業的好處,通常可以找到足夠優秀的人。工讀生至少需要在職6個月以上。

(c) 組成團隊後,第一個月僅只需要熟悉目前軟體系統,第二個月才開始讓他們執行測試計畫,回報並記錄問題

(d) 在此過程中,由小組長指定測試內容和範圍,換言之,這段期間,其實小組長才是扮演QA的角色。而其他成員都可以將繁瑣的測試交給工讀生。然而,程式的品質仍然是所有成員負責,工讀生不在Scrum的範圍內,因此不「負擔責任」。

(e) 當測試進行2個以上SPRINT,工讀生應該已經開始覺得測試是很煩人的事情,但也應該知道品質對產品的重要性。這和在學校做專案計畫有天壤之別。因此,就可以開始由小組長領導工讀生進行測試自動化。

(f) 測試自動化並不期望把所有整合測試/回歸測試,100%統統自動化。只要把「簡單瑣碎」的測試自動化,通常就能節省一半以上的時間

(g) 通常六個月後,3-4人的工讀生團隊就能完成部分整合測試,和大部分的回歸測試。而下一輪的新工讀生,可以選擇從頭開始打造新的測試自動化,也可以接手前期工讀生做到一半的自動化。打造新的自動化通常可以用新的工具,新的角度來測試既存系統,可以讓品質在一次提高。接手前期工讀生的自動化,可以讓自動化範圍更廣,空出時間來做其他的事情


工讀生進行自動化測試的開發,對組織,對小組長,對工讀生有三贏的效果。(參考:實習生的三贏)

組織:讓沒有QA的團隊,能確保高品質的產出。除了要花些微的工讀費用之外,讓團隊成員能把瑣碎的事情下放給優秀的工讀生,使團隊成員能集中心力,但又同時負責個人生產的品質。同時,由於利用工讀生來培養小組長,讓組織能了解這個資深工程師,適不適合作為領導者,萬一不適合,頂多也是犧牲工讀生而已。

小組長:沒有人生下來就會當主管,當主管必須要有經驗,而工讀生團隊是主管最容易讓資深工程師測試自我的地方。因此小組長可透過這獨立運作的團隊,練習各種管理技能。

工讀生:大部分優秀的大四以上學生,都猜得到業界和學界的差異。許多人可能會在暑假應徵summer intern,然而其實短短兩個月,通常會做比較獨立的專案,雖然都很有趣,但是和在學校有很大的不同。加入實際開發團隊,即便只是做測試,也能了解「現實和學校」的差距,並且體會到軟體專案開發時,品質的重要性。讓有此六個月經驗的工讀生,更容易在未來找到更好的工作。





註1:關於Quality Control, Quality Test, Quality Assurance, test engineer, SQA的各種工作角色的區分,請參見wiki。然而,誠如前所述,工作角色名字不重要,做出事情才重要。

12/09/2017

How to build a self-motivated software developer team


A team which all team members are self-motivated is a dream team where everybody want to join in. But, it is really rare. Well, maybe the 1992 dream team was one of the cases but we didn't see many examples in software developer's world.

Nevertheless, to build a self-motivated team is a major task of a manager. If you are the manager, this should be your priority-zero task, and should be only one zero, if you are going to build a new team.

Self-motivated might be the best way to drive software engineer's performance. Since high productive engineer works high involved in creativities and mental work.  These are hardly be gain or impacted by salary or physical award (reference: 1, 2, 3). Sometimes it could be driven by a noble target: save all poor children in the world, increase average human life to 200 years. But unfortunately, that kind of things normally happens in non-profit organization with a born charismatic leader. 

So how to build a self-motivated software developer team in a common working place?

Three key points: (1) selection (2) intersection (3) automation.

(1) Selection

If a member who is already a self-motivated person, then it will be easy to keep his good attitude. Since it is pretty hard to change a person's mindset, therefore to get a right person is the most easy way.

Do select a person who already has record on self-motivation. DON'T select a person who has good skill-set but has bad records on self-motivation and you believe you can change his/her mindset, I won't say it is possible but you need to understand that you really have much less changes. Since you can't be with the person 7x24 and his mindset is only inside his brain.

The key point of selection is try to understand his past. Do not judge his "self-motivation" by ask future question like: will you be self-motivated in our team? Understand his past working experience by asking the difficult moment. Especially, sometime he might not be in spotlight and what he did on that moment.

Again, identify a person's past is the best way to select right attitude candidates. And a best fitting person can really have positive impact for the team. 


(2) Intersection

There is no way to read team member's mind. People have left-hand-column, even if you already selected best people to join your team and you were very sure they all are honest. But they surly have things which can't tell or won't tell.




Some leaders or managers will try to dig it out, it is fine to do but not that easy. The best way is to admit the existence. And then leaders should focus on the intersection which is the area that covers the target of a single team member, the team and the organization. And that is also the area where creates win-win-win.

A self-motived member could find that area by himself. But if you are leader/manager, you should keep in mind that figure out the area and knowing the area is very different in each individual. To fine tune a bit earlier can largely reduce the risk of un-motivated situation.

For example, "Ken" is always in good performance and deliver pretty good result. And you believe that you knew that his career interesting is pure technical area. Which means he might want to be an architect in the future. However, if you see he is pretty happy to lead junior members to work out teamwork activities, for example : organize a study group, handle company travel, or year end party. That might be a sign of that he is actually want to be a manager in the future. If his actions is toward his goal then it is fine. However, if his actions didn't reflect your assumption, then it is your time to reset yourself or/and make a little changes.

The bottom line is to avoid lose-lose-lose situation. This sounds funny and should not even considered to happen. But there are too many true sad stories existed in the world. An usual/typical sample in software developer's world was: a team (which members are well-pay) worked over-time on an ambiguous project for months, delivered a product which didn't fit PM's expectation, company lose money, members lose life, customer didn't get result: no body wins.

To avoid 3-lose situation, make sure there is an intersection of all. If you were the manager, make sure you can guide your members into his own intersection. But if you really see that there is NO intersection at all, make sure to create one.



(3) Autopilot

Autopilot means a member knows exactly what to do, how to do. And most important thing is if there are tasks out of his current skill set, he will know how to learn. He can even do self-consideration of intersection and selection. Totally worry-free.

Again, if the selection was done good, to let team member become autopilot will be easy. All you need to do is coaching. Coaching is another topic of a few books plus lots of trainings/experience. If you are an experienced leader/manager then you already know how to do, just reminder to keep open your mind. And also please keep in your mind that open-your-mind is never easy.

The bottom line is to avoid micro-management.  Software development is highly brain consuming job. Micro-management never works in software development, it does work in other kind of job but it definitely doesn't work in software development. If you need to talk to your member about when to arrive in office, when to leave, what to update in Slack, how to write email. That means you are NOT trying to build self-motivated team or this specific person won't fit in a self-motivated team.



Sorry, No short-cut

There is no short-cut in for organization theory. However, practically do the right things normally will get the positive result in a few months. Of course, sometimes in a rapid startup environment, it seems no time to wait. But most of us in software developer world are running marathon not a sprint.


Skill sets and performance concerns:


There is one more thing. I didn't discuss skill sets and performance here. But this is actually extremely critical for a software developer's team. Without an excellent skill sets and performance delivery the self-motivated will be useless. However, this "should" be not difficult to identify during interview and resume check.



12/05/2017

Scrum: Feature-boxing of Sprints







In certain scenario, a scrum project could allow different length of Sprints and still satisfies Timeboxing principle. It benefits an involving software product of build MVP, increase integration quality and make members even more focus.



Time-boxing is one of fundamental practices in Scrum methodology. Most of actions in scrum are time-boxed. It makes sure the project keep going and also lets members focus on current task.

Time-boxing is one of the cure of Parkinson's Law of Triviality for all kind of meeting. No matter it is Sprint kick-off or daily standup. I believe it should apply to not only project management but also other area of organization, as long as the timeframe is a consensus of members. 

You can easily find the definition or discussion of how important time-boxing (or timebox) is in google. For example: this one or this one.

Timeboxing in Sprint


A Sprint in scrum also apply to time-boxing. Normally it means when project kick-off, all scrum members will decide how long is a Sprint. The recommended length is 4 weeks in software development. After that all Sprint will be in 4 weeks, no matter how many stories have done or what changes happened between Sprints. That also means if a project is in Sprint-11, 40 weeks was gone. 

A fixed timebox sprint make process happens. But is it necessary to keep the same length of Sprint?

Still timeboxing but flexible in next Sprint



Timeboxing is still critical and should be applied in the moment before event start. Sometimes, we should not fix timeframe in project kick-off and keep for next 40 weeks or more.

In fact, every Sprint kick-off meeting should also discuss a timeframe of this specific Sprint.

Image a sprint-kick-off meeting. Everybody: Product Owner, Scrum Master, Scrum Members were together in this Sprint kick-off meeting, discuss stories and story-points. If PO select 3 stories: P1, P2 and P3 which needs 2 weeks, 1 weeks, 3 weeks. What team should do? The general practice should be keep P1 and P2 in this Sprint and also select a few lower priority task to fill up that one left week. However, there are a few drawbacks in this situation. Firstly, remember Parkinson's Law? members might extends the time for not select lower priority tasks which sometimes is not a bad idea. But secondly, if a scrum team keep doing select a lower priority to fill up time slot, it make the "priority" not "priority" any more. 

If all members have consensus of flexible Sprint length, they can easily setup next Sprint to 3 weeks. And that Sprint will done  P1+P2. Or with Product Owner's agreement, they can setup next Sprint to 6 weeks to complete all P1~P3. 

In some scenario, the most beautiful way should be keep P1 in next sprint only. And this Sprint will be just 2 weeks. 


Make MVP possible

Why do one story at one Sprint is a beautiful way? Well, in some scenario, we need to make MVP(Minimum Viable Product)...and keep make MVP for a while to identify market and make sure minimum waste. Unfortunately, no body can foresee the future. A quick/early delivery is the reason why MVP is useful and also the reason why it is good to stick a single story delivery in a single Sprint. To achieve that, we need flexibility in different Sprint.

The key person of MVP is Product Owner (PO). And to make MVP possible, the bottom line of scrum is to have PO's real participant. In reality, it is very very hard to PO to focus on what he needs to do. A single story delivery forces PO to make a decision of the real priority of backlogs. Since the team will really delivery a things in every Sprint and of course PO should then put the thing in the market. PO can't say: well, it is too early to go for market. Since this is his priority one! Priority one should go for market right away! 


Why Quality improved?


Very simple, each Sprint with only one story has its own QA process and due to the complexity of change is short. we can easily fix integration issue or new defeat much quicker than a sprint with more than one story.

Agile: Feel comfortable to Adopt reality


An agile team should be comfortable to adopt changes and those changes should reflect to reality. But should still keep the critical concept. There is always a way to enjoy both without compromise to an uneasy method. 

To be flexible in Sprint length doesn't mean to break Timeboxing. But it does break some rule from the regular Scrum training. Nevertheless, process is continuously improving is the bottom and spirit of Agile. Scrum master or organization leader should take responsibility to make sure the process could be tailored after retrospective.

Case Study


As developer manager of a enterprise software product, I modify a bit of product release method to make sure PO's backlog is a real priority to reflect market needs. 

The result is since 2016/July to 2017/Mar (8 Month), we delivery 5 releases. The longest Sprint is 8 weeks and the shortest Sprint is 2 weeks. We actually complete 5 major stories and achieve following technical result.

(1) Quality: no side effect in these 5 release. Compare to previous fix Sprint length model much lower technical defeat in beta.

(2) Productivity: averagely, more code conduct per engineer compare to previous fix Sprint length model. However, at the same period of time, we enjoy more team building activity then before and very very very few overtime.

(3) Motivation: engineer could see the result (no matter good or bad) few weeks after delivery. Previous fix Sprint length model needs 3 to 9 months to know if our works really matters.

If you'd like to know more detail, please drop me email.