相對於今年，滿多其他 IT 部門也都陸陸續續導入敏捷，大家在互動合作上，往往可以站在比較相同的頻率上對話
回到當初只有我們自己導入時，可所謂風風雨雨
每個人/部門的穀倉都是蓋好蓋滿

在這邊先解釋一下穀倉效應
就是各人自掃門前雪(誤)
是指說彼此鮮少往來，也不願與其他單位分享資訊
在我的理解下，很容易造成經驗無法傳承。
舉例來說 有相近類型的開發功能，可能結果都做得出來，但因為沒有傳承導致重工，錯失市場良機導致
另外一個常見的穀倉效應的案例也就是 Sony 案例，隨著公司規模業務的拓展很廣，官僚體系的根深蒂固，掌權者擁有權限與資訊，導致隔閡與流程繁瑣，漸漸的被市場淘汰。

之於人

在團隊內我們透過了敏捷的經常對話特性
有效的解決了人跟人之間的穀倉效應
當中花了很大的心力在打破咎責的觀念
讓大家能夠更誠實的互助與把心力用在解決問題
對事不對人～把事情做對做好，不咎責的團隊文化

至於部門間

這部分真的就是一大雷點，不過也慶幸我的專案已經是跟公司內部 IT 最無掛鉤的了。
但在過程當中也是有遇到不少需要跨部門溝通的機會。
最早遇到的困難就是，我們接到了使用者需求需要跨部門合作，
但因為開發方式的不同，往往常常互相等待。

後來我們的作法則是
1.跨部門的需求，預計工時與完成時間要拉長一點、多一點 buffer(不要幻想能夠在同一個 sprint 處理完畢)
2.需要雙方主管參加的會議，盡量邀請。利用壓力來辦事(不健康，但有效)
3.在 review 時邀請協作單位一起來參加，展示進度與讓 stakeholder 的反饋也能傳達到不同開發部門
4.在 retro 時討論這次與其他部門合作時遇到的難點與障礙，下次該如何避免。

持續的調整，才能提高風險耐受度

下行上效，不是簡單的事情
但持續做對的事情，會讓持續進步的公司看到。

先改變自己，才能影響他人。

參考資料：
cc0圖庫
穀倉效應