大型科技公司如何以產品而非Scrum方式執行科技專案？ - Gergely

• 有能力、自主的人需要較少的結構來產生可靠、高質量的輸出。大型科技公司能夠吸引、負擔和僱用這些人。
• 透過給予他們選擇如何運作的自由來利用有能力的團隊。對於大多數型別的工程來說都是如此，並且有充分的理由說明為什麼臭鼬工廠的自治模式和減少官僚主義，是許多擁有高素質人才的高績效團隊最終遵循的。

• 開發人員生產力。工程師如何才能花更多時間編寫程式碼來推動團隊目標的實現，而不是陷入基礎架構問題或解決依賴關係的問題？平臺團隊是一種有用的方法，但這裡還有很多東西需要解壓縮。我們將在以後的時事通訊中詳細介紹這方面的內容。
• 償還技術和架構債務。所有大型科技公司都在快速行動並快速響應新機遇。在這樣做時，公司經常走捷徑，導致技術和架構債務。如何以合理的方式償還這筆債務成為日常流程的一部分，而不是進行“大爆炸”的技術債務償還專案？
• 與組織目標相匹配的團隊結構。公司和子組織的目標會定期更改。團隊結構如何反映這些變化，同時最大限度地減少對團隊凝聚力的破壞？
• 為創新和意想不到的工作騰出時間。對於期望創新的團隊，您如何創造空閒時間來實現這一目標？
• 隨著工程團隊的成長跟上步伐。公司擁有的工程師越多，溝通或做出影響大多數工程師的決策所需的開銷就越大。組織規模擴大一倍後，如何保持快速發展？無論組織規模如何，都有哪些流程和結構選擇可以讓團隊保持敏捷和快速行動？
• 經久不衰的卓越。整個組織如何提高其吞吐量，同時工程師也保持快樂，並且改進持續時間足夠長以複合？“持久卓越”一詞來自Will Larson的文章“保持在通往高績效團隊的道路上”。

以產品為中心的環境和放棄 Scrum
Scrum 妨礙了每天的交付。Scrum 的整個想法圍繞著 Sprint，在 sprint 開始時提交任務，在 sprint 期間處理這些任務，並演示我們在最後所做的事情。 
這個過程感覺不自然，就像是強加給一個快速移動的網路團隊一樣。我們很快就轉向了一種更流暢的工作方式，採用了看板方法。我們不再關心 sprint，並且放棄了 Scrum 帶來的大多數儀式。我們只關心知道我們現在在做什麼，以及我們接下來要做什麼。
基礎設施和開發人員工具消除了對許多 Scrum 儀式的需要。Scrum 儀式，比如向產品負責人演示、簽署工作然後交付它，假設了一些事情：

• 產品負責人是可以肯定地按照規範驗證工作的人。
• 產品負責人編寫了規範——因為他們正在驗證它。
• 在簽收完成之前，工作不會被運送到生產中。