Bir kurumda çevik dönüşüm projesine başladığınızda sizi en çok şaşırtacak tablo genellikle şudur: Müşteriye dokunan ekipler hız üretiyor, ama onlara hizmet veren ekipler duruyor.
Mobil bankacılık ekibi her iki haftada bir sprint kapatıyor. Yeni özellikler planlıyor, kullanıcı testleri yapıyor, geri bildirimle şekilleniyor. Ama aynı ekip bir backend servisine ihtiyaç duyduğunda haftalar bekliyor. Çünkü o servisi üreten ekip Waterfall projesi yönetiyor. Üç aylık planlama dönemi var. Talep alındı, sıralandı, bir sonraki döneme kaldı.
İki metodoloji çakışmıyor. İki hız çakışıyor.
Sorun Metodolojide Değil, Bağımlılıkta
Waterfall yanlış değildir. Belirli koşullarda, özellikle gereksinimler sabit ve risk yüksek alanlarda hâlâ en doğru yaklaşımdır. Bir bankanın kredi risk modülü, bir kurumun muhasebe çekirdeği bu tarife girer. Orada çevikleşme baskısı uygulamak yalnızca belirsizlik üretir.
Ama müşteriye dokunan, kullanıcı davranışına göre hızla şekillenmesi gereken bir ekip Scrum yapıyorsa ve bu ekip her hafta aynı backend kapısını çalıyorsa; problem çözülmesi gereken yer Scrum değil, bağımlılık mimarisinin kendisidir.
İki Hızlı Bir Organizasyonda Neler Olur?
Biz bu tabloyu onlarca kurumda gördük. Sonuçları genellikle aynı ilerler:
1. Scrum ekiplerin sprint'leri boş kapanır. Planlanan işin bir kısmı "bağımlılık bekliyor" statüsünde bir sonraki sprint'e taşınır. Ekip hızlanmak istiyor, ama yapısal engellerle karşılaşıyor.
2. Motivasyon düşer. Çevik metodoloji benimsemiş bir ekip kendi dışındaki engellerle sürekli mücadele etmek zorunda kaldığında, metodolojiye olan inancı zamanla sarsılır.
3. Gerçek çeviklik sayılara yansımaz. Yönetim Scrum kullandıklarını görür ama beklenen hızlanmayı göremez. "Çevik çalışıyoruz ama fark yok" algısı yerleşir.
Çözüm: Kanban'ı Köprü Olarak Kullanmak
Backend ekipler için Scrum dayatmak genellikle çözüm değildir. Çünkü Scrum belirli bir ritim ve otonom karar alma kapasitesi gerektirir. Waterfall altyapısında bunları sıfırdan kurmak, asıl ihtiyacı olan hızlanmayı daha da geciktirir.
Kanban burada köprü metodoloji olarak çalışır. Neden?
- Mevcut süreci durdurmaz, görünür kılar. - WIP (iş akış sınırı) limitleriyle gerçek tıkanıklıkları yüzeye çıkarır. - Scrum ekiplerin taleplerine öncelik sırası verilmesine olanak tanır. - Hem Waterfall hem Agile ile yan yana çalışabilir.
Kanban bir ekibi "anında çevik" yapmaz. Ama o ekibin hangi taleplere, hangi sırayla, kaç gün içinde yanıt verdiğini ölçülebilir hale getirir. Bu ölçüm, sonraki adıma karar vermek için gerekli veriyi üretir.
Hangi Ekip Hangi Metodoloji?
Kurum genelinde tek bir metodoloji dayatmak yerine şu soruyu sormak daha verimlidir: *Bu ekibin çıktısı ne kadar öngörülür, ne kadar değişken?*
- Öngörülür + yüksek risk → Waterfall veya Waterfall + Kanban - Değişken + müşteriye dokunan → Scrum - Öngörülür ama yoğun talep alan → Kanban - Karma bağımlılık → Squad/tribe tasarımı + bağımlılık haritası
Bu kararı bir metodoloji kitabından değil, o kurumun gerçek bağımlılık haritasından okumak gerekir. Bu yüzden biz her dönüşüm programına önce bir olgunluk ve bağımlılık analiziyle başlıyoruz.
Sonuç
Çift hızlı organizasyon bir sorun değil, geçiş döneminin kaçınılmaz gerçeğidir. Sorun, bu çift hızı yönetmeden büyütmektir. Önde Scrum, arkada Waterfall varsa ve bu yapı yönetilmiyorsa; çevikleşme yatırımının büyük bölümü kaynak bekleyen sprint'lerde erir.
Bağımlılık haritası çıkarmadan, hangi ekibin hangi metodoloji için hazır olduğunu görmeden başlayan dönüşümler genellikle en meşgul kısımda durur: metodoloji adını koyup uygulamasına geçememek.