Çevik Geliştirme ( Agile ) "yüzeysel" bakıldığında bazı açılardan Türklerin çalışma, iş bitirme yönetemlerine  uygun düşüyor gibi görünüyor.Çevik Manifesto üzerinden gidersek:
 

• Planla ve takip etmek yerine, manevra yap ve adapte ol: Ülkemizin gerek ekonomik gerekse sosyolojik açıdan "aşırı" dinamik olması bizleri uzun vadeli planlar yapıp uygulamaktan zaten önemli ölçüde alı koymaktadır.Fakat bu  "dinamizm" kaos haline dönüştüğü için ( kısa süre de olsa durağan bir alanı olmayan) bizlere  değişimlere karşısında doğru noktalarda "manevra yapıp", "adapte olma" adına pek bir beceri kazandırmamıştır.Bunun yerine daha çok  olayları plansız bir şekilde kendi akışına bırakma alışkanlığı oluşturmuştur.Ayrıca bu değişim, önünü göreme bariz olarak var olduğu halde "kağıt üzerinde"  eksik verilerle zaten yapılması mümkün olmayan uzun vadeli planlar oluşturma alışkanlığı gelişmiştir. Planlama veya metod "işe" yaramadığında planı veya metodu değiştirmek yerine, pratik olarak problemi çözmek fakat bu çözümü hasır altı etmek,sanki ilgili metodun veye planın işe yaradığı izlenimini vermek de bunun cabası.Ayrıca bizler bu aşırı dinamik ortamda geliştirdiğimiz  bazı güzel çözümleri küçümsemekteyiz
• Yapılcak işi resmi sözleşme kurallarına kesin olarak bağlamaktansa, müşteri ile işbirliğine git: Bu aslında ülkemizdeki "esnaf" kültüründe eskiden beri var olan bir gelenek. Fakat "moderleşme" sancıları yaşıyan ülkemizde bu herkesin söylediğinden kolayca döndüğü veya işini geciktirdiği bir hal almıştır. Gerek iş yapan, gerek işi taleb eden taraflar arasındaki güven eksikliği bu paydaşlar arasında işbirliğinin oluşmasına fırsat vermeyen "kaygan"  bir zemin oluşturmaktadır. Taraflar,  daha doğrusu paydaşlar, ürünün başarısını için ortak çalışmaları gerektiğini kavrayamamaktadırlar.

• Bireyler ve aralarındaki etkileşimleri, kullanılan araç ve süreçlerden daha önemlidir: Ülkemizde "kurumsal" şirket olma olarak algılan  şey: yapılan işin onları yerine getiren "bireylere" olan bağımlılığı olabildiğince azaltmak. Bunu tam aksini yaptığını söyleyen firmalar ise  meşhur "gaz verme" tabirinin doğmasına yol açmıştır:[ gaz verme: şirketlerin çalışanlarına önem verdiğini göstermek üzere gerçekleştirdiği ama çalışanlar tarafından samiyetsiz bulunan her şey... ]. Çalışanlar korkularını masaya yatırıp, bunları açıkça tartışmadığı için bireyler/birimler genellikle birbirlerine karşı anlamsız "politik" yapılar / kalkanlar oluşturmakta ve bunlar "kurumsal süreç" adımları gibi sunulmaktadır: halbuki bunların çoğu iş yapma odağından uzaklaşmış korunmaya odaklı politik yapılardır.Günümüzde endüstriyel standardarttaki işlerin tek bir birey tarafından yapılması mümkün değildir, bir ekip takım çalışmasına ihtiyaç vardır.Süreçler ve araçlar ancak ve ancak bu ekip, takım üyeleri bir birleriyle etkin bir iletişime geçiyorlarsa anlamlıdır...Aksi taktirde tek başlarına bir anlam ifade etmezler.

• Çalışan yazılım, detaylı belgelemeden daha önemli/önceliklidir: Çoğu yazılım geliştirme projesi "deneysel" bir süreçtir. Ülkemizde özellikle büyük yazılım firmalarında yazılım geliştirmeya klasik "inşaat" projesi yönetimi[ afilli ismiyle PMI ]mantığıyla bakılmaktadır.Kağıt üzerinde "tasarımlar"  yapılmakta, yine kağıt üzerindeki bu tasarımlar"kontrole" tabi tutulmakta.[ bunların bir kısmının afilli ismini duymuşsunuzdur:"Kritik Tasarım Gözden Geçirme" dökümanı veya  ecnebicesi CDR ] .Bu  sırf kağıt üzerindeki klasörler dolusu analiz veya tasarım çalışması , çoğu uzun soluklu projede"yanlış" bir güvenlik hissi [ işi bitirdik , başardık] vermektedir.Modellemenin temel amacı çözeceğiniz probleme ait değişik alternatifleri görmenizi , çözümlere ait yeni kurgular oluşturabilmeniz sağlamaktadır.Kimse ciddi ölçekteki bir yazılım projesinde sırf bu modellere bakarak, çözümün doğruluğunu, eksikliği tespit edemez.İteratif Geliştirme malesef bu büyük ölçekli şirketler tarafından doğru olarak algılanmamıştır. Küçük ölçekli yazılım şirketlerinde ise durum tam tersinedir: Bir şekilde çalışan bir yazılım var ama ne mimariye ne de sistemin genel yapısına ait bir belgeleme.[ eğer var ise de üstün körü, muhatabına bir şey anlatmayan durumda]. Belgelemek kötü bir şey değildir.Belgeleme yaparken dikat etmeniz gereken şeyler
  • Bu belgelemeyi niye yapıyorum?
  • Kimler bu belgelemeden faydalanacak?Ve Ne tür fayda elde edecekler?  sorularına net yanıtlar verebilmenizdir. Ayrıca belgeleme denilince genellikle  belirli formatlar [örneğin  fiziksel veya sanal kağıda dökmek] anlaşılmaktadır.Böyle olması gerekmiyor.Doğru kişiyle yapılmış bir görsel, sözlü bir video kaydı bazen kağıda dökmekten çok daha işe yarayabilir.Belgelemede farklı formatlar kullanabilirsiniz.

Genel çerçevede aslında "çevik geliştirme" bize çok yabancı değil... :-). Ama çevik geliştirme  plansız, disipilinsiz çalışma olarak algılanmamalıdır.Yine tekrar edersek Çevik geliştirmedeki  planlı ve disiplinli çalışma, bunlara bizim klasik olarak yüklediğimiz anlamlardan da  farklıdır.