Scrum mu, Kanban mı: Metodoloji Değil, İşin Geliş Şekli

Yanlış soru: “Hangisi daha çevik?”

O Cuma akşamı retroya “Scrum bize uymuyor, Kanban’a geçelim” önerisiyle girdim. İki gün önce bir Kanban kitabının yarısını okumuştum ve kafamda cevap hazırdı. Yanlış soruyu soruyordum. Scrum ile Kanban arasında bir yarış yok. İkisi iki farklı iş şekli için tasarlanmış.

Serinin ilk bölümünde kaba bir ayrım yapmıştım: Scrum belirsizliği yüksek ürün geliştirme için, Kanban önceliği dışarıdan gelen, sürekli akan işler için. O tabloyu yazarken kendi ekibimin iki işi aynı anda yaptığını görmemiştim. Bizim sorunumuz yanlış çerçeve seçmek değildi. İki farklı iş türünü tek bir çerçeveye sokmaktı.

Scrum’ın bütün sözü şuna dayanır: iki hafta boyunca öncelik sabit kalır, ekip de karşılığında sprint sonunda çalışan bir şey gösterir. Bu anlaşma, işin iki hafta bekleyebildiği yerde güzel çalışır. Çağrı merkezinden gelen “müşterinin emri ekranda görünmüyor” eskalasyonu iki hafta bekleyemez. Onu sprint’e sokmak ya müşteriyi bekletir ya da sprint’i deler. Bizde her seferinde ikincisi oldu.

Önce say: 12 haftada 131 talep

Kanban önerisini retroda tartışmadık. Onun yerine bir aksiyon çıktı: son altı sprint’te (12 hafta) sprint planı dışında tahtaya giren her maddeyi kategorilere ayır. Scrum Master’ımız Selin ile bir öğleden sonra Jira’dan dışa aktarıp tek tek etiketledik. Tablo şuydu:

Üç şey netleşti. Birincisi, hacim tesadüf değildi: iki haftada ortalama 22 talep geliyordu ve altı sprint’in hiçbirinde 17’nin altına düşmemişti. Buna “plansız” demek kendimizi kandırmaktı; plansız olan iş değil, bizim planımızdı.

İkincisi, 58 eskalasyonun tamamı (%44) aynı gün cevap bekliyordu. Hiçbiri bir sonraki planning’i bekleyemezdi. Üçüncüsü, rapor talepleri farklıydı: bir hafta bekleyebiliyorlardı ve bir kısmı birkaç günlük işti. Onlar sprint’e sığıyordu, sadece doğru kapıdan girmiyorlardı.

Yani tek bir “destek işi” yoktu. Üç ayrı geliş şekli vardı ve her biri farklı bir cevap istiyordu.

Karar tablosu: işin geliş şekli → çerçeve

O tablodan sonra kararı çerçeveye göre değil, işin iki özelliğine göre vermeye başladık: ne kadar bekleyebildiği ve ne kadar önceden bilindiği.

Bir de oran kuralı koyduk. Plansız işin kapasiteye oranı %15’in altındaysa sprint içinde bir tampon yeter. %15 ile %30 arasındaysa tampon artı günlük bir triage gerekir. %30’u geçiyorsa o iş artık sprint’in bir sapması değil, ayrı bir iş akışıdır ve kendi kolunu ister. Bizim oranımız son altı sprint’te %31 ile %52 arasındaydı.

Tablonun üçüncü satırı en az konuşulanı ama en ucuz kazancı verdi. Rapor talepleri eskiden Slack’te birine doğrudan yazılıyor ve o kişi “beş dakikalık iş” diye araya sokuyordu. 24 rapor talebinin 9’u beş dakika değil, bir ile üç gün sürmüştü. Artık hepsi tek bir formdan geliyor, PO onları her Perşembe topluyor ve refinement’a alıyor. Talep sahibi bir hafta bekliyor ama ne zaman alacağını biliyor. Bekleme süresi uzadı, şikâyet azaldı. İnsanlar beklemekten değil, ne kadar bekleyeceklerini bilmemekten rahatsız oluyormuş.

Sahadan: iki başarısız deneme, bir işe yarayan model

Deneme 1: tamponu büyüt

Ekim 2024’te, sayım yapmadan çok önce, ilk refleksimiz buydu. Planı %40 boş bıraktık. Mantık basitti: destek işi gelecek, yer açalım. İki sprint sürdü. Plan tamamlama oranı düzelmiş gibi göründü, çünkü plan küçülmüştü. Ama sprint hedefi anlamını yitirdi. Kapasitenin neredeyse yarısı belirsizse “bu sprint şunu çıkarıyoruz” cümlesini kimse ciddiye almıyor. Review’da gösterilecek şey azaldı. PO’nun ifadesiyle “yarım sprint’e tam seremoni” yapıyorduk.

Tampon öngörülebilir dalgalanmayı emer. İşin kendisi sürekli akıyorsa onu emmez; sadece planı küçültür.

Deneme 2: kalıcı iki kişilik destek kolu

3 Şubat 2025’te Kanban kolunu kurduk. İlk tasarımda Can ve Barış kalıcı olarak operasyona geçti, kalan dört kişi sprint’e devam etti. İlk hafta harikaydı: eskalasyonların ortalama cevap süresi iki günden altı saate düştü.

Üçüncü sprint’in ortasında Barış bire birde şunu söyledi: “Ben destek ekibine mi geçtim?” Haklıydı. Yeni emir tipi geliştirilirken ikisi hiçbir tasarım tartışmasında yoktu. Ürünün yeni kısmını bilmiyorlardı, bu yüzden o kısımdan gelen eskalasyonları çözmek için yine sprint ekibine soruyorlardı. İki ekip kurmuştuk ve aradaki bilgi köprüsü her gün yıkılıyordu. Bu bizim hatamızdı, özellikle benim: işi böldüm, bilginin de bölüneceğini hesaplamadım.

