Ana sayfa → Bölüm 01
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 rolleri ve toplantıları 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; 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 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. Pratikte karşılıkları şunlar:
| Değer | Sahadaki karşılığı |
|---|---|
| Bireyler ve etkileşimler | 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 | 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 işbirliği | Amaç ne yapacağımızı bir yere yazmak değil, aynı şeyi anladığımızdan emin olmaktır. |
| Değişime yanıt vermek | Sprint Planning, rotayı düzenli aralıklarla düzeltme iznidir. Plan yapmamak değil, plana esir olmamak. |
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 algılanır.
- Müşteriye “sprint başladı, acil değilse bunu bir sonrakine alalım” demek zordur.
- Kısa döngüler bağlam değişimini artırır; 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 neredeyse her zaman bir önceki adımdadır.
4. Pratik senaryo: sprint’in ortasında canlıda hata çıktı
Bu, Scrum Kılavuzu’nda cevabı yazmayan sorulardan biridir. Kendi karar ağacımı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.
- 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 durdur. Hata çok büyükse dürüst ol: sprint’i iptal et, sorunu çöz, yeniden planla. Bu bir başarısızlık değil, bir karardır.
Kendi eklediğim adım: 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? Çerçeve seçimi
Scrum tek seçenek değil ve her ekip için doğru seçenek de değil. Kabaca ayrım şu:
| Çerçeve | 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. Scrum Kılavuzu ikinci gruptadır: rolleri ve etkinlikleri tanımlar ama karşılaşacağın her sorunun cevabını vermez — vermesi de beklenmemelidir.
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 öğrenmiyorsun demektir.)
- Bir junior, 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 hedefini ekipteki herkes, bakmadan söyleyebiliyor mu?
Sonuç
Agile kaosu bitirmez; yönetilebilir kılar. Hata yapmanı engellemez; hatayı geç fark etmeni engeller. İlk aylar zor geçer, retrolar 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, İbrahim Demir’in Agile serisinden ilham alıyor. Metinler bana ait; ekleme ve değişiklikler kendi ekip deneyimimden geliyor. Ayrıca Scrum Guide (2020) ve Robert C. Martin’in Clean Agile kitabı temel referanslar.