Scrum Anti-Pattern'leri: Dark Scrum, Zombie Scrum ve Mini-Waterfall Sprint'ler
Scrum anti-pattern'lerinin ortak noktası, event ve artifact'lar yerindeyken empiricism'in çalışmamasıdır. Yazı Dark Scrum, Zombie Scrum, ScrumBut, Sprint 0, hardening sprint, mini-waterfall ve taşan Sprint'leri belirti, kök neden, Guide'daki karşılığı ve ilk adımla bir tabloda topluyor; çoğunun kökünde büyük item'lar ve zayıf bir Definition of Done olduğunu gösteriyor ve ekipler için 10 soruluk bir teşhis listesi veriyor.
Sürüm notu: Bu yazı Scrum Guide 2020'yi (Kasım 2020, Ken Schwaber ve Jeff Sutherland) esas alır; Kasım 2026 itibarıyla scrumguides.org'daki güncel resmi sürüm hâlâ budur. Dark Scrum için Ron Jeffries'in 2016 tarihli yazısı, Zombie Scrum için zombiescrum.org ve "The Zombie Scrum Survival Guide" kaynak alındı.
Önce Tahmin Et
Bookstore'da kampanya sayfalarını geliştiren ikinci bir ekip var ve "Scrum yapıyor". Takvimlerinde bütün event'ler duruyor. Ama son beş Sprint'te şunlar oldu: Sprint'in ilk haftası analiz ve tasarımla geçiyor, kodlama ikinci haftanın başında başlıyor, test son iki güne sıkışıyor ve her Sprint ortalama dört item bir sonrakine taşınıyor. Daily Scrum'da direktör ekipten durum alıyor. Review'a stakeholder gelmiyor; ekip Increment'i kendine gösteriyor. Release'ten önce "stabilizasyon Sprint'i" yapılıyor.
Bu tabloda kaç farklı anti-pattern var? Ve bunlardan hangisi diğerlerinin kök sebebi olabilir? Tahminini yaz; yazının ortasındaki tablo her biri için belirtiyi, kök nedeni ve ilk adımı veriyor.
Biçimi Yapıp Teoriyi Atlamak
Guide'ın son notu bu yazının özeti gibi: Scrum'ın yalnızca bazı parçalarını uygulamak mümkündür ama sonuç Scrum değildir. Anti-pattern'lerin ortak noktası bu: event'ler, artifact'lar ve unvanlar yerinde; ama empiricism'in üç pillar'ından biri ya da birkaçı çalışmıyor. Transparency yoksa inspection yanıltıcı, inspection yoksa adaptation tesadüfi, adaptation yoksa bütün ritim bir ritüel.
Bu yazıdaki anti-pattern'ler birbirinden bağımsız değil. Mini-waterfall Sprint'ler taşan Sprint'leri, taşan Sprint'ler hardening sprint'i, hardening sprint ise Increment'siz Review'ı doğuruyor. Bu yüzden her biri için yalnız belirtiye değil kök nedene bakmak gerekiyor.
Dark Scrum
Ron Jeffries 2016'daki "Dark Scrum" yazısında bu adı, Scrum'ın biçimleri kullanılarak ekibin üzerinde güç kurulmasına verdi. Tarif ettiği tablo tanıdık: yöneticiler eski rollerini biliyor ama Scrum'daki yeni rollerini bilmiyor; Daily Scrum bir durum ve talimat toplantısına dönüyor; Sprint Planning'de iş dikte ediliyor ve "bu imkânsız" diyen geliştirici tembel ilan ediliyor; Review ekibin "başarısızlığının" gösterildiği yer oluyor; baskı arttıkça test ve tasarımdan kısılıyor, kalite düşüyor, bu da daha çok baskı getiriyor. Jeffries bunun çoğu zaman kötü niyetten değil, iyi niyetli ama yeni rollerini öğrenmemiş insanlardan doğduğunu vurguluyor.
Jeffries'in önerdiği çıkış Developers'tan başlıyor: her Sprint test edilmiş, entegre, çalışan yazılım teslim etmek ve bunu mümkün kılan teknik pratikleri öğrenmek. Çalışan yazılım görünür olduğunda korku azalıyor ve konuşma "neden bu kadar yavaş?" sorusundan "elimizdeki hızla neyi önce yapalım?" sorusuna geçiyor. Bir önceki yazıdaki pratiklerin Scrum için bu kadar önemli olmasının bir sebebi de bu.
Zombie Scrum
Christiaan Verwijs, Johannes Schartau ve Barry Overeem'in "The Zombie Scrum Survival Guide" kitabı ve zombiescrum.org sitesi bu durumu uzaktan Scrum gibi görünen ama yakından bakınca Scrum olmayan bir şey olarak tanımlıyor. Dark Scrum'da bir baskı var; Zombie Scrum'da ise kimse bir şey hissetmiyor: event'ler yapılıyor, kimse itiraz etmiyor, kimse heyecanlanmıyor, hiçbir şey değişmiyor.
Yazarların teşhis için kullandığı dört alan Guide'ın özüne denk düşüyor: hızlı teslim etmek (Sprint sonunda çalışan bir şey yok ve ekip hızın riski neden azalttığını görmüyor), stakeholder'ın ihtiyacını yapmak (stakeholder ekiple hiç konuşmuyor), sürekli iyileşmek (Retrospective'ten bir şey çıkmıyor) ve self-organization (ekibin kendi işi üzerinde söz hakkı yok). Site ekiplerin kendilerini değerlendirebileceği ücretsiz bir anket de sunuyor. Bookstore'un kampanya ekibi dört alanın üçünde zayıf: teslim yok, stakeholder yok, iyileşme yok.
ScrumBut, Sprint 0 ve Hardening Sprint
ScrumBut, Scrum.org'un yaygınlaştırdığı bir kalıp: "Scrum kullanıyoruz ama ..." cümlesinin ardından bir sebep ve bir geçici çözüm gelir. "Retrospective yapıyoruz ama zaman olmadığı için ayda bir." "Definition of Done'ımız var ama bu Sprint acil olduğu için test'leri sonraya bıraktık." Her ScrumBut tek başına masum görünür; ama her biri, Scrum'ın görünür kılacağı bir problemi tam o noktada saklar. Retrospective'i seyrekleştirmenin asıl sebebi çoğu zaman Retrospective'lerin sonuç üretmemesidir; çözüm onları atlamak değil, sonuç üretir hâle getirmek.
Sprint 0, ilk Sprint'ten önce "altyapı, mimari ve backlog hazırlığı" için yapılan ve Increment üretmeyen bir Sprint. Guide'da yok ve Guide'ın Scrum Team'in her Sprint değerli, kullanışlı bir Increment yaratmaktan accountable olduğu cümlesiyle çelişiyor. Altyapı hazırlığının gerçekten gerektiği durumda bile ilk Sprint, küçük de olsa uçtan uca çalışan bir parça hedefleyebilir: Bookstore'un ilk Sprint Goal'ü tek kalemli bir siparişin iadesiydi ve pipeline o Sprint'te, o iş için kuruldu.
Hardening sprint'i serinin altıncı yazısında gördük: Definition of Done zayıf olduğunda birikmiş test, entegrasyon ve stabilizasyon işini temizlemek için feature üretmeyen bir Sprint. Kampanya ekibinin "stabilizasyon Sprint'i" başka bir adla aynı şey.
Mini-Waterfall Sprint ve Taşan Sprint'ler
Mini-waterfall, waterfall'un fazlarını Sprint'in içine sıkıştırmak: ilk günler analiz, orta kısım kodlama, son günler test. Kampanya ekibinin board'unda bu açıkça görünüyor: Done kolonu Sprint'in ilk sekiz gününde boş, son iki günde dolmaya çalışıyor. Test'te bulunan her hata, düzeltmesi için zaman kalmadığından bir sonraki Sprint'e taşınıyor.
Kök neden genellikle iki yerde. Birincisi item'ların büyüklüğü: bir item Sprint'in tamamını sürüyorsa analiz, kodlama ve test o item içinde sıralı olmak zorunda kalıyor. İkincisi ekibin yapısı: test eden kişi Developer değil de ayrı bir ekipteyse iş ona ancak "kod bitince" gidebiliyor. İlk adım item'ları bir iki günde Done olabilecek parçalara bölmek ve test'i item'ın içine, ilk günden itibaren almak. Board'u sağdan sola yürüyen Daily Scrum da bu sırayı tersine çevirmeye yardım ediyor.
Sürekli taşan Sprint'ler ise çoğunlukla bu yapının sonucu. Her Sprint dört item'ın taşması, forecast'in sistematik olarak kapasiteyi aştığını gösteriyor; ama asıl kayıp sayıda değil anlamda: taşan item'lar "otomatik olarak" bir sonraki Sprint'e geçtiğinde Product Owner'ın sıralama kararı devreden çıkıyor. Guide'ın kuralı burada da aynı: Done olmayan item Product Backlog'a döner.
Belirti, Kök Neden, Guide, İlk Adım
Kampanya ekibinin tablosu, her anti-pattern için:
| Anti-pattern | Belirti | Kök neden | Guide'daki karşılığı | İlk adım |
|---|---|---|---|---|
| Dark Scrum | Daily Scrum'da yönetici durum alıyor, iş dikte ediliyor | Yöneticiler eski rollerini sürdürüyor; çalışan yazılım görünmüyor | Daily Scrum Developers'ın event'i; "how" yalnız Developers'ın takdiri | Her Sprint gerçekten çalışan bir Increment göstermek; yöneticiyi Review'a davet etmek |
| Zombie Scrum | Event'ler yapılıyor, hiçbir şey değişmiyor, stakeholder yok | Ekip ürünün amacından ve kullanıcısından kopuk | Review bir çalışma oturumu; Product Goal ekibin hedefi | Bir sonraki Review'a bir gerçek kullanıcı ya da destek temsilcisi getirmek |
| ScrumBut | "Scrum yapıyoruz ama ..." cümleleri | Scrum'ın görünür kıldığı problemden kaçmak | Parçalarını uygulamak mümkün ama sonuç Scrum değil | Her "ama"nın arkasındaki problemi Retrospective'te açıkça yazmak |
| Sprint 0 | Increment'siz hazırlık Sprint'i | Altyapıyı iş değeriyle birlikte kurmayı bilmemek | Her Sprint değerli, kullanışlı bir Increment | İlk Sprint Goal'ü uçtan uca en ince dilim olarak yazmak |
| Hardening sprint | Release'ten önce feature'sız stabilizasyon Sprint'i | Definition of Done'ın "kod yazıldı" seviyesinde olması | Definition of Done'ı karşılamayan iş Increment değil | Hardening'de yapılan işleri Definition of Done maddesine çevirmek |
| Mini-waterfall | Done kolonu son iki günde doluyor | Büyük item'lar; test'in ayrı kişide ya da ayrı ekipte olması | Item'lar bir gün ya da daha kısa iş parçalarına bölünür; ekip cross-functional | Item'ları bir iki günlük dilimlere bölmek, test'i ilk günden item'a almak |
| Taşan Sprint'ler | Her Sprint aynı sayıda item bir sonrakine geçiyor | Brüt kapasiteyle plan; mini-waterfall | Done olmayan item Product Backlog'a döner; Sprint Backlog bir forecast | Kapasite tablosu yapmak ve taşan item'ı otomatik taşımak yerine yeniden sıralamak |
Baştaki sorunun cevabı: yedi anti-pattern'in izi var ve büyük ihtimalle kök sebep mini-waterfall ile zayıf Definition of Done'ın birleşimi. Çalışan yazılım Sprint sonunda çıkmadığı için direktör Daily Scrum'a gelip durum topluyor (Dark Scrum), Review'da gösterecek bir şey olmadığı için stakeholder gelmiyor (Zombie Scrum), birikmiş test işi release'ten önce bir stabilizasyon Sprint'i doğuruyor (hardening sprint).
Ekip İçin 10 Soruluk Teşhis
Bookstore ekibi bu listeyi her çeyrekte bir Retrospective'te kullanıyor; "hayır" cevabı sayısı bir sonraki çeyreğin iyileştirme gündemini belirliyor:
- Son üç Sprint'in her birinin sonunda Definition of Done'ı karşılayan, kullanılabilir bir Increment var mıydı?
- Sprint Goal'ümüzü tek cümleyle, item saymadan bir stakeholder'a anlatabiliyor muyuz?
- Son Review'ın sonunda Product Backlog'da en az bir şey değişti mi?
- Son Review'a en az bir gerçek kullanıcı ya da onu temsil eden biri geldi mi?
- Son Retrospective'ten çıkan aksiyon bir sonraki Sprint'te uygulandı mı?
- Daily Scrum'da Developers birbirine mi konuşuyor, yoksa birine rapor mu veriyor?
- Done kolonuna giren item'lar Sprint'e yayılmış mı, yoksa son iki güne mi sıkışmış?
- Ekibin dışında bir kişiyi ya da ekibi bekleyerek Done olamayan item var mı?
- Son bir yılda feature üretmeyen bir "hazırlık" ya da "stabilizasyon" Sprint'i yaptık mı?
- "Scrum yapıyoruz ama ..." diye başlayan bir cümle kurduk mu ve arkasındaki problemi konuştuk mu?
Son iki soru ters işaretli: "evet" cevabı bir uyarı. Liste puan vermek için değil, konuşmayı başlatmak için. Üç "hayır"dan fazlası olan bir alan, bir sonraki Retrospective'in tek gündem maddesi olmaya aday.
Üretimde Dikkat
Anti-pattern'lerin çoğu verilerde iz bırakıyor. Done item'ların Sprint günlerine göre dağılımı mini-waterfall'u, Sprint'ten Sprint'e taşan item sayısı planlama sorununu, Review sonrası backlog değişikliği sayısı Zombie Scrum'ı, Retrospective aksiyonlarının uygulanma oranı da iyileşmenin durup durmadığını gösteriyor. Bookstore'un kampanya ekibinde Done'ların yüzde 70'inden fazlası son iki güne düşüyordu; iki Sprint'lik bir değişiklikten sonra bu oran yüzde 35'e indi.
Ölçekte anti-pattern'ler çoğalarak yayılıyor. Birden çok ekipte aynı belirti görünüyorsa kök neden genellikle ekiplerde değil kurumdadır: ayrı test departmanı, Product Owner'a yetki vermeyen bir onay zinciri, ekipler arasında paylaşılmayan bir Definition of Done. Bu, Scrum Master'ın kuruma hizmetinin alanı.
Sık Düşülen Tuzaklar
Anti-pattern avcılığı. Her pratiği bir etiketle damgalamak ("bu ScrumBut!") ekibi savunmaya iter ve konuşmayı bitirir. Etiket bir teşhis aracı; amaç ekibi suçlamak değil, kök nedeni bulmak.
Her şeyi aynı anda düzeltmeye çalışmak. Kampanya ekibi yedi anti-pattern'in hepsine aynı Sprint'te saldırsa hiçbirinin etkisini ölçemezdi. İlk adım tek bir şeydi: item'ları bölmek. Taşan Sprint'ler ve hardening sprint ihtiyacı bunun ardından kendiliğinden azaldı.
Guide'ı silah olarak kullanmak. "Guide böyle diyor" cümlesi bir tartışmayı kapatmak için değil, bir pratiğin amacını hatırlamak için kullanıldığında işe yarıyor. Guide'ın kendisi de pratiklerin bağlama göre değiştiğini ve Guide'ın onları tarif etmediğini söylüyor.
Zombie Scrum'ı motivasyon sorunu sanmak. Ekip heyecansızsa sebebi çoğu zaman ekipte değil, yaptığı işin bir kullanıcıya ulaşmamasında. Çözüm moral etkinliği değil, Increment'i gerçek bir kullanıcının önüne koymak.
Küçük Bir Deneme
★☆☆ Yukarıdaki 10 soruyu ekibinle bir sonraki Retrospective'in ilk on dakikasında cevaplayın. Cevaplarda en çok ayrışan soruyu bulun; ayrışma, ekibin aynı gerçeği farklı gördüğünü gösterir.
★★☆ Son üç Sprint'te Done olan item'ların Done olduğu günü çıkar ve günlere göre bir dağılım yap. Son iki gün toplamın yarısından fazlasıysa en büyük üç item'ı nasıl bölebileceğini yaz.
★★★ Ekibinde duyduğun üç "Scrum yapıyoruz ama ..." cümlesini yaz. Her birinin arkasındaki asıl problemi, bu problemin bedelini ve ScrumBut olmadan çözmenin ilk adımını bir sayfada topla ve Scrum Master'la paylaş.
Anti-pattern'lerin büyük kısmı Scrum'ın ne olduğunu, nereden geldiğini ve neden bu kadar az kural koyduğunu bilmemekten doğuyor. Serinin son yazısında Scrum'ın tarihine bakıyoruz: 1986'daki Harvard Business Review makalesinden 2020 Guide'ına ve 2025'te yayımlanan, resmi Guide'ın yerine geçmeyen Expansion Pack'e.