之前曾經寫過一篇我們公司專案使用敏捷開發的案例，當時我們在預期的時間讓 MVP 的產品能夠上線，讓敏捷開發的價值得底被證明。不過這一次我想從另一個同樣是跑敏捷開發卻跑的不盡理想的專案中，重新探究敏捷開發的價值。
專案的背景是與國外企業的 RD 部門將部分的產品委外給我們開發，產品的規劃、設計由他們主導，我們只要負責好開發的部分，聽起來是非常單純的委外開發。但短短的半年期間，雙方經歷過多次的調整，才終於催生出產品進到使用者測試的階段。
溝通的高牆
敏捷開發宣言裡提到：個人與互動重於流程與工具
在最剛開始接下這專案時，負責管理我們的是客戶公司（以下簡稱Ａ社）的 Tech Lead 以及負責這個產品的 Product Manager、Product Owner，我們與其他 RD 的溝通幾乎是零。
我們走我們的 Scrum，他們走他們的 Scrum，只有 Tech Lead 和 PM 知道雙方在做什麼。
這樣延伸出來的主要問題是功能開發的速度會變的緩慢。
在一個有打算做跨部門的組織裡，要讓這件事情得以實現，我想還是需要讓對於同一功能再進行開發的相關人員有能夠溝通的管道，不然的話兩個團隊各做各的狀況其實還是一種 waterfall 的流程，只是裝上了敏捷開發流程的殼。
當時為了解決這個問題，Ａ社的新 CTO 在剛上任時找了我們幾位同事到他們公司一起共事幾天，和他們一起每日站立會議，確實與他們的工程師面對面的溝通時，許多之前需要等待很長時間回應的狀況就馬上等到解決，但由於我們終究不是駐點的團隊，這一次的面對面溝通只是暫時化解當時正在開發功能上的一些問題，並沒有真正解決之前溝通的高牆。
小小的調整，讓問題提早被發現
舉例來說我們當時遇到的狀況是開發功能的流程是固定的，功能設計與圖完稿後才會進到功能開發，我們沒有機會可以對設計圖上問題提出改善建議，必須要照圖開發，直到一個不正確的功能被開發完成後再重新由 Product Manager 開新需求進行調整，理想上這雖然是一個完整程序，但開發者及設計師就會面臨一種時常在打掉重練的挫敗感，對產品而言則是不停地在累積技術債。
後來，針對上面提到的情境我們做了一點溝通上的調整，使得一些邏輯面上的問題在交付給客戶之前就能得到解決，雖然說交付給客戶之後，有一定的機率客戶會要求修改或調整功能，但至少工程師們在開發過程中就發現的邏輯問題能夠在交付給客戶前就得到討論，減少一些未來開發上所累積的技術債。
不再只有單一對話窗口，多團隊看板開發
除了剛才提到一點流程上的改變，在我們回國後，CTO 下了一個決策，我們從一開始的 Scrum 換成了 Kanban 的管理方式。
過去不同團隊做的事情如果會相互影響到，很難在各自的站立會議中發現，因此非常倚賴 Tech Lead 來同步溝通個團隊的狀況，導致開發速度一直都很緩慢，大家都互相的等來等去，而且還不知道到底等的是誰。
改成看板開發後，以這家公司規模（工程師在20位以內）還可以在同一時間一起開會，主要由 CTO 擔任會議主持人瀏覽看板，因為不同部門的正在負責的票都在同一個看板上，Ａ團隊的票被 B 團隊影響著的狀態就能夠在看板上一目瞭然。
解決了之前不同團隊對於進度瞭解上的高牆。
持續堅持站立會議
站立會議是大家耳熟能詳在 Scrum（敏捷軟體開發過程）中的一部份。
在專案的這段時間內，不論有沒有和客戶那邊一起站立會議，我們自己這邊則是一直都有進行著，我想除了同步彼此的進度狀況，發現專案的問題、進度的問題、技術的問題之外，我另外有個心得是覺得站立會議同時還是一個建立團隊默契及感情滿重要的會議。
這個專案中有過幾次工程師上的人力調整，除了全職的工程師外也有一些 Remote 工程師在我們的團隊當中，透過每日的站立會議，讓新進的工程師或是無法常常面對面對話的 Remote 工程師們都有一段時間和其他團隊成員對話、溝通，能夠幫助他們更快地融入團隊中，這點是我覺得站立會議在敏捷開發中的另一個價值。
在這專案中，客戶有客戶團隊自己的開發腳步，站在外包團隊的角度正好可以觀察到這些事情，更加讓我體會到敏捷開發絕對不是單單只有那些原則、圖表和方法，還會牽扯到組織的文化及管理。我想要做到資深的管理者（或說 Scrum Master）需要有效且精準地找出組織問題的癥結點並加以改善，才能夠讓敏捷開發一直保有他敏捷的優勢，而不是只是流於形式。