我們花了5年左右的時間來構建Braze，沒有太多正式的項目管理方式。我們使用設計文檔、Trello、電子表格、啟發式、最佳實踐和大量會議來完成大量工作。沒有兩個項目是相同的——有些項目是由一個人的團隊運行的，他們把當前的狀態記在腦子裏，而另一些項目則細致地記錄了實際的個人提交。一切都很順利……直到它沒有。
到2018年初，我們開始看到一些明顯的跡象，表明存在一些根本問題:
- 太多的項目同時在飛行。
- 在構建周期的後期有太多的需求變化。
- 其他人在做什麼，透明度太低。
- 花太多時間指導人們如何管理項目和合理分配工作。
這些都是一個相互關聯的重大問題網絡的一部分。目前還不清楚項目的優先級是如何確定的，什麼時候進行，以及預計會建造什麼。問題的核心在於:我們如何工作?是時候從根本上改變我們管理軟件項目的方式了。
製定計劃
經過一些思考，我們決定采用一種工程團隊行之有效的方法——我們決定要做得更多敏捷．
為了應對這個新挑戰，我們想要組建一個小組，代表並利用我們整個產品和工程組織的知識——所以我們成立了一個委員會，由代表產品管理、設計和工程的8名成員組成。我們包括了經理和個人貢獻者，以及具有不同敏捷背景、資曆和經驗的人。
這個敏捷委員會，正如我們所稱的那樣，在處理這種情況時牢牢記住了幾個關鍵原則:
- 我們希望在可能的情況下使用經過驗證的解決方案，包括方法和軟件。要做到獨一無二需要付出很多努力，我們隻想在必要和戰略領域做到獨一無二。我們還希望人們能夠穀歌管理他們工作的最佳實踐，或者更好的是，讓加入Braze的人已經知道如何做。
- 我們希望Braze的產品工程團隊在運作方式上基本一致，因為能夠說同一種語言是很有價值的。
- 我們不想武斷地做任何事情，或者不經過深思熟慮。隻是選擇一種方法，然後照章辦事是不夠的;對我們來說，常識和經過深思熟慮的迭代是很重要的。
有了這些指導方針，我們決定加以利用Scrum，這是一個敏捷框架，已被證明對許多組織有效。眾所周知，它是可伸縮的，而且當您尋求實現敏捷過程時，它是安全的默認選擇。
接下來，我們麵臨著兩個主要的決定:(1)我們應該使用什麼工具來支持我們的新過程，以及(2)我們應該如何將變更推出到我們的過程。我們討論、評估並演示了幾款軟件——最終是Atlassian的軟件Jira對我們來說是正確的選擇。這是一個經過充分驗證的解決方案，我們團隊中的一些人已經有使用它的經驗，Braze中的其他團隊也已經在使用它，這為更好的跨團隊協作提供了機會，因為我們都在一個係統中工作。
在選擇敏捷的推出計劃時，我們有幾個關鍵的決定要做。首先，我們如何培訓團隊?我們可以雇傭一個敏捷教練，讓團隊中有經驗的人來培訓其他人，或者找顧問來幫忙。第二，我們是否應該讓擁有敏捷經驗的工程團隊在實施敏捷之前等待培訓?
最後，我們決定讓那些熟悉Jira和Scrum的團隊在他們覺得力所能及的範圍內開始，並聘請了一名顧問來幫助組織範圍內的過渡。我們不希望讓團隊成員或獨立玩家在過渡期間主要負責指導團隊成員，因為:
- 我們不希望任何單獨的團隊掌握我們如何進行敏捷，我們覺得如果來自第三方，培訓會得到更好的接受，建議也會更有包容性
- 我們認為谘詢業務比個人敏捷教練更穩定、更可靠
- 我們希望對整個工程組織進行基礎培訓，並且在開始時不假設組織中每個成員對敏捷的了解程度
- 最後，我們想讓教練在某個時間點離開，以明確我們組織中的每個人都有責任維持這個過程繼續下去
我們決定使用Scrum，這是一種敏捷框架，已被證明對許多組織有效。眾所周知，它是可伸縮的，而且當您尋求實現敏捷過程時，它是安全的默認選擇。
執行計劃
經過幾個月的計劃，我們有一個大文件這詳細說明了我們打算做的每一件事，我們與整個組織分享反饋。然後，在評估了幾個供應商之後，我們選擇了Eliassen與我們一起踏上敏捷之旅。這段旅程始於Eliassen主持的為期兩天的敏捷培訓，隨後是Eliassen為我們介紹的一位專家進行的為期三個月的敏捷指導。
從一開始，我們對轉移到Jira和Scrum就相當謹慎。互聯網和我們團隊的個人經曆都充滿了關於過度教條主義方法的危險的警示故事，關於Jira如何成為“反模式”的功能，以及Scrum在組織中可能出錯的所有方式。我們谘詢的人再三提醒我們，這些變化可能需要時間，在我們看到敏捷的真正好處之前，可能會有成長的痛苦。
值得慶幸的是，我們立即發現了新流程的價值。這種轉變的一個好處是，我們從來沒有感到盲目遵循Scrum的任何特定方麵的壓力;為了讓事情做得更好，我們每隔幾周就會回顧一下事情的進展，然後修改需要修改的地方。在為期三個月的培訓中，我們在整個工程組織中實施了徹底的變革:
- 每個人都學習了如何編寫、梳理、指出、分解和獲取用戶故事
- 當完成手頭的工作時，站立者找到了新的焦點
- 產品、設計和工程都學會了說同樣的語言，界麵設計也越來越好
結果
現在，我們已經站在了這大約六個月的努力的另一邊，變化很明顯，而且是巨大的。我們已經看到導致這一努力的問題顯著減少。有了敏捷，我們現在就有了清晰易懂的機製，用於簽收、協作、backlog創建和梳理，並且我們定期舉行回顧會議，討論需要改進的地方。
我們還為設計工件提供了明顯更一致的位置，以及更好地一致的期望。”完成對於一個特定的項目來說。看到其他團隊在做什麼變得很容易，人們比以往任何時候都更容易理解如何很好地一起工作。
我在這個過渡的末尾注意到，在任何給定的時間，組織中開放的拉請求的總數都下降了，即使我們正在做更多的工作並擴大我們團隊的規模。通過以較小的增量工作並專注於完成任務，飛行中的項目數量顯著減少。
我們公司的成功也激勵了其他人。我們開始看到Braze其他部門的團隊開始他們自己的敏捷轉換，所以很快更多的人會說同樣的語言，並擁有他們需要的工具來定義和改進協作。
外賣
我們努力的兩個主要因素確保了它的成功。
首先，它是由一個有代表性的委員會推動的，這對於從工程組織和各種不同的角度獲得輸入至關重要。在全公司範圍內，人們在一個會影響他們日常工作的問題上感到被傾聽和代表。隨後創建的一個完整的文檔，列出了敏捷轉換的動機和計劃，可以與團隊共享，這也是非常有用的。我們相信展示決策是如何做出的，並為反饋引入清晰的路徑——因為它提供了背景，並建立了一個提供反饋的工件。
其次，讓第三方來幫助指導我們的團隊是必要的決定。有了一個客觀的、有經驗的合作夥伴，我們能夠快速地對我們的流程進行大量改進。我們的教練知道什麼是好的，並且能夠毫無偏見地提出建議，有很多次我們能夠問，“團隊通常如何做X?”，並找到一個立即可行的解決方案。另一方麵，如果我們使用內部資源，我們就會麵臨這樣的風險:我們收到的反饋來自一個有偏見的一方，並增加了與現有職責的資源爭奪。
