Sahte Çeviklik (Fake Agile) Nasıl Anlaşılır? Yöneticiler İçin Dönüşüm Tuzakları
Güncelleme tarihi: 17 Eyl
Kısaca Bir organizasyon Scrum toplantıları yapmasına rağmen karar alma biçimini, müşteri geri bildirimini, mühendislik pratiklerini ve sürekli iyileştirme kültürünü değiştirmiyorsa sahte çeviklik riski vardır. Agile dönüşüm ritüelleri uygulamak değil, çalışma sistemini değiştirmektir.
Sahte Çeviklik (Fake Agile); bir organizasyonun çevikliğin (Agile) temel değerlerini ve zihniyetini benimsemeden, sadece ritüellerini (Daily Scrum, Sprint, JIRA kullanımı) taklit etmesi durumudur. "Cargo Cult Agile" olarak da bilinen bu durumda, şirketler dışarıdan bakıldığında "Squad" ve "Tribe" gibi havalı isimlere sahiptir ancak içeride hiyerarşi, korku kültürü ve yavaşlık aynen devam eder.
Bu rehberde, Türkiye'deki birçok kurumun düştüğü "Mış gibi yapma" tuzaklarını ve gerçek bir dönüşümün önündeki yönetimsel engelleri derledim.
1. Yönetici Desteği: "Siz Yapın, Ben UAT'de Bakarım"
Bir çevik dönüşümün başarısız olacağının en büyük sinyali, iş sahibinin (Sponsor/Yönetici) sürece dahil olmamasıdır.
İşin sahibi; "Benim çok işim var, ne istediğimi söyledim ya, siz yapın ben sonra bakarım" diyorsa, o şirkette çeviklikten bahsedilemez.
Gerçek: Dönüşüm, sadece yazılım ekiplerinin değil, iş birimlerinin de iş yapış şeklini değiştirmesini gerektirir.
Hata: Yönetimin hiçbir alışkanlığını değiştirmeden, sadece IT ekiplerinin "hızlanmasını" beklemesi, dönüşümü baştan öldürür.
2. Şekilcilik Tuzağı: Duvarlarda "Agile Ormanı" Yaratmak
Farklı sektörlerden birçok şirketin ofisine girdiğinizde duvarlarda kocaman "TRUST" (Güven), "TRANSPARENCY" (Şeffaflık) yazdığını görürsünüz.Tecrübemiz şudur: "Bir şirket ofisinin duvarlarına büyük harflerle ne yazıyorsa, o olay o şirkette yoktur."
Duvarları renkli post-itlerle donatmak, toplantı odalarına "Agile Ormanı" gibi isimler vermek veya departman adını "Krediler Garajı" yapmak sizi çevik yapmaz.
Soru: İsimlere, olayın şekline neden bu kadar takılıyorsunuz? Müşteriniz sizin "Garaj" isminizle ilgilenmiyor; "Hatalı ürün üretiyor musunuz?" onunla ilgileniyor. İsimleri değil, kafaları değiştirin.
3. "Tavuk Yoktur" Sendromu (Hedefsizlik)
Birçok şirket, neden dönüştüğünü bilmeden, sadece "rakip yaptı diye" veya "moda olduğu için" Agile dönüşüm başlatır.
Danışman sorar: "Dönüşümle neyi iyileştireceğiz?"
Müşteri cevap verir: "Daha hızlı olalım."
Danışman sorar: "Mevcut hızınız nedir?"
Cevap: "Bilmiyoruz, ölçmüyoruz."
Bu durum, Temel fıkrasına benzer:Temel eczaneye girer "Tavuk var mı?" der. Eczacı "Yok" der. Ertesi gün yine sorar. En sonunda eczacı cama kocaman "TAVUK YOKTUR" yazar. Temel ertesi gün gelip sorar: "Tavuk ne zaman gelecek hemşerim?"
Ders: Derdinizi doğru ifade etmezseniz (Tavuk arıyorsanız), çözümü yanlış yerde (Eczanede/Agile'da) ararsınız. Neyi iyileştireceğinizi (Müşteri memnuniyeti mi? Time-to-market mi?) verilerle belirlemeden dönüşüme başlamayın.
4. İki Haftalık Sprint Koşmak Sizi Kurtarmaz
Sevgili takımlar; sadece 2 haftalık periyotlarla (Sprint) çalışıp, her sabah 15 dakika ayakta toplantı (Daily) yaparak Agile olamazsınız.
Konu hakkında yazılmış rastgele iki kitap okursanız, yaptığınız şeylerin olması gerekenin %1'i bile olmadığını görürsünüz.
Eğer Sprint sonunda "canlıya çıkılabilir" (Done) bir ürün parçası yoksa,
Eğer retrospektif toplantılarınız sadece "havadan sudan" konuşmalarla geçiyorsa,
Eğer yöneticiler araya sürekli "Acil iş" sokuyorsa;Siz Agile yapmıyorsunuz, sadece "Waterfall'ı küçük parçalara bölüp daha stresli hale getiriyorsunuz."
5. Sertifika Koleksiyonculuğu
Şirketinizdeki herkese PSM, PSPO, PAL gibi sertifikaları aldırdığınızda dönüşmüş olmuyorsunuz.LinkedIn'de boy boy paylaştığınız o sertifikalar günün sonunda işi yapmıyor.
Kağıt parçalarına odaklandığınız kadar işinizi nasıl daha iyi yapacağınıza odaklansanız, projelerinizin başarılı olma şansı artar. Sertifikayı veren kurumlar bile basılı halini göndermeye tenezzül etmiyor, PDF üretip üzerine isminizi yazıyor. Ne kadar değerli olduğunu buradan anlayabilirsiniz.
Ne Yapmalı?
Sahte Agile döngüsünden çıkmak için;
Şekle değil öze odaklanın: İsimleri değiştirmeyi bırakın.
Ölçün: Neyi iyileştirmek istediğinizi verilerle (DORA metrikleri vb.) belirleyin.
Yönetimi dahil edin: Liderlerin sadece desteklemesi yetmez, davranışlarını değiştirmesi gerekir.
Yöneticilerinizi, Agile Koçlarınızı ve Dönüşüm Liderlerinizi gerçek bir zihniyet değişimine hazırlamak için Gelişim Programlarımızı inceleyebilirsiniz.
Bu yazı, Onur Özcan'ın "Nasıl Agile (Çevik) Olunmaz?" serisinin küçük bir bölümüdür. Toplamda 4 ayrı blog yazısı olacak şekilde paylaşılmaya devam edecek. Serinin tamamını beklemek istemiyor ve hemen okumak istiyorsanız, hazırladığımız e-kitabı buradan ücretsiz indirebilirsiniz.
Sıkça Sorulan Sorular
Bir şirketin gerçekten Agile olup olmadığı nasıl anlaşılır?
Takımların hangi ritüelleri yaptığına değil, müşteriden ne kadar hızlı geri bildirim aldığına, kararların ne kadar hızlı verildiğine, çalışan yazılımın ne sıklıkla teslim edildiğine ve ekiplerin problemlerini ne kadar hızlı iyileştirebildiğine bakmak gerekir.
Fake Agile ile kötü uygulanmış Scrum aynı şey midir?
Tam olarak değil. Scrum’ın bazı pratiklerini yanlış uygulamak yöntemsel bir problem olabilir; Fake Agile ise organizasyonun çevik görünmesine rağmen temel yönetim ve çalışma biçimlerini değiştirmemesi gibi daha geniş bir problemi ifade eder.
Agile dönüşümün başarısı hangi metriklerle ölçülebilir?
Time-to-market, lead time, cycle time, deployment frequency, change failure rate, müşteri geri bildirimi ve çalışan deneyimi gibi göstergeler birlikte değerlendirilebilir. Ölçümler dönüşüm başlamadan önce belirlenen iş problemiyle ilişkilendirilmelidir.
Agile dönüşüm neden başarısız olur?
En yaygın nedenlerden biri dönüşümün yalnızca takımların sorumluluğu gibi görülmesidir. Yönetim biçimi, önceliklendirme, organizasyonel bağımlılıklar ve mühendislik pratikleri değişmeden yalnızca Scrum ritüelleri eklemek kalıcı sonuç yaratmaz.
Agile dönüşüm ne kadar sürer?
Tek bir standart süre yoktur. Takımlar bazı çalışma pratiklerini birkaç sprint içinde değiştirebilir ancak liderlik davranışları, organizasyon yapısı ve mühendislik yetkinliklerinin dönüşmesi daha uzun ve sürekli bir gelişim süreci gerektirir.
Agile dönüşüme nereden başlanmalı?
Önce çözülmek istenen iş problemi ve mevcut durum netleştirilmelidir. Ardından sınırlı bir alanda değişiklik yapılmalı, sonuçlar ölçülmeli ve işe yarayan uygulamalar öğrenilerek organizasyona yayılmalıdır.
