“IT Agile Oldu Ama İş Tarafı Hâlâ Geleneksel”
Birçok organizasyon, çevik dönüşüme IT ekiplerinden başlar. Ancak çoğu zaman şu tablo ortaya çıkar:
“IT Scrum ile sprint yapıyor ama iş birimi hâlâ 3 ayda bir roadmap planı gönderiyor.”
Bu yazıda, Agile yaklaşımın IT ve iş birimi arasında nasıl hizalanabileceğini,
kurumsal gerçekliklerle çatışmadan nasıl uygulanabileceğini ve
somut örneklerle nasıl köprü kurulabileceğini ele alacağız.
1. Sorunun Kökü: Dönüşüm Asimetrisi
Nedir?
- IT ekipleri çevik framework’leri (Scrum, Kanban) uygular.
- İş birimleri ise hâlâ proje bazlı, plan odaklı ve “waterfall” düşünceyle hareket eder.
Bu, şu çelişkilere yol açar:
- IT hızlı teslimat yapmak ister, iş birimi uzun onay süreçleri uygular.
- Öncelikler sprint içinde değişemez, ama iş tarafı her hafta “acil” iş ister.
- Roadmap ve vizyon çatışması yaşanır.
2. Farklı Bakış Açıları: Roller Nerede Ayrışıyor?
| Perspektif | IT (Çevik) | İş Birimi (Geleneksel) |
|---|---|---|
| Planlama Yaklaşımı | Kısa döngüler, iteratif | Uzun vadeli, takvim bazlı |
| Önceliklendirme | Sprint bazlı, sürekli gözden geçirme | Dönemlik, hedef tabanlı |
| Değişim Karşılama | “Welcome change” felsefesi | Değişim = Plan sapması |
| Başarı Ölçütü | Teslim edilen değer, kullanıcı memnuniyeti | Hedef uyumu, bütçe disiplini |
3. Uyum İçin 3 Katmanlı Strateji
1. Ortak Sözlük Oluşturun
- “Done”, “MVP”, “Backlog”, “Sprint” gibi terimler her iki taraf için aynı anlamı taşımalı.
- Örn: İş birimi için “Done” = “test edilmiş, kullanıma hazır”, IT için sadece “koda yazıldı” ise sorun çıkacaktır.
2. Rol Hizalaması Kurun
- Product Owner, yalnızca IT’nin değil, iş biriminin temsilcisi olarak tanımlanmalı.
- PO → İş önceliğini IT’ye çeviren çevirmen gibi çalışmalı.
3. Ortak Ritüel ve Araçlar Kurun
- İş birimlerinin sprint review’lara ve demo’lara katılımı zorunlu hâle getirilmeli.
- Jira, Confluence gibi araçlara iş tarafı da erişebilmeli (okuma, katkı sağlama seviyesinde).
- Quarterly planning gibi klasik yapıların yerine rolling forecast + quarterly OKR yapılabilir.
4. Uygulamalı Senaryo: Kafada Oturtmak İçin
Kurgu:
Büyük bir bankada kredi ürünleri birimi (iş tarafı) ile IT servisleri arasında bir dijital onboarding projesi yürütülüyor.
Klasik Yaklaşım:
- İş tarafı kapsam dokümanını hazırlar.
- 3 aylık proje planı ile IT’ye iletir.
- Teslim sonunda testler yapılır.
Sorun: Süreçte müşteri ihtiyaçları değişmiş olur, çözüm ise eski sorunlara hitap eder.
Agile Yaklaşım:
- İş birimi ve IT beraber Product Backlog oluşturur.
- İlk sprintte onboarding ekran tasarımı ve 1 API yapılır.
- Sprint Review’da gerçek müşteri temsili feedback verir.
- sprintte onboarding sürecine e-imza eklenir.
- 3 sprint sonunda çalışan bir MVP çıkar.
Kazanım: 1.5 ayda ilk işleyen modül yayına alınır. Değişen yasal ihtiyaçlara sprint içinde hızla uyum sağlanır.
5. Pratik Geçiş Önerileri
| Problem | Pratik Çözüm |
|---|---|
| İş birimi çevikliği bilmiyor | 1 günlük “Agile Awareness” eğitimi (örneklerle, roleplay ile) |
| Öncelik çakışmaları | PO rolüne karar verici yetkisi olan bir iş yöneticisi dahil edin |
| Sprint’lere katılım zayıf | Sprint review’larda demo + iş birimi başarı metriklerini paylaşın |
| Herkes roadmap takıntılı | Klasik proje planı yerine “Epic > Feature > Story” görünümü kullanın |
6. Agile İletişim Köprüsü: Diller Arası Çeviri Gibi
İş birimi = “müşteri ihtiyacı” odaklı konuşur
IT = “sistemsel çözüm” odaklı konuşur
Çözüm:
Agile dokümantasyon = her iki dili ortak platformda birleştiren çerçeve
- Epik tanımı → müşteri hedefiyle yazılmalı
- User Story → teknik ihtiyaçla eşleştirilmeli
- Acceptance Criteria → hem iş hem IT açısından netlik sağlamalı
Sonuç: Agile Sadece IT Meselesi Değildir
Kurumsal Agile başarısı, yalnızca IT ekiplerinin çevik olmasıyla sağlanamaz.
Gerçek başarı: İş birimi ile IT arasında “aynı ritimde” çalışan bir değer zinciri kurmaktır.
Scrum veya Kanban sadece araçtır.
Uygulamadaki farkı yaratan: rollerin hizalanması, kararların şeffaflaşması ve iş-IT köprüsünün kurulmasıdır.
Sonraki Yazı Ne Olacak?
👉 4. yazıda, Lean bakış açısı ile Agile felsefenin nasıl entegre olabileceğini işleyeceğiz.
Muda, Mura, Muri kavramlarını Agile pratiklerle nasıl yönetiriz?
“Yalınlık olmadan çeviklik olmaz mı?” sorusunun peşine düşeceğiz.