AgileKoc ToolsScrum Master Kim Olmalı? Türkiye'de 'Yönetici mi, Takım İçi mi?' Tartışmasına Gerçekçi Bir Bakış
Scrum Master rolünü yönetici mi üstlenmeli, takımdan mı çıkmalı? Türkiye gerçeğinde etki gücü, psikolojik güvenlik ve karar kriterleriyle net yanıt.
Türkiye'de Scrum Master Rolü Neden Zor?
Türkiye'de Scrum Master rolü en çok şu yüzden zor: Scrum, "işi daha görünür ve öğrenerek yapma" düzeni ister; çoğu kurum ise hâlâ "kontrol + onay + acil" refleksleriyle çalışır. Sonuç?
Scrum Master çoğu yerde ya toplantı organize eden kişi olur, ya da "PM'in farklı isimlisi"ne dönüşür. Bir süre sonra ekip de şunu söyler:
"Scrum bizde çalışmıyor."
Benim savunduğum yaklaşım şu:
Yazılım yöneticisi (Engineering Manager / Team Lead), Scrum'a evrilen bir dünyada Scrum Master bakışına evrilmelidir.
Yani yönetici şapkası, "iş dağıtan" değil; liderlik eden, sistemi iyileştiren ve organizasyona doğruları anlatan bir şapkaya dönüşmelidir.
Bu Yazıda Neyi Netleştireceğiz?
- Scrum Master "rol" mü "pozisyon" mu?
- Scrum Master'ı takım içinden seçmek ne zaman işe yarar, ne zaman çuvallar?
- Türkiye'de neden "etki gücü" kritik?
- Engineering Manager → Scrum Master evrimi ne kazandırır, ne risk taşır?
- Karar vermek için pratik kriter listesi
Önce Netleşelim: Scrum Master 'Rol' mü 'Pozisyon' mu?
Scrum Guide'a göre Scrum Master bir hesap verebilirlik (accountability) içerir. Yani "biri gönüllü olsun, bu sprint kolaylaştırsın" seviyesinde kalınca rol çoğu zaman yan görev gibi algılanır.
Türkiye pratiğinde ise şu gerçek var:
Eğer Scrum Master'ın zamanı, odağı ve etkisi yoksa, Scrum Master rolü hızla "takvim yöneticisi"ne düşer.
Bu yüzden benim çerçevem şu:
- Küçük, olgun, self-managed ekiplerde Scrum Master rolü takım içinden çıkabilir.
- Kurumsal, bağımlılıkları yüksek, baskılı yapılarda Scrum Master "etki" ister; bu da çoğu zaman "liderlik rolü" gerektirir.
Türkiye'de Scrum Master'ın 'Etki Gücü' Neden Şart?
Çünkü engellerin büyük kısmı teknik değil, organizasyonel:
- Onay süreçleri (güvenlik, satın alma, hukuk, IT governance)
- "Acil" kültürüyle her gün değişen öncelikler
- Ekiplerin aynı anda 3 projeye bölünmesi
- İş biriminin sprint ortasında scope sokması
- Yönetimin "rapor" beklentisi (günlük durum, haftalık üst yönetim sunumu vs.)
- Bağımlılıklar ve silo yapısı
Bu engelleri kaldırmak için Scrum Master'ın sadece facilitation bilmesi yetmez.
İçeride bir ağırlığı, ilişkisi ve sözünün geçtiği bir alan olması gerekir.
İşte burada şu soru çıkıyor:
"Bu etki gücünü kim daha kolay sağlar: ekip içinden seçilen biri mi, yoksa liderlik rolü olan biri mi?"
Neden 'Engineering Manager → Scrum Master Bakışı' Diyorum?
"Yönetici Scrum Master olsun" demekle "yönetici Scrum Master bakışına evrilsin" arasında fark var.
Benim söylediğim daha çok şu:
Yönetici; işi dağıtmayı, kontrol etmeyi, rapor kovalamayı bırakıp
ekip için koruyucu kalkan, organizasyon için çevirmen, sistem için iyileştirici olmalı.
Kültür Kazanır: Sahadan Ofise Çeviklik
Mikro yönetim, rapor takıntısı ve güven eksikliğini sahadan okuyun. Futbol sahasındaki dinamikler ile iş dünyasındaki kontrol refleksini paralel bir anlatımla keşfedin.
Türkçe e-kitap
Yönetici Evrilince Ne Kazanırsın?
1. Ekip Odağını Koruyabilir
Bölünmeye karşı "tek Sprint Goal"u savunabilecek ağırlık olur.
2. İş Birimiyle Sınırları Daha Net Çizer
"Şimdi değil, Backlog'a alalım; önceliklendirme PO ile" cümlesini söylemek yetmez; bunu yaşatmak gerekir.
3. Organizasyonel Engellere Daha Hızlı Dokunur
Onay süreçleri, kaynak çekişmesi, bağımlılıklar… Bunlar çoğu zaman "eş düzey" konuşma ister.
4. Scrum'ın 'Seremoni'ye Düşmesini Engeller
Çünkü hedefi "toplantı" değil, "akış ve değer" olur.
5. Takımı Büyütür (Liderlik)
Scrum Master'ın özü hizmetkâr liderliktir. Bu, yöneticiye de iyi gelir: "komut-kontrol" yerine "güçlendirme"."
Ama Dürüst Olalım: Yönetici Scrum Master Yaklaşımının Riskleri Var
Bu kısmı atlamamak önemli. Çünkü bazı şirketlerde "yönetici Scrum Master" ekibi rahatlatmak yerine boğabilir.
Risk 1: Psikolojik Güvenlik Zedelenebilir
Eğer yönetici aynı zamanda:
- performans değerlendiren,
- terfi/maaş etkisi olan,
- "hata yapınca" tepki veren kişiyse
ekip Retro'da açık konuşmaz. Retro "tiyatro" olur.
Risk 2: Scrum Master Rolü Kontrol Aracına Dönebilir
İyi niyetle bile şu kayma olur:
- "Ben liderim, en doğrusu bende"
- "Sprint hedefi tutmadıysa sıkıştırayım"
- "Herkes daily'de bana rapor versin"
Scrum, özgürlük değil daha sofistike kontrol aracına dönüşür.
Risk 3: Rol Çatışması Yaşanır
Yönetici rolünün doğası bazen "karar vermeyi" gerektirir. Scrum Master ise çoğu zaman "karar verdirmek" işini yapar.
Bu ikisi aynı kişide çakışabilir.
Özet: Yönetici Scrum Master yaklaşımı doğru uygulanırsa roket; yanlış uygulanırsa zehir.
Takım İçinden Scrum Master Seçmek: Ne Zaman İyi Fikir?
Takım içinden Scrum Master'ın çok iyi çalıştığı durumlar var:
- ✅ Ekip olgun (self-management var)
- ✅ Yönetim gerçekten destek oluyor (engelleri kaldırıyor)
- ✅ Paydaş baskısı düşük, scope disiplinli
- ✅ Scrum Master adayının iletişimi güçlü, saygı görüyor
- ✅ Scrum Master rolüne zaman ayrılıyor (yan iş değil)
Bu durumda takım içinden çıkan Scrum Master:
- gerçek bir sahiplik yaratır,
- ekibin "bizim sürecimiz" demesini sağlar.
Ama Türkiye'de sık görülen senaryoda (baskı, bağımlılık, onay zinciri) takım içinden seçilen Scrum Master çoğu zaman şu noktada takılır:
"Bunu yönetime nasıl kabul ettireceğim?"
"İş birimi sprint ortasında işi soktu, ben ne yapacağım?"
"Ekip bölünüyor, kim dur diyecek?"
O Zaman Karar Nasıl Verilecek? (Pratik Kriter Listesi)
Şu kriterlerle net karar verebilirsin:
1) Engellerin Tipi
- Engeller çoğunlukla organizasyonelse → liderlik/etki gücü gerekir.
- Engeller çoğunlukla ekip içiyse (alışkanlık, teknik pratikler, iş akışı) → takım içinden SM yeterli olabilir.
2) Psikolojik Güvenlik Seviyesi
- "Yönetici varken kimse açık konuşamıyor" → yönetici SM olmamalı; ayrı SM daha iyi.
- "Yönetici koç gibi, güven var" → yönetici SM bakışı çok işe yarar.
3) Scrum Olgunluğu
- Çok düşük olgunluk + yüksek baskı → full-time güçlü SM şart (çoğu zaman liderlik rolüyle).
- Olgun ekip → takım içinden SM sürdürülebilir.
4) Zaman ve Odak
- Scrum Master %10 zaman ayıracaksa → sonuç bekleme.
- En azından bir dönem %50+ odağı olacak biri olmalı.
5) Organizasyonun "Değişime Toleransı"
- Yönetim sadece "hız istiyorsa" → SM rolü "kandırmaca"ya dönebilir.
- Yönetim öğrenmeye ve şeffaflığa açıksa → SM rolü gerçek iş yapar.
Benim Yaklaşımımın Kısa Özeti
Ben "Scrum Master kesin yönetici olmalı" demiyorum.
Ben şunu söylüyorum:
Türkiye'de Scrum Master rolü çoğu zaman etki gücü ister.
Bu etki gücü yoksa rol "yan iş"e düşer ve Scrum törene dönüşür.
Bu yüzden yazılım yöneticisi, Scrum'a evrilen dünyada Scrum Master bakışına evrilmeli:
kontrol eden yönetici değil, sistemi iyileştiren lider olmalı.
Bu dönüşüm, ekipleri gerçekten hızlandıran şeyin "Scrum toplantıları" değil; odak, engel kaldırma ve sürekli iyileştirme olduğunu yönetime de anlatır.
Kapanış: Sana Küçük Bir Meydan Okuma Sorusu
Şu soruya dürüst cevap ver:
Bizde engellerin %70'i ekip içinde mi, organizasyonda mı?
Eğer organizasyondaysa, Scrum Master'ın "yetkinliği" kadar "yetkisi/etkisi" de kritik.
Ve o zaman Scrum Master rolünü rastgele seçmek çoğu zaman pahalıya patlar.