Scrum'ı Bir Üst Seviyeye Taşımak: Ölçme, Ölçekleme ve Yanlış Bilinenler
Temel pratiklere hâkim bir ekip için bir sonraki adım, Scrum'ı daha çok uygulamak değil; neyi, neden ve nasıl ölçtüğünü bilmek ve yaygın yanlışlardan kaçınmaktır. Bu ders dört başlıkta ilerler: yanlış bilinenler, ölçme, zor durumlar ve ölçekleme. Sonunda öz değerlendirme listesi ve beş pratik ipucu var.
Sık Yanlış Bilinenler
| Yanlış inanış | Gerçek | Sahada ne yapmalı? |
|---|---|---|
| Scrum bir metodolojidir | Scrum bir çerçevedir; kuralları verir, uygulama detayını ekibe bırakır | Kendi bağlamınıza uyan pratikleri ekip olarak tanımlayın ve yazın |
| Çevik olmak dokümantasyonu bırakmaktır | Manifesto çalışan yazılımı öne koyar, dokümantasyonu yok saymaz | Gerekli dokümanı Bitti Tanımı'nın içine koyun, kısa ve güncel tutun |
| Velocity ekipler arası kıyaslama aracıdır | Story point her ekibin kendi göreli ölçeğidir | Velocity'yi yalnızca ekibin kendi kapasite tahmininde kullanın |
| Scrum Master ekibin yöneticisidir | Scrum Master süreci ve ekibin etkililiğini destekleyen bir hizmetkâr liderdir | İş atama ve performans değerlendirmesini bu role yüklemeyin |
Ölçme: Göstergeler Ne Söyler, Ne Söylemez?
| Gösterge | Ne söyler? | Ne söylemez? |
|---|---|---|
| Velocity | Ekibin yaklaşık kapasitesindeki eğilimi | Ekibin ne kadar iyi olduğunu veya üretilen değeri |
| Döngü süresi (cycle time) | Bir işin başlamasından bitmesine kadar geçen süre; akıştaki tıkanıklıklar | İşin doğru iş olup olmadığını |
| Teslim süresi (lead time) | Talepten teslimata kadar geçen toplam süre; müşterinin beklediği süre | Bekleme süresinin hangi aşamada oluştuğunu (bunun için döngü süresine bakın) |
| Sprint hedefi başarı oranı | Ekibin ortak hedefe odaklanıp odaklanmadığı | Hedefin kendisinin değerli olup olmadığını |
| Hata kaçış oranı | Canlıya sızan hataların, kalite kapılarından ne kadar geçtiğini | Hataların ciddiyetini ve kök nedenini |
| Ekip memnuniyeti | Sorunların çıktıya yansımadan önceki erken sinyali | Tek başına ekibin başarılı olduğunu |
Goodhart Yasası Tuzağı
Bir ölçü hedefe dönüştüğünde, iyi bir ölçü olmaktan çıkar. Örnek senaryo: Yönetim, velocity'nin her Sprint artmasını ister. Ekip iki hafta içinde puanları şişirir, velocity yükselir ama teslim edilen değer değişmez.
- Tek bir gösterge değil, birbirini dengeleyen 3-4 göstergelik bir set seçin (örneğin akış hızı + kalite + memnuniyet).
- Tek bir Sprint'e değil, trende bakın.
- Göstergeleri bireyleri değerlendirmek için kullanmayın; ekip kendi verisinin sahibi olsun.
- Sayı kötüleştiğinde suçlu aramayın, retrospektifte neden diye sorun.
Zor Durumlar: Adım Adım Yönerge
Sprint ortasında kapsam değişikliği
- 1. Ürün Sahibi talebi ekibe açıkça anlatır.
- 2. Ekip etkiyi tahmin eder: Sprint hedefi tehlikede mi?
- 3. Hedef tehlikede değilse: yeni iş girer, benzer büyüklükte bir iş çıkar.
- 4. Hedef anlamını yitirdiyse: Sprint iptali Ürün Sahibi'nin yetkisindedir; ekiple konuşarak karar verin.
Yarım kalan işler
- Otomatik olarak sonraki Sprint'e taşımayın; önce Ürün Backlog'una geri alın.
- Kalan iş miktarını yeniden tahmin edin ve önceliğine göre sıralayın.
- Sprint Review'da yarım işi bitmiş gibi göstermeyin.
Birden fazla ürüne bölünmüş ekip
- Tek bir sıralı backlog veya net bir öncelik kuralı belirleyin.
- Bağlam değiştirme maliyetini görünür kılın; ekibin aynı anda çalıştığı iş sayısını sınırlayın.
Düzenleyici veya güvenlik gereksinimi olan sektörler
- Uyum adımlarını (izlenebilirlik kaydı, güvenlik taraması, onay) sona bırakmayın, Bitti Tanımı'na koyun.
- Uyum ekibini ve güvenlik ekibini Sprint Planlama ve Review'a davet edin.
Dış tedarikçiyle çalışma
- Tedarikçiyle ortak bir Bitti Tanımı yazın.
- Tedarikçi çıktısını Sprint Review'da gösterin; teslimi Sprint sonuna bırakmayın.
Ölçekleme: Giriş Düzeyi Bakış
Birden fazla Scrum ekibi aynı ürün üzerinde çalışacaksa en az şunlar gerekir: tek bir ortak Ürün Backlog'u, ortak bir Bitti Tanımı ve ekipler arası bağımlılıkları görünür kılan düzenli bir eşgüdüm ritmi. İlke şudur: önce tek ekibi sağlamlaştırın. Sorunlu bir ekibi çoğaltmak sorunu da çoğaltır.
Ekip Olgunluğu Öz Değerlendirme Listesi
Her maddeyi ekiple birlikte işaretleyin: Evet / Kısmen / Hayır.
- Her Sprint'in tek cümlelik, ölçülebilir bir hedefi var.
- Bitti Tanımı yazılı ve herkes aynı şekilde yorumluyor.
- Backlog'un ilk birkaç Sprint'lik kısmı hazır ve sıralı.
- Retrospektifte alınan aksiyonlar bir sonraki Sprint'te takip ediliyor.
- Velocity yalnızca ekip içinde kullanılıyor.
- Döngü süresini veya benzer bir akış göstergesini izliyoruz.
- Hatalar canlıya çıkmadan yakalanıyor; kaçanlar için kök neden bakıyoruz.
- Ekip, Sprint ortasında gelen taleplere karşı Ürün Sahibi ile net bir yol izliyor.
- Ekip üyeleri sorunları açıkça dile getirebiliyor.
Yorumlama: Çoğu madde Hayır ise temel pratiklere dönün. Çoğu Evet ise aşağıdaki ipuçlarına geçin.
Bir Üst Seviyeye Taşıyacak 5 Pratik İpucu
- 1. Sprint hedefini yazın. Şablon: Bu Sprint sonunda [kullanıcı] şunu yapabilecek: [somut sonuç]. Kart listesi hedef değildir.
- 2. Küçük bir gösterge seti seçin. Örneğin: döngü süresi, hata kaçışı, ekip memnuniyeti. Üçünü de her retrospektifte 5 dakika konuşun.
- 3. İşleri küçültün. Bir kart birkaç günde bitmiyorsa bölün; küçük işler akışı öngörülebilir kılar.
- 4. Retrospektifte tek deney seçin. Deney şablonu: Şunu deneyeceğiz, şu sinyale bakacağız, şu Sprint'te değerlendireceğiz.
- 5. Yönetimle ortak dil kurun. Gösterge raporuna tek bir cümle ekleyin: bu sayı neyi söylüyor, neyi söylemiyor?
Bu dersi kayıt olmadan izleyebilirsin. İlerlemeni kaydetmek, sertifika almak ve puan tablosuna girmek için ücretsiz üye ol: Kayıt Ol