Scrum Master Müdahale Etmeli mi, Takımı Kendi Haline mi Bırakmalı? Pasiflik Hizmetkar Liderlik Değildir.

Ayşe, Phoenix Takımı'nın Scrum Master'ı olarak son üç Sprint'i endişeyle izliyordu. Takım, her Sprint Planlama'da büyük bir hevesle Sprint Hedefi belirliyor, işleri taahhüt ediyor ve işe koyuluyordu. Ancak Sprint İncelemesi'ne gelindiğinde, her zaman bir şeyler eksik kalıyordu. Sprint Hedefi ya kısmen tamamlanıyor ya da tamamen kaçırılıyordu.

Geliştiriciler (Developers) arasında gerginlik artmaya başlamıştı. Caner, sürekli olarak 'Ürün Sahibi (Product Owner) son dakikada gereksinimleri değiştiriyor' diye şikayet ederken, Elif ise 'Caner, sen baştan doğru tahmin etseydin bu olmazdı' diye karşılık veriyordu. Ürün Sahibi Deniz ise 'Ben sadece pazarın ihtiyaçlarına göre ayarlama yapıyorum, bu çeviklik değil mi?' diyerek kendini savunuyordu. Bu tartışmalar, Daily Scrum'larda bile hissedilir hale gelmişti; kimse sorunların kökenine inmek istemiyordu.

Ayşe, ilk başta takımın kendi çözümünü bulacağına inanarak geri planda kalmayı tercih etmişti. Sonuçta, Scrum Guide takımların kendi kendini organize etmesini ve yönetmesini vurguluyordu. Ama bu pasiflik, takımın sorunları derinleştirmesine yol açıyordu. Takım, her Sprint'te aynı döngüyü yaşıyor, moral düşüyor ve verimlilik azalıyordu. Ayşe, artık bir şeylerin değişmesi gerektiğini biliyordu. Ancak nasıl müdahale edecekti? Doğrudan bir çözüm sunmak, takımın özerkliğini zedeleyebilir miydi?

Birçok Scrum Master, 'hizmetkar liderlik' kavramını yanlış yorumlayarak, takımın sorunlarına tamamen kayıtsız kalmayı veya müdahale etmekten kaçınmayı tercih eder. Takımın 'kendi yolunu bulacağına' inanmak, iyi niyetli bir yaklaşım gibi görünse de, bazen sadece pasiflikten ibarettir.

Hizmetkar liderlik, takımın önündeki engelleri kaldırmak, onlara rehberlik etmek ve büyümeleri için uygun ortamı sağlamak anlamına gelir. Bu, takımın zorlandığı anlarda, özellikle de tekrarlayan kalıplar ortaya çıktığında, aktif bir rol üstlenmeyi gerektirir. Takımın sürekli olarak Sprint Hedefleri'ni kaçırması, çatışmaların su yüzüne çıkması veya verimsiz süreçlerin devam etmesi gibi durumlar, bir Scrum Master'ın gözlemlemesi ve müdahale etmesi gereken sinyallerdir.

Pasif kalmak, takımın kendi kendini organize etme yeteneğini geliştirmez; aksine, sorunların kronikleşmesine ve takımın potansiyelini gerçekleştirememesine neden olabilir. Scrum Master'ın görevi, takımın kendi çözümlerini bulmasına yardımcı olmak için doğru soruları sormak, zor konuşmaları kolaylaştırmak ve gerektiğinde takımın yüzleşmekten kaçındığı gerçekleri nazikçe ortaya koymaktır. Bu, 'ben karışmam' demekten çok daha fazlasıdır.

Ayşe'nin durumu, bir Scrum Master'ın sahip olması gereken en kritik yetkinliklerden birini vurgular: gözlemci koçluk ve zor konuşmaları etkili bir şekilde kolaylaştırma becerisi. Bu, sadece toplantı düzenlemek veya kuralları hatırlatmak değil, takımın dinamiklerini anlamak, altta yatan sorunları tespit etmek ve takımın kendi çözümünü bulmasına rehberlik etmektir.

Bu senaryoda, Ayşe'nin ihtiyacı olan şey, takımın Sprint Planlama sorunlarının ardındaki gerçek nedenleri ortaya çıkarmak için bir 'zor konuşma' başlatmaktı. Bu, sadece tahmin hatalarından ibaret olmayabilir; belki de gereksinimlerin net olmaması, Product Owner'ın önceliklendirme becerileri, Geliştiriciler arasındaki güven eksikliği veya dış paydaşların (stakeholder) sürekli müdahaleleri gibi daha derin sorunlar yatıyordu.

Bir Scrum Master olarak, bu tür durumlarda çatışma çözümü becerileri, güçlü koçluk soruları sorma yeteneği ve tarafsız bir kolaylaştırıcı olma rolü hayati önem taşır. Takımın kendi kendini organize etmesi için onlara alan tanımak önemlidir, ancak bu alanın içinde kaybolduklarında onlara yol göstermek de hizmetkar liderliğin bir parçasıdır. Bu müdahale, takımın özerkliğini kısıtlamak değil, aksine onların daha özerk ve etkili olmalarını sağlamaktır.

