Sprint Ortası Kapsam Değişikliği: 'Evet' mi, 'Hayır' mı, Yoksa 'Nasıl Konuşmalı'?

Ayşe, deneyimli bir Scrum Master olarak, ekibinin Sprint'in ortasında iyi bir ritim yakaladığını biliyordu. Sprint Hedefi netti: 'Müşteri paneline yeni bir raporlama modülü eklemek.' Geliştiriciler, Can'ın (Product Owner) önceliklendirdiği işlere odaklanmış, ilerleme kaydetmişlerdi.

Ancak bir öğleden sonra, Can'ın masasına geldiğini gördü. Yüzünde hafif bir gerginlik vardı. 'Ayşe, Elif Hanım'dan (üst düzey bir paydaş) acil bir talep geldi. Yeni bir entegrasyon, 'şimdi' yapılması gerekiyormuş. Cuma günkü Yönetim Kurulu toplantısında sunumda olması şartmış.' dedi Can, sesi endişeliydi. 'Bunu bu Sprint'e sıkıştırmalıyız, Elif Hanım'ın baskısı çok yüksek.'

Ayşe, Can'ın durumunu anladı. Product Owner olarak paydaş beklentilerini yönetmek zordu ve bazen bu tür 'acil' talepler kaçınılmazdı. Ancak aynı zamanda, ekibinin odağını, Sprint Hedefi'ni ve sürdürülebilir çalışma hızını korumanın kendi sorumluluğu olduğunu da biliyordu. Bu yeni işi eklemek, mevcut Sprint Hedefi'ni tehlikeye atacak, ekibin moralini bozacak ve muhtemelen teknik borcu artıracaktı. 'Evet' demek kolay bir kaçış yolu gibi görünse de, uzun vadede daha büyük sorunlara yol açacaktı. 'Hayır' demek ise Can'ı zor durumda bırakacak ve işbirliğini zedeleyebilirdi. Ayşe, bu durumun sadece bir 'evet' ya da 'hayır' meselesi olmadığını biliyordu; bu, nasıl konuşulacağı meselesiydi.

Bir Scrum Master olarak, bu tür durumlarda ilk tepkilerimiz genellikle iki uçtan birine kayar:

1. 'Hayır, Scrum Kuralı Böyle Diyor!' Yaklaşımı: Scrum Kılavuzu'na sıkı sıkıya bağlı kalmak, teorik olarak doğru olsa da, Product Owner'ı ve paydaşları düşmanlaştırabilir. 'Kuralları uygulayan robot' imajı çizebilir, işbirliğini zedeleyebilir ve sorunun kökenindeki paydaş baskısını çözmez. Product Owner, 'Benim işim bu' derken, Scrum Master 'Benim işim de bu' diyerek bir güç mücadelesine girer. Bu, genellikle kaybedenlerin olduğu bir senaryoyla sonuçlanır.

2. 'Tamam, Bir Şekilde Sıkıştırırız' Yaklaşımı: Bu, kısa vadede herkesi mutlu ediyormuş gibi görünse de, uzun vadede yıkıcı sonuçları vardır. Ekibin moralini bozar, Sprint Hedefi'ni anlamsızlaştırır, teknik borcu artırır, tahmini zorlaştırır ve en önemlisi, ekibin sürdürülebilir hızına zarar verir. Her Sprint'e ek işler sıkıştırmak, ekibin sürekli olarak 'yangın söndürme' modunda çalışmasına neden olur ve gerçek değer yaratma kapasitesini düşürür. Bu durum, şeffaflığı azaltır ve güveni zedeler.

Bu yaklaşımların her ikisi de, sorunun temelindeki dinamikleri ele almaktan uzaktır: paydaş beklentileri, Product Owner'ın yetki ve sorumlulukları, Sprint Hedefi'nin değeri ve ekibin korunması ihtiyacı. Gerçek bir hizmetkar liderlik, bu iki uç arasında bir denge bulmayı gerektirir; bu da güçlü iletişim ve koçluk becerileriyle mümkündür.

Bu senaryoda Scrum Master'ın ihtiyacı olan şey, sadece bir 'kural koyucu' olmak değil, bir 'kolaylaştırıcı' ve 'koç' olmaktır. Temel beceriler şunlardır:

Empati ve Aktif Dinleme: Product Owner'ın endişelerini, paydaş baskısını ve neden bu kadar 'acil' hissettiğini gerçekten anlamak. Sadece duymak değil, dinlemek.

Güçlü Sorular Sorma: Durumun tüm yönlerini ortaya çıkaracak, varsayımları sorgulayacak ve Product Owner'ın kendi çözümlerini bulmasına yardımcı olacak sorular sormak. 'Neden şimdi?', 'Bunu yapmazsak ne olur?', 'Sprint Hedefi'mizi nasıl etkiler?' gibi.

Net Sınırlar Koyma ve Seçenekleri Sunma: Suçlamadan, olası sonuçları şeffaf bir şekilde ortaya koymak ve farklı eylem planları sunmak. Scrum Master karar vermez, ancak bilgilendirilmiş bir kararın alınmasına yardımcı olur.

Şeffaflık Oluşturma: Mevcut durumun, olası kararların ve bunların sonuçlarının tüm ekibe ve ilgili paydaşlara açık olmasını sağlamak. Scrum'ın üç sütunundan biri olan şeffaflık, bu tür anlarda hayati önem taşır.

