Agile Olmak ile Scrum Yapmak Arasındaki Fark
Bir ekibin bütün seremonileri eksiksiz uygulayıp yine de çevik olmaması mümkün mü? Sadece mümkün değil, sahada gördüğüm en yaygın durum bu.
- Agile bir çerçeve değil, karar verme biçimidir. Scrum Kılavuzu hesap verebilirlikleri ve etkinlikleri anlatır; ama zor anda ne yapacağını sana Manifesto’nun ruhu söyler.
- Amaç hata yapmamak değil, geç hata yapmamaktır. Altı ay sonra yanlış ürünü teslim etmek felakettir; iki hafta sonra “yanlış yoldayız” demek öğrenmedir.
- Agile kaosu bitirmez, görünür kılar. İlk sprint’lerde işler kötüleşmiş gibi görünür — çünkü sorunlar artık saklanamıyordur.
- Seremoniler bir zincirdir. Birini tek başına düzeltmek genelde işe yaramaz; kopan halka çoğu zaman bir önceki adımdadır.
Asıl derdin 2001’deki kayak gezisi değil
Agile anlatan çoğu yazı 2001’de Utah’ta bir araya gelen on yedi kişiyle başlar. Bu hikâye doğrudur ama senin derdin değildir. Senin derdin Pazartesi sabahı açtığın backlog, iki haftada üç kez değişen gereksinim, üç gündür “devam ediyor” durumunda duran bir madde ve toplantıda sorulan şu soru: “Bunu neden hâlâ teslim edemedik?”
Bu seri bu soruyla ilgili. Her bölümde bir seremoniyi ele alacağız. (Scrum Kılavuzu bunlara “etkinlik” der; sahada herkes “seremoni” diyor, Kılavuz’dan söz etmediğim her yerde ben de öyle diyeceğim.) Ama önce şunu netleştirmek gerekiyor, çünkü geri kalan her şey buna dayanıyor: Scrum yapmak ile çevik olmak aynı şey değil.
1. Neden Agile? Tahmin illüzyonuna karşı
Klasik plan öncelikli yaklaşımlar — en bilineni şelale (waterfall) — tek bir varsayıma dayanır: geleceği en baştan yeterince doğru tahmin edebiliriz. Bu varsayım güven verir, çünkü elinde bir tarih ve bir bütçe olur. Sorun şu ki bu güven ölçüme değil, belgeye dayanır.
Agile bu tahmini daha iyi yapmayı vaat etmez. Bunun yerine yanılmanın maliyetini düşürür. İki haftalık döngüler tahminini isabetli yapmaz; sadece yanıldığında bunu altı ay yerine iki hafta içinde öğrenmeni sağlar.
2. Manifesto bir dua değil, karar çerçevesidir
Manifesto’daki dört değer duvara asılmak için değil, seçim yapmak zorunda kaldığın anlar için yazılmıştır. Her biri bir karşılaştırmadır: “X, Y’den önce gelir.” Sol taraf tek başına slogandır; anlamı, sağ tarafla çatıştığı an ortaya çıkar. Pratikte karşılıkları şunlar:
| Manifesto ne diyor | Sahadaki karşılığı |
|---|---|
| Bireyler ve etkileşimler, süreçler ve araçlardan önce gelir | Jira’daki durum alanından daha değerli olan şey, birinin Daily’de “takıldım, yardım lazım” diyebilmesidir. |
| Çalışan yazılım, kapsamlı dokümantasyondan önce gelir | Yüz sayfalık analiz dokümanını kimse okumaz. Tıklanabilir bir ekran gerçek geri bildirim üretir. Sprint Review’un varlık sebebi budur. |
| Müşteri ile iş birliği, sözleşme pazarlığından önce gelir | Amaç ne yapacağımızı bir yere yazmak değil, aynı şeyi anladığımızdan emin olmaktır. Refinement bunun için var: sözleşme değil, ortak anlayış üretir. |
| Değişime yanıt vermek, bir planı takip etmekten önce gelir | Sprint sınırları, rotayı düzenli aralıklarla düzeltme iznidir: Review’da ne öğrendiğini görürsün, retrospektifte süreci uyarlarsın, Planning’de yeni yönü seçersin. Plan yapmamak değil, plana esir olmamak. |
Manifesto’nun en sık atlanan cümlesi, dört maddenin hemen altında yer alır: “Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız.” (Resmî Türkçe çeviri sıralamayı ters çevirir: orada değer verilen maddeler sağda durur, yukarıdaki tabloda solda.) Süreç, doküman, sözleşme ve plan kötü değildir; hepsine ihtiyacın var. Mesele, ikisi çatıştığında hangisini seçeceğindir. Manifesto tam olarak o an için yazılmıştır.
3. Kimsenin söylemediği kısım: başta işler karışır
Scrum’a geçen ekiplerde ilk birkaç sprint genelde daha kötü geçer. Bunun sebebi süreci yanlış uygulamak değildir. Sebep şu: Agile sorunları çözmez, onları görünür kılar.
- Retrospektif bir süreç iyileştirme alanıdır ama ilk zamanlar kişisel eleştiri olarak algılanır.
- Müşteriye “sprint başladı, acil değilse bunu bir sonrakine alalım” demek zordur.
- Geçiş döneminde iletişim yükü artar; ekip sürekli soru sorup cevap bekler.
Bu belirtiler hastalık değil, ateştir. Ateş düşürücü vermek yerine sebebe bakmak gerekir — ve sebep çoğu zaman bir önceki adımdadır.
“Görünür kılar” benim gözlemim değil, Kılavuz’un kendi iddiası. Scrum ampirizme dayanır; ampirizmin üç ayağı şeffaflık, denetleme ve uyarlamadır (transparency, inspection, adaptation) ve sıra önemlidir: görmediğin şeyi denetleyemez, denetlemediğin şeyi uyarlayamazsın. Kısa döngü, açık backlog ve retrospektif sorunları yüzeye çıkarmak için var. İlk sprint’lerdeki karışıklık, şeffaflığın çalıştığının kanıtıdır.
4. Pratik senaryo: sprint’in ortasında canlıda hata çıktı
Bu, Scrum Kılavuzu’nda cevabı yazmayan sorulardan biridir. Kendi karar sıramız şöyle işliyor — kitaptan değil, Manifesto’dan türetilmiş:
- Etki analizi. Kaç kullanıcı etkileniyor, iş etkisi ne? Küçükse bilinçli olarak ertele, backlog’a al. Önceliklendirme kararı PO’nun.
- Sprint Hedefi kontrolü. Hedefi bozmadan küçük bir eforla çözülebiliyor mu? Çözülebiliyorsa çöz, ama bunu görünür kıl.
- Takas. Sprint’i bozacaksa doğru soru “fazladan mesai yapalım mı” değil, “bunu almak için sprint’ten neyi çıkarıyoruz?” Kararı PO ile birlikte ver.
- Sprint’i iptal et. Hata Sprint Hedefi’ni anlamsız kılıyorsa dürüst ol: sprint’i iptal et, sorunu çöz, yeniden planla. Sprint’i yalnızca PO iptal edebilir; ölçüt hatanın büyüklüğü değil, Sprint Hedefi’nin hâlâ anlamlı olup olmadığıdır. Bu bir başarısızlık değil, bir karardır.
- Kararı yaz. Bu adım Kılavuz’da yok, benim eklemem. Hangi seçenek seçilirse seçilsin, kararı ve gerekçesini tek cümleyle bir yere yaz. Altı ay sonra “o sprint neden patladı” diye bakan kişi (çoğu zaman sen olacaksın) bu cümleyi arayacak. Bunu yazmayan ekipler aynı tartışmayı her çeyrek baştan yapıyor.
5. Neden Scrum? Yaklaşım seçimi
Scrum tek seçenek değil ve her ekip için doğru seçenek de değil. Kabaca ayrım şu:
| Yaklaşım | Odak | Ne zaman |
|---|---|---|
| Scrum | Karmaşıklık ve teslimat | Belirsizliğin yüksek olduğu ürün geliştirme |
| Kanban | Sürekli akış | Operasyon, destek, önceliği dışarıdan gelen işler |
| XP | Mühendislik kalitesi | TDD, pair programming, teknik mükemmellik önceliğindeyse |
Pratikte çoğu ekip melez çalışır: Scrum iskeleti, Kanban’dan gelen WIP limiti, XP’den gelen pair programming. Bu bir tutarsızlık değil; kitaba değil probleme uymak.
6. Agile kanun değil, anayasadır
Bir kanun kitabı her durumu maddeleştirir. Anayasa ilkeleri verir, yorumu uygulayana bırakır. Manifesto ikinci gruptadır. Scrum Kılavuzu arada bir yerde durur: hesap verebilirlikleri ve etkinlikleri tanımlar ama karşılaşacağın her sorunun cevabını vermez — vermesi de beklenmemelidir. Boşluğu Kılavuz’dan yeni madde bekleyerek değil, Manifesto’nun ilkeleriyle doldurursun.
Her sorunu “bu Scrum’da yazıyor mu?” diye sorarak çözmeye çalışırsan sonuç şu olur: Scrum yaparsın, Agile olamazsın.
- Kararı ilkeye dayandır, maddeye değil
- Kötü haberi erken ver — erken kötü haber risktir, geç kötü haber başarısızlıktır
- Süreci ekibin ihtiyacına göre uyarla ve neden uyarladığını yaz
- Ölçmediğin bir şeyi iyileştirdiğini iddia etme
- Toplantı sayısını çeviklik göstergesi sanmak
- Süreci ekibin sorununu çözmek yerine kendini korumak için uygulamak
- Her istisnayı kılavuzda arayıp bulamayınca donup kalmak
- İlk sprint’lerdeki karışıklığı “Agile bize uymadı” diye yorumlamak
Beş soruluk dürüstlük testi
Ekibinin gerçekten çevik olup olmadığını anlamak için bu beş soruyu sor. Hepsine “evet” diyemiyorsan, muhtemelen süreci uyguluyor ama davranışı değiştirmemişsindir.
- Son üç ayda planlanmış bir işi iptal ettik mi? (Hiç iptal etmiyorsan büyük ihtimalle backlog’a giren işi yeterince sorgulamıyorsun.)
- Kıdemsiz biri, kıdemli birinin teknik kararına toplantıda itiraz edebiliyor mu?
- Kötü haber yukarı çıkarken yumuşuyor mu, yoksa olduğu gibi mi gidiyor?
- Son retrospektiften çıkan maddelerden en az biri gerçekten yapıldı mı?
- Sprint Hedefi’ni ekipteki herkes, bakmadan söyleyebiliyor mu?
Sonuç
Agile kaosu bitirmez; görünür, dolayısıyla yönetilebilir kılar. Hata yapmanı engellemez; hatayı geç fark etmeni engeller. İlk aylar zor geçer, retrospektifler gergin olur, sprint’ler taşar. Bunlar sürecin bozuk olduğunun değil, işlediğinin göstergesidir — çünkü daha önce bunları hiç görmüyordun.
Serinin geri kalanında seremonileri tek tek ele alacağız. Sıradaki bölüm, zincirin ilk halkası: işlerin ekibe ulaşmadan önce nasıl filtrelendiği.
Bu serinin iskeleti ve birçok fikri büyük ölçüde İbrahim Demir’in Agile serisine dayanıyor. Metinler bana ait; ekleme ve değişiklikler kendi ekip deneyimimden geliyor. Ayrıca Agile Manifesto (Türkçe), Scrum Guide (2020) ve Robert C. Martin’in Clean Agile kitabı temel referanslar.