Bu tür hassas bir konuşmayı başlatmak ve yönetmek zorlayıcı olabilir. Takımın savunmaya geçmesini engellemek ve açık diyaloğu teşvik etmek için doğru yaklaşımı bulmak gerekir. Bu, sadece teorik bilgiyle değil, pratik deneyimle gelişen bir yetkinliktir.

Ayşe, pasif kalmanın bir çözüm olmadığını fark ettiğinde, bilinçli bir müdahale stratejisi geliştirdi. İşte bu tür durumlar için kullanılabilecek pratik bir çerçeve:

1. Gözlemle ve Veri Topla: Ayşe, son üç Sprint'in Sprint Hedefleri'ni, tamamlanan ve tamamlanamayan işleri, takımın Daily Scrum'lardaki etkileşimlerini ve Sprint İncelemesi'ndeki tartışmaları not aldı. Hangi kalıplar tekrarlanıyor? Kim ne zaman ne söylüyor?

2. Yansıt ve Hazırlan: Müdahale etmeden önce, Ayşe kendi varsayımlarını ve duygularını gözden geçirdi. Amacı neydi? Takımı suçlamak mı, yoksa onlara yardım etmek mi? Hangi soruları soracaktı? Olası tepkiler neler olabilirdi ve bunlara nasıl karşılık verecekti?

3. Sorgula ve Diyalog Başlat: Ayşe, takımın Sprint Retrospektifi'nde bu konuyu gündeme getirmeye karar verdi. Ancak bunu suçlayıcı bir dille değil, gözlemlerini paylaşarak ve açık uçlu sorular sorarak yaptı.

4. Kolaylaştır ve Derinleş: Takım üyeleri konuşmaya başladığında, Ayşe'nin görevi diyaloğu derinleştirmekti. Çatışma çıktığında tarafsız kalmak, herkesin sesini duyurmasını sağlamak ve ortak bir anlayışa ulaşmalarına yardımcı olmaktı. Bu, 'takım içi çatışma yönetimi' becerilerini devreye sokmayı gerektirir.

5. Güçlendir ve Sorumluluk Ver: Çözüm önerileri takımdan gelmeliydi. Ayşe, takımın kendi çözümlerini formüle etmesine, denemeler yapmasına ve sonuçlarını değerlendirmesine olanak tanıdı. Bu, onların kendi kendini organize etme ve yönetme yeteneklerini geliştirmelerini sağlar.

Ayşe, Retrospektif'i başlattıktan sonra, gözlemlerini şu şekilde paylaştı:

Ayşe: 'Arkadaşlar, son üç Sprint'te Sprint Hedeflerimizi tutturamadık. Bu konuda ne hissediyorsunuz? Bu durumun takımımız üzerindeki etkilerini nasıl görüyorsunuz?'

Caner ve Elif arasında kısa bir gerginlik yaşandı. Ayşe, sakinliğini korudu ve sözü Elif'e verdi.

Elif: 'Açıkçası, ben moralimin bozulduğunu hissediyorum. Ne kadar uğraşsak da, sanki bir yere varamıyoruz. Planlamada çok iyimser mi oluyoruz, yoksa işler mi sürekli değişiyor, emin değilim.'

Ayşe: 'Elif, bu hissi paylaştığın için teşekkür ederim. 'İyimserlik' ve 'işlerin değişmesi' önemli noktalar. Caner, sen ne düşünüyorsun bu konuda?'

Caner: 'Ben de Elif'e katılıyorum. Ama bence asıl sorun, Planlama'da üzerinde anlaştığımız şeylerin Sprint ortasında değişmesi. Ürün Sahibi Deniz, sürekli yeni taleplerle geliyor.'

Deniz (Ürün Sahibi): 'Ben sadece pazarın dinamiklerine göre hareket ediyorum. Eğer esnek olmazsak, rekabet edemeyiz. Zaten çeviklik bu değil mi?'

Ayşe, gerilimin arttığını hissetti. İşte bu noktada, bir Scrum Master'ın kolaylaştırma becerileri devreye girer. Ayşe, suçlamaları durdurmak ve daha yapıcı bir diyalog başlatmak için devreye girdi:

Ayşe: 'Hepinizin haklı olduğu noktalar var. Deniz, pazar dinamiklerine uyum sağlama ihtiyacını anlıyorum. Caner ve Elif, planlama istikrarı ve taahhütleri yerine getirme arzusunu dile getiriyor. Bu üç bakış açısını nasıl bir araya getirebiliriz? Sprint Planlama sırasında hangi varsayımlarla hareket ediyoruz ve bu varsayımlar ne kadar gerçekçi?'

Bu soru, tartışmayı 'kimin suçu' olmaktan çıkarıp, 'nasıl daha iyi yapabiliriz' noktasına taşıdı. Takım, Sprint Hedefi'nin netliğini, Product Backlog öğelerinin detay seviyesini ve dışarıdan gelen değişikliklere nasıl tepki vereceklerini konuşmaya başladı. Ayşe, sadece sorular sorarak ve diyaloğu yönlendirerek, takımın kendi çözümünü bulmasına rehberlik etti. Sonuç olarak, takım Sprint Hedefi'ni daha net tanımlama, Product Owner ile daha sık senkronize olma ve beklenmedik değişiklikler için bir 'tampon' bırakma konusunda anlaştı.