Holakrasi vs Team Topologies: Takım Otonomisi Modelleri Karşılaştırması

Liderliğin “takımlara daha çok otonomi veriyoruz” açıklaması her zaman karışık tepkilerle karşılanır, çünkü sınırları olmayan otonomi genelde çözdüğünden çok problem yaratır.

Senaryo tanıdıktır. Matriks proje takımlarından ürün moduna, akışa-hizalanmış takımlara geçiş hız kazanımı üretir; yanında istenmeyen sonuçları da getirir: daha fazla defekt, tekrarlanan çaba, takımların birbirinin ayağına basması.

Burada uygulanabilir varsayılan Team Topologies. Takım tiplerini ve etkileşim modlarını çerçeve olarak alın; sonra Holakrasi’den rol tüzüklerini, Spotify modelinden uygulama topluluklarının dilini ödünç alın. Bağlam değişir; ancak bu birleşim yeniden yapılanmanın deneme-yanılma maliyetini düşürür.

Otonominin Tanımı#

Başarılı otonomi girişimleri genelde şu temelleri doğru yapar:

• Karar hakları: Takım bağımsız olarak neye karar verebilir, nerede girdi veya onay alması gerekir?
• Net domain sahipliği: Bir takım problem alanını uçtan uca sahiplenir: yol haritası, kod, altyapı, on-call ve maliyet. Ortak sahiplik genelde sahipsizlik demek
• İnce, güvenilir arayüzler: Koordinasyon toplantıları yerine versiyonlanmış API’ler, event’ler ve kontratlarla etkileşim.
• Görevlerden ziyade sonuçlar: Takımlar sonuçlara ve SLO’lara taahhüt verir.

Modellerden Nasıl Yararlanılır#

Holakrasi (seçili parçalar)#

• İşe yarayan: Rol tüzükleri (amaç, sorumluluklar, domainler) ve kısa “taktik” toplantılar gerginlikleri hızla yüzeye çıkarır. Sağlanan netlik değerlidir.
• Atlanabilecek: Tam yönetişim törenleri ve anayasa; düzenli sürüm çıkaran takımlar için çok ağırdır.
• Dikkat: Roller hızla çoğalabilir. Canlı rol kataloğu tutun, her ay kullanılmayan rolleri kapatın.

Spotify Modeli (çoğunlukla terminoloji)#

Squad’lar (çapraz fonksiyonel takımlar) ve guild’ler (uygulama toplulukları) geniş kabul görür; chapter’lar yalnızca gerçek bir zanaat standardı koordinasyon gerektirdiğinde değer üretir. Org şemasını olduğu gibi kopyalamak kaynağı yanlış okumaktır: Spotify, “modeli” kendi organizasyonlarının belirli bir andaki anlık görüntüsü olarak tanımlamıştır.

Dikkat: Chapter lead’ler gölge yöneticiye dönüşebilir. Performans yönetimini squad liderinde tutun.

Team Topologies (temel çerçeve)#

Dört takım tipi ve üç etkileşim modu ortak dil sağlar: Stream-aligned, Platform, Enabling ve Complicated-Subsystem takımları; Collaboration, X-as-a-Service ve Facilitating etkileşimleri. İşe yaramasının nedeni Conway Yasası’na karşı durmak yerine onunla uyumlu tasarım yapması ve bağımlılıkları görünür kılması; ters Conway manevrası (mimariyi istenen takım sınırlarına göre şekillendirmek) özellikle güçlüdür.

Platform takımları ürün takımı gibi davranmalı; SLA’ları ve “paved road”u yayınlamalıdır, çünkü bilet kuyrukları ve onay kapıları kazancın çoğunu geri alır.

İşe Yarayan Korumalar#

• Sahiplik haritası: Her domain, servis ve yetenek tam olarak bir takıma atanır.
• SLO ve hata bütçeleri: Takımlar servis güvenilirliğinin sahibi; liderliğin işi bu hata bütçelerini erken optimizasyondan korumak.
• Değişim taksonomisi: Geri döndürülebilir değişiklikler etkilenen takımlardan tavsiye gerektirir; geri döndürülemez olanlar açık onay gerektirir. Jeff Bezos’un “tek yön vs iki yön kapı” kavramı org tasarımına uyarlanabilir.
• Karar kayıtları (ADR): Hafif, aranabilir; PR’lara linkli.
• Paved road: CI, deploy, gözlemlenebilirlik, kimlik vb. için görüş sahibi varsayılanlar. Olgunluk seviyeleri ve kaldırma takvimi yayınlayın.
• Etkileşim kontratları: Her çapraz bağımlılık için hedef etkileşim modu ve beklentiler yazılı.
• Metrikler: DORA (lead time, deploy sıklığı, MTTR, değişim hata oranı), takım sağlığı, platform NPS.

Geçiş Planı (12-24 Hafta)#

1. Değer akışlarını haritalayın, 3-5 akışa-hizalanmış aday takım ilan edin; sahip oldukları sonuçları isimlendirin. Her takımın net bir müşterisi ve başarı kriteri olsun.
2. Mevcut bağımlılık grafiğini çizin; bekleme, yeniden iş, belirsiz sahiplik sıcak noktalarını işaretleyin. Bu harita genelde ilk “oh” anını yaratır.
3. Etkileşim modlarını tanımlayın; “toplantıyla koordinasyon”u öldürün. Her bağımlılık için Collaboration, X-as-a-Service veya Facilitating kararı verin.
4. Bir enabling takım kurun (8-12 hafta) test, gözlemlenebilirlik ve trunk-based development koçluğu için. Bu ekip kalıcı değil; sonunda squad’lara dağılır.
5. Platform = ürün: CI/CD, logging, auth, deney için golden path RFC yayınlayın. Opinionated varsayılanlar sunun; takımlar yolu bilmeli.
6. Servis sınırları: Repoları ve runtime sahipliğini takımlara hizalayın. Kod, on-call ve bütçeyi eş konumlayın.
7. Kadans: Haftalık taktik (squad), iki haftada bir guild, aylık mimari forum, üç aylık iş gözden geçirme.
8. Ölçün: DORA + incident + merge süresi baz çizgisi; 6/12/24. haftalarda tekrar ölçün.