Bu, Scrum Master'ın hizmetkar liderlik rolünün bir parçasıdır. Ekibi dış müdahalelerden korurken, Product Owner'a doğru kararları vermesi için koçluk yapmak ve tüm paydaşlar arasında sağlıklı bir iletişim köprüsü kurmak. Amaç, sadece bir Sprint'i kurtarmak değil, aynı zamanda ekibin uzun vadeli sağlığını ve çevik olgunluğunu geliştirmektir.

Ayşe gibi bir Scrum Master'ın bu tür bir taleple karşılaştığında uygulayabileceği adımlar şunlardır:

1. Durumu Anlayın ve Doğrulayın: Product Owner'ın endişelerini dinleyin ve paydaş baskısını kabul edin. 'Can, Elif Hanım'ın bu talebinin senin için ne kadar önemli olduğunu anlıyorum. Bu tür acil durumların ne kadar stresli olabileceğini de biliyorum.'

2. Mevcut Durumu Şeffaf Hale Getirin: Bu yeni işin mevcut Sprint Hedefi ve devam eden işler üzerindeki potansiyel etkisini açıklayın. Takımın odağının dağılmasının, mevcut işlerin gecikmesinin veya kalitenin düşmesinin olası sonuçlarını vurgulayın. 'Bu yeni talep, mevcut Sprint Hedefi'miz olan 'X özelliğini canlıya almak' ne kadar etkiler? Geliştiricilerin şu anki odaklanmasını nasıl bozar ve bu, mevcut işlerin tamamlanma süresini ne kadar uzatır?'

3. Seçenekleri Sunun (Suçlamadan): Scrum Master olarak karar veren siz değilsiniz, ancak Product Owner'ın bilgilendirilmiş bir karar vermesine yardımcı olmak için seçenekleri net bir şekilde ortaya koymalısınız:

* A) Yeni işi bir sonraki Sprint'e almak: 'Bu yeni işi bir sonraki Sprint'e alarak, mevcut Sprint Hedefi'mizi koruyabilir ve ekibin odağını sürdürebiliriz. Böylece bu işi daha planlı bir şekilde ele alabiliriz.'

* B) Mevcut Sprint'teki bir işi çıkarmak: 'Eğer bu iş gerçekten bu Sprint'te yapılmalıysa, mevcut Sprint'teki hangi işi (veya işleri) dışarıda bırakmayı düşünürüz? Bu, Sprint Hedefi'mizin hala geçerli olmasını sağlar mı?'

* C) Sprint'i iptal etmek: 'Bu yeni talep, mevcut Sprint Hedefi'mizi tamamen geçersiz kılıyorsa ve çok daha önemliyse, Sprint'i iptal etme seçeneğimiz de var. Ancak bu, önemli bir maliyet ve yeniden planlama gerektirir.' (Bu seçenek çok nadir ve ciddi durumlarda düşünülmelidir.)

4. Kararı Product Owner'a Bırakın (Bilgilendirilmiş Karar): Seçenekleri ve olası sonuçlarını netleştirdikten sonra, kararı Product Owner'ın vermesini sağlayın. 'Bu seçenekler ışığında, sence ekibimiz ve ürünümüz için en iyi yol ne olur? Senin için en öncelikli olan nedir?'

5. Şeffaflığı Sağlayın: Alınan kararı takımla ve ilgili paydaşlarla (gerekiyorsa) paylaşın. Kararın neden bu şekilde alındığını ve olası sonuçlarını açıklayın. Bu, herkesin aynı sayfada olmasını ve gelecekte benzer durumların daha iyi yönetilmesini sağlar.

İşte Ayşe'nin Can ile yaptığı konuşmada kullanabileceği bazı ifadeler:

Empati ve Doğrulama:

* 'Can, Elif Hanım'ın bu talebinin aciliyetini anlıyorum. Bu tür durumlarda üzerindeki baskıyı tahmin edebiliyorum.'

* 'Bu konunun senin için ne kadar önemli olduğunu görüyorum.'

Durumu Şeffaf Hale Getirme ve Etkiyi Sorgulama:

* 'Peki, bu yeni işi mevcut Sprint'e eklediğimizde, şu anki Sprint Hedefi'miz olan 'X özelliğini canlıya almak' ne kadar etkilenecek?'

* 'Geliştiricilerin şu anki odağını dağıtmadan bu işi nasıl entegre edebiliriz? Mevcut işlerden hangileri gecikebilir?'

* 'Bu, ekibin sürdürülebilir hızını ve motivasyonunu nasıl etkiler sence?'

Seçenekleri Sunma ve Kararı PO'ya Bırakma:

* 'Eğer bu işi şimdi alırsak, mevcut Sprint'teki Y veya Z işlerinden hangisini dışarıda bırakmayı düşünürüz? Bu, Sprint Hedefi'mizin hala geçerli olmasını sağlar mı?'

* 'Bu kararı verirken, hem takımın sürdürülebilir hızını hem de Sprint Hedefi'nin değerini korumayı hedefliyoruz. Senin için en öncelikli olan nedir?'

* 'Bu yeni talebin aciliyeti, mevcut Sprint'i iptal etmeyi gerektirecek kadar yüksek mi? Eğer öyleyse, bunun potansiyel maliyetlerini ve faydalarını konuşalım.'

* 'Bu seçenekler ışığında, ekibimiz için en iyi yolun ne olduğunu düşünüyorsun?'

Bu tür konuşmalar, Product Owner'ı bir 'karar verici' olarak konumlandırırken, Scrum Master'ı ise bir 'bilgilendirici' ve 'kolaylaştırıcı' olarak konumlandırır. Bu, sağlıklı bir işbirliği ortamı yaratır ve uzun vadede daha iyi kararlar alınmasını sağlar.