İşe yarayan: dönen tek kişilik kol

17 Mart’tan itibaren kolu rotasyona çevirdik. Her sprint altı kişiden biri operasyon kolunda. Yoğun haftalarda ikinci bir kişi sprint’ten çekiliyor ve bu, planning’de baştan kapasiteden düşülüyor. Altı sprint sonra herkes kolda en az bir kez oturmuş oldu. Kuralları şunlar:

Siniflar
  Acil      ayni gun      (cagri merkezi, musteri etkili)
  Standart  2 is gunu     (veri duzeltme, mutabakat farki)
  Planli    sprint'e girer (rapor talebi, >1 gunluk is)

Kurallar
  1. Koldaki kisi sprint isine dokunmaz.
  2. 1 gunu gecen is kolda kalmaz: story olur, backlog'a gider.
  3. Ayni kategoride 3. talep gelirse kok neden maddesi acilir.
  4. Sira PO'nun degil, sinifin: Acil > Standart > Planli.
  5. Kol bos kalirsa kisi sprint'e yardim eder, yeni is cekmez.

İkinci kural en önemlisiydi. Kol sadece kısa işi yapar; bir günü geçen iş, gerçek bir geliştirme işidir ve refinement’tan geçmelidir. Bu kural olmasaydı kol, backlog’u atlatan bir arka kapıya dönüşecekti.

Üçüncü kural da işin büyük kısmını azalttı. 37 veri düzeltme talebinin 22’si aynı iki mutabakat farkından geliyordu. İki kök neden maddesi açıldı, iki sprint’te düzeltildi, o kategori 12 haftada 37’den 14’e indi.

Bir uyarı: “sonra” sütununun ilk üç sprint’i kalıcı iki kişilik modelle geçti. Rotasyon sonrası sayılar biraz daha iyi, ama sadece üç sprint’lik veriye bakıp ayrıca bir tablo yapmak istemedim.

Ne kaldı, ne değişti?

Kanban’a geçmek Scrum’ı bırakmak demek değildi. Seremonilerin çoğu kaldı; sadece operasyon kolu için anlamları değişti.

Review’daki değişiklik beklemediğim kadar değerli çıktı. Eskiden destek işi review’da görünmezdi; ekip iki haftanın üçte birini harcadığı işi kimseye göstermiyordu. Şimdi kol her review’da üç satır okuyor: kaç talep geldi, hangi kategori tekrar etti, backlog’a hangi kök neden maddesi gitti. PO’nun önceliklendirmesi ilk kez destek yükünü hesaba katmaya başladı.

Nasıl bozuluyor?

Melez modelin kendi hastalıkları var. Bizde gördüklerim ve gördüğümde yaptıklarım:

• Kol arka kapıya dönüşüyor. PO acele bir özelliği “küçük bir şey, kola verelim” diye sokmaya çalıştı. İkinci kural bunu yakaladı: iş bir günü geçti ve backlog’a döndü. Kural yazılı olmasaydı tartışma kişisel olurdu.
• Kol boşken yeni iş çekiliyor. Kolda sakin bir gün olunca kişi sprint’ten yeni bir madde çekmişti. Ertesi gün iki acil talep geldi ve madde yarım kaldı. Beşinci kural oradan çıktı: boş kol yardım eder, sahiplenmez.
• Rotasyon bilgi eşitsizliğini gizliyor. Muhasebe entegrasyonunu bilen iki kişi yokken gelen talepler bir gün bekledi. Çözüm, her talebin kapanışına tek satırlık “nasıl çözdüm” notu yazmak oldu. Üç ay sonra o notlar bir runbook’un başlangıcıydı.
• Plansız iş oranı düşüyor, ama kol kalıyor. Kök nedenler temizlendikçe hacim düşer. Oran %15’in altına inerse kolu kapatıp tampona dönmek gerekir. Bunu her çeyrek sonunda kontrol ediyoruz; henüz kapatmadık.

Ne izlemeli?

• Plansız iş oranı (dışarıdan gelen işe harcanan süre / toplam kapasite). Karar eşiği: %15 ve %30.
• Sınıf başına bekleme süresi medyanı. Acil sınıf aynı günü aşıyorsa kol tek kişiye yetmiyordur.
• Tekrar eden kategori sayısı. Aynı talebin üçüncü kez gelmesi bir ürün hatasıdır, destek işi değil.
• Sprint plan tamamlama oranı. Kol kurulduktan sonra düşüyorsa sızıntı var: kol işi sprint’e taşıyor.

Kontrol listesi

Sonuç

31 Ocak’taki retroya “Kanban’a geçelim” diye girdim. Haklı çıksaydım, ekibin tamamı akışa geçecek ve yeni emir tipi gibi haftalar süren, belirsiz işlerde sprint’in verdiği ritmi kaybedecektik. Yanlış soruyu sorduğum için doğru cevabı bulmam iki başarısız deneme sürdü.

Bugün altı kişinin beşi Scrum, biri Kanban çalışıyor ve bu bir tutarsızlık değil. İş iki şekilde geliyor, biz de iki şekilde karşılıyoruz. Metodoloji tartışması bitti; her çeyrek sadece bir sayıya bakıyoruz: plansız iş oranı.

Çerçeve seçmek kolaydır. Zor olan, işin sana nasıl geldiğini saymaktır.