Spotify’nin Squad ekip modeli bir başarısızlıktı
(jeremiahlee.com)"Spotify’nin kendisi bile 'the Spotify model'i kullanmıyor. Siz de kullanmayın."
2012’de ünlenen Spotify’nin "Scaling Agile" whitepaper’ı, onların bir temennisiydi; hiçbir zaman tamamen hayata geçirilmedi.
Whitepaper gerçeklikten farklıydı, ama işe alımda faydalı olduğu için olduğu gibi bırakıldı; yazar da şirketten ayrıldıktan sonra bunu düzeltmek için kayda geçirdi.
Bu modelin nelerinin yanlış olduğu, Spotify’nin hatalarından neler öğrenilebileceği ve başka hangi modellerin önerildiğini ayrıntılı biçimde anlatan bir yazı
Söz konusu whitepaper’ın ortak yazarı ve Spotify’nin Agile koçları da eskiden beri dışarıdakilere bunu taklit etmemelerini söylüyordu.
"Whitepaper’ı yazdığımız dönemde bile biz bunu yapmıyorduk. Bu, kısmi bir hedef ve bir tahminden ibaretti. İnsanlar gerçekte var olmayan bir şeyi zahmetle taklit etmeye çalıştı."
Neden iyi çalışmadı?
- Matris yönetim yanlış problemi çözüyor
Tam kapsamlı çevik ekipler iyi çalışır. Ama matris yapısındaki yönetim daha fazla sorun üretir
→ Spotify’nin ekipleri uzun ömürlü yapılardı; bu yüzden başka bir ekibe geçerken yöneticiyi değiştirmek zorunda olmamanın avantajı çok sınırlıydı
→ Mühendislik yöneticileri yalnızca kariyer gelişimi düzeyinde sorumluluk aldı, kişiler arası çalışma becerileri gibi alanlarda yardımcı olamadı
→ Her ekibin mühendislerinden sorumlu tek bir yönetici yoktu. mini-CEO gibi çalışan ürün yöneticisinin yanında mini-CTO gibi hareket edecek biri yoktu. Yani teknik ekibin desteğinden sorumlu olacak ya da öncelikler konusunda pazarlık edecek kimse yoktu. Teknik ekip içinde fikir ayrılığı çıktığında ürün yöneticisi tüm mühendislerle tek tek pazarlık etmek zorunda kalıyordu. Bu da olmazsa en az üç kişi olan backend/web/mobile mühendislik yöneticileriyle pazarlık etmek ya da bölümün mühendislik liderine konuyu taşımak gerekiyordu.
[ Spotify’nin hatalarından öğrenilecekler ]
→ Ürün-tasarım-teknoloji ekiplerinde genellikle mühendis sayısı daha fazla olduğu için, tüm mühendislerden sorumlu bir yönetici olmalı ki ekip içi görüş ayrılıklarında bir escalation hattı olsun
→ Ürün yöneticilerinin teknoloji konularını konuşabileceği eş düzey bir muhatabı olmalı (CEO ve CTO gibi).
- Ekip özerkliğine bel bağlamak
Şirket küçükken her ekip geniş bir iş alanıyla uğraşır ve inisiyatifi alan ekip sık sık değişebilir.
Şirket büyüdükçe ekipler arasındaki tekrar eden işlevler verimlilik için yeni ekiplerde birleştirilir.
Ekip sayısı arttığında inisiyatifin el değiştirmesi daha seyrek olur ve ekipler çözmeleri gereken sorunlar hakkında uzun vadeli düşünebilir.
→ Spotify, ekipler arası iş birliği için ortak bir süreç tanımlamadı. Her ekip kendi yöntemiyle dahil olunca tüm organizasyonun üretkenliği düştü.
→ "Spotify modeli", şirket çok daha küçükken derlenmişti. Bunun devamı olarak daha güncel bir çerçeve gelmeliydi ama gelmedi. Sadece özerklikten söz edildi, ekipler arası iş birliği kısmı tamamlanmadı.
[ Spotify’nin hatalarından öğrenilecekler ]
→ Özerklik hizalanma gerektirir. Şirket öncelikleri yönetim tarafından belirlenmelidir. Özerklik, ekiplerin canlarının istediğini yapması demek değildir.
→ Ekipler arası iş birliği süreci mutlaka gereklidir. Özerklik, her ekibi tüm sorunları tek başına çözsün diye bırakmak değildir.
→ Başarının nasıl değerlendirileceği de yönetim tarafından belirlenmelidir ki ekipler arası iş birliği önceliklerinde uyum sağlanabilsin.
→ Özerklik hesap verebilirlik gerektirir. Product Management, ürün değerinden sorumlu olmalıdır. Her ekip, eklenen parçayı 'tamamlanmış' hale getirmekten sorumludur. Olgun ekipler, iş değeri, risk, öğrenme ve sonraki adımlar için en iyi hareketi gösterebildiklerini ortaya koyarak bağımsızlıklarını haklı çıkarmalıdır.
"Spotify’de tek bir şeyi düzeltme şansım olsaydı, özerkliği bu kadar fazla vurgulamamış olmayı seçerdim." - Spotify’nin eski Agile koçu Joakim Sunden
- İş birliği, yalnızca var olduğu varsayılan bir yetkinlikti
Spotify ekiplerin çalışma biçimini kontrol etmesine izin verdi, ama birçok kişinin Agile hakkında temel bir anlayışı bile yoktu.
Bu yüzden ekipler, çıktılarını iyileştirmek için süreç iyileştirmelerini tekrar tekrar deneyip doğru kombinasyonu bulmaya uğraşmak zorunda kaldı.
Sürecin sorunlarını ya da çözümlerini verimli biçimde konuşmak ve sonuçları değerlendirmek için ortak bir dil yoktu. Aslında bu Agile bile değildi; sadece "Not-Waterfall" idi.
Spotify’de her ekibe süreç iyileştirmeyi öğretip önerilerde bulunacak "Agile koçları" vardı. Niyet iyiydi ama tüm ekiplere yardımcı olmaya yetecek kadar koç yoktu.
Her koçun ekiplere ayırabildiği zaman, bir ekibin projeyi tamamlayıp sonucu değerlendirmesine kadar destek vermek için yetersizdi. Bu nedenle aslında hiçbir şeyden sorumlu değillerdi.
[ Spotify’nin hatalarından öğrenilecekler ]
→ İş birliği; bilgi ve pratik gerektiren bir beceridir. Yöneticiler, insanların mevcut Agile pratiklerini zaten anladığını varsaymamalıdır.
→ Şirket yeterince büyüdüğünde, her ekibin hem kendi içinde plan yapabilmesi hem de ekipler arası iş birliğini mümkün kılması için destek organizasyonlarına ihtiyaç vardır. Program Management planlama sürecinden sorumlu olmalıdır. Adanmış Program Manager’lar, Product Manager ile Engineering Manager’ın kendi rollerini yerine getirirken aynı zamanda iş birliği yapabildiği şekilde ekiplerin çalışmasını sağlamalıdır.
- Mitleri değiştirmek zordur
Agile Scrum’ın burndown/sprint gibi kelimeler sunmasının nedeni, yeni kavramları tanıtırken bunlara bir isim gerekmesiydi.
Spotify, Missions, Tribe, Squads, Chapter Lead gibi yeni kelimeler tanıttı; bu da "ancak özel bir kelime seçersek gerçekten yeni bir şey üretmiş oluruz" yanılsamasını yarattı.
Bu gereksiz eş anlamlıları kaldırdığınızda, Spotify modeli aslında fazla özerklik ve zayıf bir yönetim yapısına sahip "Cross-Functional Team" kümelerinden ibaret.
Eğer Spotify bu modele dair fikirleri kendi uydurduğu isimler yerine özgün adlarıyla anmış olsaydı, model başarısız olduğunda bunu kültürel kimliği değiştirmek gibi değil, daha iyi çalışan iç süreçler bulma çabası olarak değerlendirebilirdi.
[ Spotify’nin hatalarından öğrenilecekler ]
→ Çoğu işletme yalnızca birkaç inovasyon alanını sürdürebilir. İç süreçlerdeki inovasyonun şirketi pazarda farklılaştırdığı durumlar nadirdir. Geçmişi incelemek, işletmelerin inovasyon için daha iyi alanlar bulmasına yardımcı olabilir.
→ Anlaşılabilirliği optimize edin. Organizasyonun üretkenliğini korumak için, çalışanların öğrenmesi gereken her yeni şeyin değerini değerlendirmek gerekir.
*** Bunun yerine şunu yapın. ( Elbette hızlı bir yol yok. )
Spotify modelini aramanızın nedeni muhtemelen kendi ekip yapınızı kurmak istemenizdir. Burada durmayın; daha fazlasını araştırın.
Spotify’den daha uzun süre test edilmiş şirketler çok daha fazla şey yazdı.
2012’deki Spotify, büyük ölçekli bir organizasyonda küçük ekiplerin hızını ve çevikliğini nasıl koruyacağını bulamamıştı.
Onlar da bu ilk modelin ötesine geçip daha iyi yanıtlar bulmak için dışarıya baktı; sizin de öyle yapmanız gerekir.
Yazarın diğer çalışma biçimlerine dair önerileri
-
Ürün-geliştirme-tasarım organizasyonunuzda 200’den fazla kişi mi var? Fitbit’te çalıştığım dönemde "Scaled Agile Framework" iyi uyuyordu.
-
200 kişinin altındaysa "Shape Up By Basecamp" öneririm. Bir sonraki startup’ımı bu yapıyla kurmayı planlıyorum.
-
"Essential Scrum" ve "Team Topologies" kitaplarını okuyun.
4 yorum
Güzel yazı için teşekkürler.
Şu anki şirkette de yaklaşık 2 yıl önce Spotify'ın squad takım modelini benimsedik, ancak yazıda belirtilen dezavantajlar nedeniyle birçok kısmın zorunlu olarak iyileştirildiğini gördük.
Bu yılın başından beri Basecamp'in geliştirdiği Shape Up'ı takip ediyoruz ve sonuç olarak daha iyi ürün kalitesi sunabilir hale geldik.
Öyle gerçekten. Başarı örnekleri kadar başarısızlık örnekleri de önemli.
Ben bu "Scaling Agile" white paper ilk yayımlandığında görüp şaşırarak paylaşmış, blogumda da yazmıştım.. Sarsıcı bir yazı hüzün
Yazarın önerilerinden biri olan "Basecamp'in Shape Up"ı GeekNews'te daha önce tanıtmıştık. Küçük organizasyonlarda ben de bunu öneriyorum.
Shape Up - küçük organizasyonların harika çalışmasının yolu [PDF] https://tr.news.hada.io/topic?id=427
Spotify çalışanlarının bu yazıya tepkileri
Ben 6 yıl kaldım ve %100 doğru. https://twitter.com/solomonjames/status/1258930064441425920
Ben 2019'da ayrıldım ve ayrılmamın büyük nedenlerinden biri bu yazıdaki sorunlardı https://twitter.com/ayyyylo/status/1253658456621539328
Bunu taklit edip başarısız olan diğerlerinin tepkileri
Zalando bunu 2016'da uyguladı, ama bunun iyi çalışmadığını kısa sürede fark etti https://twitter.com/chilicoder/status/1253429837185691656
Typeform da bunu uygulamaya çalıştı ama başarısız oldu https://twitter.com/jharmn/status/1252229296522842121
Spotify bunu blogunda yazar yazmaz denedik ve tam bir felaketti. https://twitter.com/braedon/status/1256122236424957953