Otonominin Kırılma Noktaları#

Bu pattern’ler iyi niyetli otonomi çabalarını sabote eder:

• Otonomi tiyatrosu: Takımlar backlog’a “sahip” ama aslında deploy edemiyor, kadro alamıyor veya roadmap’i etkileyemiyor.
• Platform polisi: Paved road yerine sert onay kapıları; yaratıcı engineer’lar genelde bu kapıları atlatacak bir yol bulur.
• Gölge yönetim: Chapter’lar veya guild’ler hiyerarşiyi geri getirir ve hızlandırması gereken kararları yavaşlatır.
• Matriks yayılması: Çift raporlama yapıları belirsiz karar hakları yaratır; değer akışı başına tek iplikli lider daha iyi çalışır.
• Araç > sonuç: Karar hakları veya sınırlar değişmeden yeni törenler ve araçlar eklenir.

Kullanıma Hazır Şablonlar#

Takım Tüzüğü (kopyala-yapıştır)#

• Amaç: Takım neden var? Müşteri kim?
• Sonuçlar (12 ay): 3-5 ölçülebilir sonuç ve öncül göstergeler.
• Kapsam & sınırlar: Neler dahil/dahil değil? Hangi servisler ve domainler?
• Karar hakları: Tek başımıza neye karar veririz? Ne öneri/onay ister?
• Arayüzler: Sahiplendiğimiz API/event’ler; SLA/SLO’lar.
• İşletim modeli: Kadans, on-call, incident, release süreci.
• Metrikler: DORA, SLO, müşteri memnuniyeti, maliyet sınırları (ör. $/1000 istek).

Etkileşim Modu Kontrol Listesi#

• Collaboration: Süre kutulu mu? Çıkış kriterleri net mi? Tek sahip var mı?
• X-as-a-Service: SLO’lar yayınlı mı? Runbook? Backlog girişi ve görünürlük?
• Facilitating: Koçluk hedefleri, yetenek transfer planı, bitiş tarihi?

Hafif Karar Akışı#

• Küçük, geri döndürülebilir: Takım karar verir; ADR yazar.
• Çapraz takım, geri döndürülebilir: Etkilenen sahiplerden tavsiye al; gerekçeli itiraz yoksa ilerle.
• Geri döndürülemez/yüksek etki: Sahip liderlerden onay; risk ve geri alma planı yazılı.

Destekleyici Araçlar#

• ADR repo + şablonlar ve arama. Kararlar aranabilir, PR’lara linkli kalır.
• Paved road skor kartları takım bazında. Olgunluk seviyeleri ve kaldırma takvimleri.
• Golden path iskeletleri (gözlemlenebilirlik ve auth gömülü). Yeni servisler doğru varsayılanlarla başlar.
• Org bağımlılık haritası wiki’de; üç ayda bir gözden geçirme. Bekleme ve belirsiz sahiplik sıcak noktaları görünür olur.

Otonominin Sınırları#

Bazı durumlar daha fazla yapı ister. Ürün/pazar uyumu hâlâ belirsizken sıkı hizalama ve az sayıda takım, dağıtık sahiplikten iyi sonuç verir; hedef sürekli kayar ve her ek sınır yeniden pazarlık edilecek bir madde demektir. Güvenlik açısından kritik ve düzenlemeye tabi alanlarda hızdan feragat pahasına onay süreçleri ve izlenebilirlik gerekir. Çok küçük organizasyonlarda (15 mühendisin altı) güçlü varsayılanlar ve net sahiplik tek başına yeter; formel takım topolojileri çoğunlukla tören ekler.

Nereden Başlamalı#

Önce değer akışlarını ve sahipliği haritalayın, sonra paved road’u yayınlayın; yapıyı ise ancak DORA ve incident verisi bir şey söylediğinde değiştirin.

Kaynaklar#

• Team Topologies - Resmi Kitap Sayfası (yeni sekmede açılır) - Skelton ve Pais; dört ekip türü ile üç etkileşim modunun kaynağı.
• Holacracy - Öz-Yönetim İşletim Sistemi (yeni sekmede açılır) - HolacracyOne’ın resmi sitesi; Brian Robertson’ın rol tüzüğü ve rıza yönetişimi modeli.
• Spotify Mühendislik Kültürü Bölüm 1 - Henrik Kniberg (yeni sekmede açılır) - Takım, kabile, bölüm ve lonca kavramlarını tanıtan 2014 tarihli özgün Spotify yazısı.
• DORA Accelerate State of DevOps Report 2024 (yeni sekmede açılır) - DORA metriklerinin araştırma temeli: öncü süre, dağıtım sıklığı, MTTR ve değişiklik hata oranı.
• Conway Yasası - Melvin Conway (1968) (yeni sekmede açılır) - Özgün formülasyon; Ters Conway Manevrası doğrudan bu makaleden türemiştir.
• Martin Fowler - Conway Yasası (bliki) (yeni sekmede açılır) - Conway Yasası ve Ters Conway Manevrası’nın mikro servisler ve ekip tasarımı bağlamında pratik açıklaması.
• Drive - Daniel Pink (yeni sekmede açılır) - Otonomi, ustalık ve amaç çerçevesi; ekip özerkliğinin neden önemli olduğunun motivasyonel temeli.