AgileKoc ToolsÇeviklik Nedir? Plan Değil, Amaç Sabitken Uyum Sağlamak
Çeviklik plan değiştirmek değildir. Amaç sabitken yöntemi koşullara göre değiştirmektir. Scrum ekipleri için örnekler, checklist ve video.
"Plan yaptık ama hayat başka bir şey yaptı."
Scrum kullanan hemen herkesin bildiği bir cümle bu.
Bir yandan "planlı çalışalım" dersin; diğer yandan müşteri fikrini değiştirir, piyasa kayar, teknik risk patlar, ekipten biri ayrılır… Sonra bir bakarsın sprint hedefi hâlâ orada duruyor ama yol artık aynı yol değil.
İşte çeviklik tam burada başlar:
Çeviklik planı değiştirmek değildir. Çeviklik amaç değişmeden yöntemi değiştirebilmektir.
Çünkü bazen plan değil, gerçeklik değişir.
Bu yazıda, bu fikri hem Scrum pratiğine çeviriyoruz hem de kısa bir video üzerinden "liderlikte çeviklik" tarafını konuşuyoruz.
"Plan Değil Gerçeklik Değişir" Ne Demek?
Plan genelde "bildiklerimize" dayanır.
Ama sprint ilerledikçe "bilmediklerimiz" ortaya çıkar.
- Kullanıcı davranışı beklediğin gibi değildir.
- Tahmin ettiğin iş, iki kat karmaşıktır.
- Bağımlılık ekipleri gecikmiştir.
- Regülasyon/öncelik değişmiştir.
- Üretimde bir hata çıkar ve tüm odak kayar.
Bu durumlarda iki kötü seçenek var:
- Planı kutsallaştırmak: "Plan böyleydi, aynen devam."
- Amaçsız esneklik: "Plan bozuldu, ne bulursak yapalım."
Çevik yaklaşım üçüncü seçeneği söyler:
- ✅ Amaç sabit (neden yapıyoruz?)
- ✅ Yöntem esnek (nasıl yapacağız?)
Video: Liderlikte Çeviklik Notları
Aşağıdaki videoda çok net bir çerçeve kuruluyor:
"Gözlemle → öğren → uyum sağla."
Bu, Scrum'ın "inspect & adapt" mantığının birebir liderlik karşılığı.
Videoda geçen kilit fikirler şunlar:
- Stratejik esneklik: Plan değişebilir; amaç için yeni yol bulunur.
- Amaç birliği: "Nasıl"dan önce "neden"i anlatmak.
- Öz-örgütlenme: Takıma hedefi verip çözümü birlikte çıkarmak.
- Sürekli öğrenme: Her sonuç bir sonraki kararın verisidir.
Scrum Ekipleri İçin 3 Pratik Ders
1) Sprint Goal "neden"dir, Sprint Backlog "nasıl"
Sprint Goal'u bir "sonuç" gibi düşün:
"Bu sprintin sonunda hangi değeri üreteceğiz?"
Backlog ise o sonuca giden "yol haritası". Yol bozulursa, hedef aynı kalıp yol değişebilir.
Mini kontrol:
- Sprint Goal'u 1 cümle ile herkes aynı şekilde söyleyebiliyor mu?
- Goal bir "iş listesi" mi, yoksa "değer" mi?
2) Değişime uyum = "her şeyi değiştirelim" değil
Çeviklik; her gün fikir değiştirip savrulmak değil.
Yeni bilgi geldiğinde karar güncellemek demek.
Örnek:
Sprint ortasında kritik bir müşteri sorunu çıktıysa, backlog'u güncelleyebilirsin.
Ama bunu "panikle" değil; etki analiziyle yaparsın.
3) Takımın hızını artıran şey "daha çok toplantı" değil, daha iyi geri bildirim döngüsüdür
Scrum'ın gücü ritüellerde değil; ritüellerin ürettiği geri bildirim verisinde.
- Daily: engelleri görünür yapar
- Review: değer ve kullanıcı geri bildirimini getirir
- Retro: sistemi düzeltir
Uygulanabilir Checklist: "Amaç Sabit, Yöntem Esnek" Sprint Akışı
Bunu istersen sprint başında kopyala-yapıştır kullan:
Sprint Planning
- ☐ Sprint Goal: 1 cümle, ölçülebilir "değer"
- ☐ En büyük 2 risk yazıldı (teknik/bağımlılık)
- ☐ Alternatif yol var mı? (Plan B)
Sprint İçinde
- ☐ Yeni bilgi geldi mi? (müşteri/teknik/operasyon)
- ☐ Goal değişmediği halde yöntem değişmeli mi?
- ☐ Değişiklik kararı kimlerle alındı? (takım + PO)
Sprint Review
- ☐ "Ne yaptık?" değil; "Ne değer ürettik?"
- ☐ 1 öğrenim + 1 karar kaydedildi
Retrospektif
- ☐ Tek bir iyileştirme aksiyonu seçildi
- ☐ Aksiyonun sahibi ve ölçümü net
En Sık Yapılan Hata: "Çeviklik" Adına Amaçsız Koşturmak
Çeviklik yanlış anlaşılınca şu şeye dönüyor:
"Her şeye yetişelim, her şeye evet diyelim."
Bu çeviklik değil; dağınıklık.
Gerçek çeviklik şunu gerektirir:
- net bir amaç,
- kısa geri bildirim döngüsü,
- ve karar alma disiplini.