İyi Mühendis Olmak ya da Olmamak

Üniversite'de iyi bir eğitim aldığımı düşünerek iş hayatına atıldığımda temel hedefim belki birçoğumuz gibi "iyi bir mühendis" olmaktı. Üniversite yıllarındaki projeler, ödevler ve sınavlar hep zor teknik problemlere çözüm bulma üzerineydi. Biraz hocalarımızın teşviki ile biraz da meraktan en iyi ve idealist mühendislerin akademik yolda ilerlediğini düşünerek öncelikle okulda asistan olarak kaldım. Bir yılın sonunda akademik dünyada çalışılan problemlerin bir kısmının aslında günlük hayata uzak olduklarını ve hatta bazılarının uygulanabilir olmadığını gördüm. Akademik dünyada gerçekten günlük hayata dair problemlerle uğraşanları tenzih ederim, ama benim üzerinde çalıştığım konular böyle değildi. Bu problemler bana heyecan vermedi ve asistanlıktan ayrıldım. 

Özel sektöre geçerken temel amacım gerçek anlamda mühendisliği deneyimlemekti. Yıllar geçtikçe özel sektörde de aslında gerçek anlamda mühendislik problemlerinin pek fazla olmadığını gördüm. Yaptığım birçok işi başkaları da yapabilirdi hatta mühendis olmaları da şart değildi. İlk yıllarıma ait hatırımda kalan mühendislik problemleri oldukça az, en önde gelen örneğini sizinle paylaşmak isterim. Üzerinde çalıştığımız projede ülke genelinde bir bilgisayar ağı kurulması ve sonrasında farklı noktalarda çalışacak sunucuların ayağa kaldırılması gerekli idi. Bilgisayar ağını kurarken modem maliyetinin projede olmadığını gördük. Modemler de X25 altyapısında kullanılabilen özel modelde idi ve tanesi 1000 USD'nin üzerinde idi. Ayrıca yurtiçinde yoktu ithal edilmesi gerekiyordu. Toplam 80 modem gerekmekteydi. Ya şirket bu modemleri alacak ve bunu zarar olarak yazacaktı ya da yönlendiricileri (router) modemsiz olarak veri santrallerine bağlamak gerekecekti. Haliyle bu konuda yönlendirici üreticisi ile temasa geçtik, ancak bunu daha önce yapmadıklarını ve nasıl yapılacağına vakıf olmadıklarını bildiren bir yanıt aldık. Bunun gerçek anlamda bir mühendislik problemi olduğunu düşünüp kolları sıvadım. Üniversite yıllarında bilgisayar ağları dersi almıştım. Bize çeşitli protokoller ve ağ topolojileri anlatılmıştı. Ancak işime yaramıyordu, önce yönlendirici ve veri santrallerinin nasıl çalıştığını öğrendim, sonra yönlendiriciyi kumanda edecek kodu yazmaya başladım. 2 hafta boyunca veri santraline kapanıp yazdığım kodla denemeler yaptım. Ve başardım! Gerçekten de modemsiz olarak sadece yönlendirici ile bilgisayar ağını çalıştırabilmiştim. Bu çözümü kullandık ve ciddi bir masraftan kurtulduk. Bundan aldığım keyfi başka birçok şeyden almadım. 16 yıllık özel sektör tecrübemde bu şekilde deneyimler maalesef oldukça azdı. 

Mühendis için bir çok farklı tanım var ama yıllar içinde benim gözümde mühendis şöyle canlandı: teknik bilgiyi insan ihtiyaçlarını karşılamak veya insanların problemlerine çözüm sunmak için akıllıca ve sistematik olarak kullanan kişi. İhtiyaç/problem ne kadar karmaşık, kısıtlar ne kadar zorlayıcı ise mühendislik becerisi o kadar kıymetli oluyor kanaatimce. İyi mühendis olmak da bu tür durumlarda önem kazanıyor. Böyle mühendislerle maalesef çok karşılaşma şansı olmuyor. Yıllar içinde bazı yabancı firmalarda gerçekten konusuna hakim ve iyi mühendis olan insanlarla çalışma fırsatım oldu. Bir çoğunun ortak özelliği yönetici sıfatı taşımamaları idi. Hatta bazıları kendi yöneticilerinden daha fazla para kazanıyorlardı. Bunlardan bir tanesine iyi mühendis olmanın sırrını sorduğumda aldığım yanıt etkileyiciydi: "daha çok ve etkili düşünme (more and effective thinking)". Ülkemizde ise genç ve başarılı mühendisler genelde yönetici kadrolarına geçiyor çünkü mühendis olarak kalmaları halinde daha iyi bir gelir elde etme imkanları olmuyor. Hatta kurumsal yerlerde ilişki yönetimi, sunum yapabilme becerisi, mühendislik becerisinin de önüne geçebiliyor. Maalesef "sunum mühendisi" kavramı bile ortaya çıkmış durumda. Ayrıca yıllarca biriktirdiği mühendislik deneyimini bir kenara bırakıp yönetimsel becerilerini geliştirmeye odaklanan değerli mühendisler var. Kimisi başarılı olabilirken kimisi yönetim alanında aynı başarıyı sergileyemiyor. Yöneticilik ve liderlik farklı yetkinlikleri gerektiriyor (İlgili Makale: İnsan Nasıl Yönetilir?). 

İyi bir mühendisin ilk özelliğinin tecrübe olduğunu düşünüyorum, bu tecrübe yıllara bağlı kıdem değil elbette. Gerçekten üzerinde uğraştığı ve tamamladığı mühendislik projelerinin sayısı ve zorluğu. İkinci önemli özelliği güncel araç ve ekipmanları iyi bilmesi bunları ustalıkla kullanabilmesi. Burada bir parantez açıp araçlarda ustalaşmanın bir yansıması olarak bir çoğumuz bir dolu sertifika alıyor ve bunları iyi mühendis olduğumuza kanıt olarak sunuyoruz. Aslında bunlar adı üstünde araç ve kendi başlarına bize doğru çözümü gösteremezler. Sonuncusu ise beceri. Bu kavramı tecrübelerini problemi çözmek için sentezleme ve araçları da bu çözümde etkin şekilde kullanabilme yetisi olarak düşünebiliriz. Mühendisliğin çıkış kelimesi Latince ingenium (akıllılık, beceriklilik), aslında tüm söylediklerimi özetliyor.

Birçoğumuz için kariyer hedefi CEO (İlgili Makale: Başarılı bir CEO olur muydunuz?) veya C seviye yönetici olabilmek. Neden bunu istiyoruz, çünkü geliri ve prestiji yüksek. Mühendislik yapanlar ise üreten kesimi temsil ediyor ve maalesef çok yüksek prestijle görev yapmıyorlar. Birçoğumuz aslında mesleklerimizde tam da ustalaştığımız yıllarda daha yüksek gelirler için bu yolu ya kendimiz bırakıyoruz veya "terfi" ederek terk etmek durumunda kalıyoruz. Bu da mühendis kalmanın çok da cazip olmadığı bir ortam yaratıyor. Son dönemde kıymetli mühendislerini bu yolla kaybeden bazı kurumlar teknik kariyer haritaları sunmaya da başladılar. Yeterli mi, değil elbette. Çünkü yönetici olmak hala daha cazip.

Yine mühendislik gibi geçmişi ilk insanlara kadar uzanan doktorluk mesleğine baktığımda ise durumun farklı olduğunu gözlemliyorum. Hastanelerde en yüksek ücreti alanlar ve en çok prestije sahip olanlar baş hekimler değil, hastane müdürleri hiç değil, bilakis mesleğini icra eden iyi hekimler ve cerrahlar. Bir hekimin kariyer haritasında "başhekim" olma gibi bir hedef genelde olmuyor. Acaba gün gelip bizde de iyi mühendis olma aynı değere ulaşır mı? Kim bilir, belki...

Çevik Yöntemlerde İdeal Takım: T-Biçimli Takım

Çevik yöntemlerde rollerin farklı olduğunu ve bu rollere uygun profillerin de farklı olduğunu daha önce belirtmiştik (İlgili Makaleler: Çevik Yöntemlerde Roller, Çevik Yöntemlerdeki Rollere Uygun Profiller ). Geliştirme takımı üyesinin temel seviyede çevik yöntemleri bilmesi gerektiğini, uyumlu, kendi kendine organize olabilen, sorumluluk sahibi, takım oyuncusu, pro-aktif ve yeterli uzmanlığı taşıdığını belirtmiştik. Bu özelliklerde olan bir ekibin iyi bir takım olması için başka nelere dikkat etmek lazım? İdeal bir geliştirme takımı nasıl olmalı? İdeal takımı oluşturabilmek için mükemmel kişilere mi ihtiyaç var? En iyi teknik uzmanları bir araya getirirsek ideal bir takım kurmuş olur muyuz? Bu takım üretken olur mu? Bu yazıda bu soruların yanıtı arayacağız.

Şekil-1

Çevik dünyada herkesin sadece tek bir konuda uzman olması ve sadece kendi işini yapması beklenmiyor. Bilakis takım olarak ilerleme ve birlikte iş yapabilme ön planda. Bu da takım üyelerinin kendi uzmanlık alanları dışında diğer konularda da bilgi birikimlerini artırmaları ve katkı yapabilmeleri ihtiyacını doğuruyor. Böylece bu yazının da başlığında yer alan “T-biçimli” kavramı ortaya çıkıyor. Bu kavram son dönemde yurt dışında özellikle çevik yaklaşımları kullananlar arasında daha çok popüler olmakta. T-biçimli kişi kısaca bir konuda derinlemesine uzmanlığı varken başka konularda da bilgisi/yetkinliği olan kişi olarak karşımıza çıkıyor. Şekil-1’de en basit haliyle, yazılım geliştirme alanında derin bilgi birikimi olan bir kişinin analiz ve test süreçleri hakkında da temel seviyede bilgi sahibi olması gösteriliyor.

Şekil-2

Şekil-3

Herkesin her alanda uzmanlık seviyesi değişkenlik gösterebilir, örneğin yazılım geliştirmede uzman kişi test konusuna daha aşina olabilir, Şekil-2’de gösterildiği gibi. Şekil-3’de ise yazılım geliştirme alanında uzman bir kişinin yine kendi uzmanlık alanındaki alt alanlardaki durumunu gösteriliyor. Buna göre Java tecrübesi olan bir kişinin diğer konularda da belli bir bilgi seviyesinde olduğu anlaşılıyor. T-biçimi içinde iş alanı bilgisinin de eklenmiş olması çok önemli, bu boyuta ilişkin örnek Şekil-4’te yer alıyor. Teknik ve iş bilgisi boyutlarının birleşmesi geniş bir yetkinlik yelpazesi ortaya çıkarıyor. Buna ait örnek,  bir yazılım uzmanı özelinde Şekil-5’teki gibi gösterilebilir.

Şekil-4

Şekil-5

Kişilerin yetkinliklerini bir araya getirince, takımların uzmanlık alanları ortaya çıkar. Takımlar da tıpkı bireyler gibi belli konularda daha derinlemesine bilgi sahibi iken, bazı konularda daha yüzeysel bilgi sahibi olabilirler. Bu haliyle, takımın yetkinlikleri de T harfine benzediği için T-biçimli Takım (T-Takım) kavramı ortaya çıkıyor. T-Takım’da herkes aynı uzmanlık alanlarından olmaz, birbirini tamamlayan ve destekleyen alanlardan kişilerin bir araya gelmesi önemlidir. Örneğin sadece yazılım geliştirme uzmanlarından T-Takım kurulmaz. Muhasebe konusunda bir ürün üzerinde çalışacak ekibin yetkinlik gösterimi Şekil-6’da yer alıyor.  

Şekil-6: T-Takım

Peki T-Takımın faydaları nedir?

• En başta kişi bağımlılığını azaltır. Takımda bir kişinin yokluğunda işler durmaz. Bir çok projede başarısızlık nedenlerinden birisi kişiye bağımlı olunmasıdır. Bu kişinin herhangi bir nedenle işini beklendiği gibi yapamaması projeyi de haliyle sekteye uğratır. T-Takımlarda bu gibi durumlar daha zor yaşanır.
• Takım üyelerinin birbirlerini daha iyi anlamalarını ve daha etkin işbirliği yapmalarını sağlar. Eğer sadece kendi uzmanlık alanınızda bilginiz varsa ve diğer konularla ilgilenmiyorsanız, takım arkadaşlarınızın yaptığı işleri iyi anlamadığınız için hem onları küçümseyecek hem de yeterince işbirliği yapmayacaksınız. Eğer yüzeysel de olsa bilginiz varsa empati yapma ve anlama imkanınız olacak. Bu sayede daha etkili iş birliği fırsatınız olacaktır.
• T-Takım müşteriden aldığı bir talebi uçtan uca geliştirip yine müşteriye sunulabilir. Hem müşteriyi anlar, hem de gelen talebi bunu gerekli yazılım geliştirme adımlarını tamamlayıp test edilmiş bir ürün olarak yine müşteriye sunar. Başka kişi ve takımlara bağımlılığı ya yoktur ya da çok azdır.

İdeal bir T-Takım kendi içindeki gelişime de önem verir. Takım üyelerinde bireysel olarak T-biçimli olmaları için diğer takım üyelerinin aktif desteği sağlanır. Takımın toplamdaki etkisini artırmak ve daha iyiye ulaşma çabasını hep barındırır. Yeni kurulan bir takımın bu noktaya ulaşması zaman alır. Bu nedenle T-Takımlar oluşturulduktan sonra, bunların gerçek performansları ortaya çıkana kadar desteklemek gerekir. T-Takım ortalama olarak 6 ay – 1 yıl arasında üretken hale gelir. Bu üretkenliği korumak için takımı da bozmamak ve değiştirmemek önemlidir. Uzun süreli örneğin 3-4 yıl birlikte çalışan T-Takımlar çok daha etkin hale gelmektedir.

T-Takım, çevik çalışan büyük ve kurumsal yerlerde (İlgili Makale: Büyük Ekipler Çevik Yöntemleri Uygulayabilir mi?) de kullanılabilir. Proje ne kadar büyük olursa olsun, çekirdeğini takımlar oluşturur. Bu takımların T-Takım olması, hem takımların birbirlerine bağımlılığını azaltır, hem de farklı lokasyonlarda çalışabilme imkanını verir.

Günümüzde başarının anlamı (İlgili Makale: Başarıya Farklı Bir Bakış) yeniden keşfediliyor. Bu çerçevede birlikte başarma ve takım olma konularının önemi giderek daha iyi anlaşılıyor. Takımlar kurulurken farklı kabiliyetleri olan ve birbirini tamamlayan yetkinliklere sahip kişileri bir araya getirme ve T-Takım oluşturmanın önümüzdeki günlerde daha çok konuşulacağını düşünüyorum.

Çevik Yöntemlerde Proje Yönetim Ofisi’ne (PYO-PMO) İhtiyaç Var mı?

Proje Yönetim Ofisi’nin (PYO, Project Management Office-PMO) projeler arası eş-güdüm sağlayan, projeleri izleyen ve raporlayan bir organizasyon parçası olduğunu daha önce aktarmıştık (İlgili Makale: Proje Yönetim Ofisi (PYO - PMO) Ne İşe Yarar? ). Öte yandan çevik yöntemler, hem kurumsal ölçekte hem de proje ölçeğinde çalışma şeklini temelinden değiştirmekte; gerek sunduğu roller, gerek değerleri, gerekse öncelikleriyle iş yapış tarzını tamamıyla farklı bir yöne doğru çevirmekte (İlgili Makaleler: Çevik Yöntemlere Yolculuk, Çevik Yöntemlere Geçerken Direnç Noktaları, Çevik Yöntemlerde Sık Yapılan Hatalar). Çevik yöntemlere geçişle birlikte proje yöneticilerine ne olacağı, onlara ihtiyaç kalıp kalmadığı başlı başına bir tartışma konusu. Biz bu yazıda farklı bir noktaya odaklanacağız: Çevik Yöntemlerde PYO. Çevik yöntemlerin hemen hepsi kendini organize edebilen takımlardan ve bu takımların müşteriye doğrudan sunabildiği ürünlerden bahsediyor. Planlama bu takımlara bırakılıyor. Yine ilerlemenin izlenmesi de takımın kendi başına yapabildiği bir aktiviteye dönüşüyor. PYO’ya yapacak iş kalmıyor gibi görünüyor. Bu durumda çevik dönüşüm yapılan kurumlarda, bin bir zahmetle kurulmuş PYO’nun kapısına kilit mi vurmalı? 

Çevik yöntemleri kullanırken de PYO’nun katkıları olabilir. Çevik projelerle çalışılan ortamlarda PYO’nun da çevik çalışmayı destekleyici bir yapıya bürünmesi, kurumsal çevikliği artırıcı alanlara odaklanması gerekir. Ancak bu şekilde çalıştığı zaman “Çevik PYO” demek doğru olur. Çevik PYO, temel olarak alttaki alanlarda katkı sağlayabilir:

• Ürün Yönetimi: Çevik PYO, portföydeki tüm ürünlerin durumları ve ürünler arası bağımlılıkların koordinasyonu konusuna odaklanabilir. Bu sayede Ürün Sahipleri (Product Owner), Ürün Talep Listelerini (Product Backlog) düzenleme, maddelerin önceliklerini büyük resmi görerek daha iyi belirleme şansına sahip olacaklardır. Özellikle Ürün Yol Haritaları (Product Roadmap) arasındaki eş güdümde de önemli rol oynayacaktır.
• Proje Başlatma: Proje taleplerine doğru Ürün Sahibi’nin belirlenmesi, projelerin çalışmaya değer olup olmadıklarının tespiti gibi konularda kurumsal ölçekte katkı sağlayacaktır.
• İnsan Kaynakları: Çevik takımların kendini yönetebildiğini biliyoruz. Çevik PYO’nun takım içi işlere karışmasını beklemiyoruz. Ancak takımı kurarken doğru takım üyelerinin belirlenmesi ve bir araya getirilmesinde Çevik PYO’nun katkısı olacaktır.
• Metrikler: Projeler içinde takımların kullandığı İlerleme Grafiği (Burndown Chart), Hız (Velocity) vb. metriklerin (İlgili Makale: Çevik Yöntemlerde Performans Ölçümü) konsolide edilmesi ve üst yönetim  için kurumsal ölçekteki durumun gösterilmesi de Çevik PYO’nun görev alanına girecektir. Burada önemli nokta Çevik PYO’nun yeni bir dolu metrik üretip takımların bu bilgileri sağlaması yönünde bir yaklaşımda bulunmamasıdır, çünkü takımlara ek iş yükü çıkarılmaması bekleniyor.
• Uyum: Takımların takım dışı kurumsal ortamlarla uyumu, takımlar arası uyum, üst yönetim ve takımların iletişimi ve uyumu Çevik PYO’nun çalışma alanına girmektedir.
• Eğitim ve Koçluk: İç ve dış eğitmenlerle iş birliği içinde takımların ihtiyaç duyduğu eğitimlerin planlanmasında Çevik PYO görev alacaktır. Ayrıca yeni başlayan çevik takımlara Çevik PYO içinden veya dışından bulacağı deneyimli kişilerle koçluk hizmeti de verebilmesi gerekir. İdealde çevik danışmanların ve koçların Çevik PYO çatısı altında toplanmasıdır. Kurumda yeterince bu tecrübede koç yoksa dışarıdan da alınabilir.
• Çevik Metodoloji Seçimi: Çevik dünyada birçok farklı yaklaşım/yöntem/metodoloji bulunmaktadır. Kurumlar genelde dönüşüm yolculuklarında temel bir yöntemin örneğin Scrum veya Kanban’ın adaptasyonu ile sürece başlamaktadır. Tüm ürünler, projeler, müşteriler ve takımlar aynı olmadığı için bazen birden fazla yöntemin de kullanılması gerekebilir. Hem yöntem seçilmesinde hem de farklı ekiplerin farklı yöntemleri kullanmasında Çevik PYO’nun  desteği olacaktır. 
• Sürekli Gelişim: Çevik yaklaşımın en temel özelliği olan sürekli gelişim ve daha iyiyi aramada, hem takımlar özelinde hem de kurumsal ölçekte Çevik PYO kılavuzluk yapabilir. Dünyadaki yeniliklerin takımlara akmasına yardımcı olabilir. Kurumsal ölçekteki gelişim aktivitelerini koordine edebilir.

Bütün bu faaliyetleri yaparken Çevik PYO’nun en belirgin özelliği diğer çevik rollerde olduğu gibi dinleyen, katkı sağlayan ve işleri kolaylaştıran tarafta olmasıdır (İlgili Makale: Çevik Yöntemlerdeki Rollere Uygun Profiller). Direktif veren, yöneten ve tepeden bakan bir yaklaşım çevik prensiplere uygun olmayacaktır. 

Her çevik kurum için Çevik PYO gerekli mi? Olmayabilir. En temel yalın öğreti “israfı önle” gözlüğünden baktığımızda kurumun büyük olmadığı durumlarda; takımların uzun yıllardır çevik yaklaşımla birlikte çalıştığı ortamlarda; sürekli gelişimi herkesin içine sindirip uygulayabildiği yerlerde; eğitim, koçluk ve uyum konularının işlediği yapılarda Çevik PYO gerekli olmayabilir. Çevik PYO’nun gerekliliğini artıları ve eksileri ile her kurum özelinde ayrı ayrı inceleyip karar vermek en doğrusu olacaktır. 

Çevik Yöntemlere Geçerken Direnç Noktaları

Kurumunuzda Çevik Yöntemlere geçişe karar verildi veya verilmek üzere, dönüşüm süreci (İlgili makaleler: Çevik Yöntemlere Dönüşüm, Çevik Yöntemlere Yolculuk, Çevik Yöntemlerde Performans Ölçümü) başlamak üzere ise bazı zorluklar sizi bekliyor demektir. Herkesin çevik yöntemlere geçiş için can attığını düşünüyorsanız, yanılıyorsunuz. Dönüşüm sürecinde insanların desteğini alabilmek için ikna etmeniz gerekiyor. Hatta ikna etmeniz gereken çok kişi olduğunu göreceksiniz. Bu ikna sürecinde farklı konumlarda çalışan farklı kişilerin birbirinden farklı direnç noktaları olacak.  Kaygı, korku, itiraz, ön yargı vb. hepsini direnç noktası olarak niteledim. Kimi zaman bu direnç noktaları açıkça size söylenecek, kimi zamansa içte tutulup gizlenecek. Bu direnç noktalarını önceden bilmek buna göre hazırlanmak direnç noktalarını aşmanızı sağlayabilir. Bu amaçla en sık olanları altta özetlemeye çalıştım.

Öncelikle takımdan başlayalım:

• Çok fazla toplantı var! Özellikle ayaküstü (stand-up) toplantılarının her gün yapılacak olması, henüz bu toplantıları deneyimlememiş kişilerde çevik yöntemlerde çok toplantı yapıldığı düşüncesini çağrıştırabiliyor. Burada en iyi argüman, sürenin 15 dakika ile sınırlı olduğunu ve bu kısa toplantının, saatler süren eski usul başka toplantılardan kurtulmak için faydalarını anlatmak.
• Eğer baştan tasarımı yapmazsak, mimarimiz başarısız olur! Çevik yöntemlerde ürünün baştan nasıl olacağının düşünülmediği, tasarımın yapılmadığı yönünde yanlış bir algı var. Bunun tam tersine Ürün Vizyonu (Product Vision) en baştan ortaya konuyor, bunu destekleyici nitelikte Ürün Yol Haritası (Product Raodmap) da hazırlanıyor. Vizyon ve Yol Haritasını ortaya koyabilmek için elbette genel hatlarıyla teknik tasarım da ortaya konuyor. Bunun anlamı tüm tasarımı en ince detayı ile baştan yapmak değil elbette. Tasarımın detayları Döngüler (Iteration, Sprint) içinde oluşturuluyor. Teknik mükemmeliyet ve güçlü tasarım bilakis çevik dünyada çok önemsenen prensipler (İlgili makale: Çevik Yöntemler ve Teknik Mükemmellik).
• Aynı yerde çalışmıyoruz, dolayısıyla çevik olamayız! Aynı yerde çalışma (co-location) takım içi iletişimi kuvvetlendirmek için önerilen bir yaklaşım. Eğer coğrafi olarak farklı yerlerde çalışanlardan kurulu takımlar varsa,  çevik yöntemler yine uygulanabilir. Belli periyotlarla takımı bir araya getirecek yüz-yüze toplantılar kurgulanabilir. Özellikle Döngü Sonu Gözden Geçirme (Iteration Review, Sprint Review and Demo) toplantıları, Döngü Planlama Toplantıları ve Retrospektifler (İlgili makale: Çevik Yöntemlerde Retrospektif) bu amaca çok uygundur. Kalan zamanda teknolojinin nimetlerinden faydalanıp telekonferans, videokonferans, mesajlaşma (Google Talk, Skype, WhatsUp vb.) kullanılarak iletişim güçlendirilebilir.

Yönetime bakalım:

• Çevik yaklaşımda uzun dönemli planlama yapılamıyor, bütçelerimizi böyle yönetemeyiz! Bu çok temel bir yanılgı, çevik yöntemlerde kapsam, bütçe ve zaman yönetimi çok daha güçlü. Bütçe ve zaman en baştan belirlendiği için yönetebilmek de kolay. Ayrıca her gelen yeni müşteri talebi ayrı ayrı maliyetlendirilip bütün planlar revize edilmediği için bütçenin sık sık değişmesi riski de söz konusu değil.
• Mevcut modelimiz bugüne kadar çalıştı, değiştirmeye ve çevik olmaya ihtiyaç yok! Eğer gerçekten müşterilerin, çalışanların memnun olduğu ve şirketin istenen genel performansı gösterdiği bir ortam varsa belki de değişim gerekli olmayabilir. Ancak bu direnç noktasının arkasında genelde şu gerçek yatar: Direktif verici - kontrol edici yönetim tarzına (command and control) alışkın ve gücü elinde tutan yöneticiler, bu güce veda etmek istemezler (İlgili makale: Çevik Yöntemlerde Sık Yapılan Hatalar). Onlar için çevik yöntemlerde takımların kendi başlarına organize olabilmeleri bir tabudur. Bu direnci aşabilmek için çevik takımların sağlayacağı verimlilik ve etkinlik artışı ön plana çıkartılıp, yöneticinin üzerindeki yükün azalacağı, taktik seviyedeki sorunlarla ilgilenmesine gerek kalmayacağı ve kendisinin stratejik diğer konulara odaklanabileceği anlatılabilir.
• Bizim durumumuz çevik için uygun değil, çünkü çok karmaşık! Bu bazen “çok farklı”, “çok özel” olarak da gelebilir. Bu direnç noktası için en iyi yaklaşım benzer firmalara ait vakaların anlatılması ve çevik dönüşüm sonrası yakalanan ivmenin vurgulanmasıdır. Özellikle rakiplerin yaptığı başarılı dönüşümler, yönetim kadrosunu etkileyecektir.

Peki Müşteriler:

• Bütün kapsam yapılmazsa, ihtiyaçlarımız karşılanmamış olur! Çağlayan modeli ile kapsama sıkı sıkıya bağlı çalışan kurumlarda en ufak bir iş isterinin bile yapılmaması sanki tüm iş eksik kalmış algısı yaratacaktır. Bu da çevik yöntemlere geçişte bir direnç yaratabilir. Burada en iyi ikna, aynı müşterilerin daha önceki uygulamalarda sunulan tüm kabiliyetlerin ne kadarını kullandıklarının gösterilmesi ile olacaktır.  Tüm sektörde sunulan kabiliyetlerin yaklaşık %64’ünün çok az kullanıldığı veya hiç kullanılmadığını (Kaynak: Standish Group Chaos Report 2009) anlatmak da işe yarayabilir. Ayrıca değişiklik isteklerinin olumlu karşılandığı, Ürün İş Listesi (Product Backlog) içinde önceliklendirmelerin proje boyunca yapılabileceğini aktarmak da müşterileri rahatlatacaktır.
• Takımla birlikte tüm döngülerde çalışacak kadar zamanımız yok! Özellikle Ürün Sahibi (Product Owner) olan müşteriler bu konuyu gündeme getirebilir. Burada takımla birlikte çalışmanın ve takıma hızlı bildirim vermenin sağlayacağı faydalar anlatılabilir. Eğer gerçekten de istenen katılım sağlanamıyorsa, en azından Döngü Gözden Geçirme toplantısına mutlaka katılımını sağlayacak bir model oluşturup, Ürün Sahibi rolünü müşteriyle en yakın çalışan takım üyesine vermek de bir alternatif olabilir.

Herkes için ortak olanlar da bulunuyor, bunların sadece başlıklarını belirtiyorum. Bunlara sunulacak argümanlar, sizin yaratıcılığınıza kalıyor. 

•  Şu anda rahattım
•  Değişimden korkuyorum
• Daha çok çalışmam gerekecek
• Başkalarıyla daha çok konuşmam gerekecek, konuşmayı sevmiyorum

Temel olarak değişim yönetimi başlıkları olan bu konuları iyi yönetebilmek, direnç noktalarını iyi belirleyip gerekli hazırlıkları yapmak, dönüşümün başarılı olması için çok önemli anahtarlardır.

Başarıya Farklı Bir Bakış

Başarı günümüz modern dünyasında çok sık karşımıza çıkan bir kavram. Bu kavramı daha önce proje perspektifi ile ele almıştık (İlgili Makaleler:Projelerde Başarı Etkenleri, Başarılı Proje Ekibinin Soruları, Öğrenilmiş Çaresizlik).

Bu yazıda genel olarak başarıdan bahsetmek istiyorum. Okulda başarı, sınavlarda başarı, spor müsabakalarında başarı ve iş hayatında başarı ise biraz daha öne çıkan kavramlar. Kimi için okuldan atılmamak başarı iken, kimi için okuldan dereceyle mezun olmak başarı. Kiminin sınavdan geçer not alması başarılı kabul edilirken, kiminin sınavdan tek bir yanlış cevabı başarısızlık olarak görülüyor. Kiminin olimpiyatlara katılabilmesi başarı iken, kiminin olimpiyatlarda gümüş madalya alması hayal kırıklığı olabiliyor. Kiminin iş bulabilmesi başarı olarak nitelenirken, kiminin genel müdür olamaması başarısızlık olarak algılanabiliyor. Peki çok farklı şekilde kullanılabilen başarı kavramı nedir? Türk Dil Kurumu’nun başarı tanımı bir işi istenen şekilde sonuçlandırmak. Burada başarıyı göreceli hale getiren “istenen şekilde” kısmı. İstenen ve elde edilen karşılaştırılınca başarı ve başarısızlık arasındaki çizgi belirleniyor. Örneğin olimpiyatlarda altın madalya istenirken gümüş madalya almak başarısızlık olabiliyor.

Başarılı olmayı veya istenen sonuca ulaşabilmeyi neler etkiliyor? Ben dört temel faktör olduğunu düşünüyorum:

• Sahip Olunanlar: Genetik miras, maddi miras gibi doğuştan gelen ve etkileme imkanımız olmayan koşulları bu başlıkta düşünebiliriz. Bu koşulları değiştirme şansımız bulunmuyor. Bunları sabit kabul edebiliriz. Herkesin doğuştan gelen bir yeteneği, bir yatkınlığı, bir üstünlüğü bulunduğunu düşünüyorum. Eğer yeteneğimiz/yatkınlığımız/üstünlüğümüz olan bir alanda başarılı olmak istiyorsak avantajlıyız diyebilirim.
• Çevresel Koşullar: İçinde bulunduğumuz çağ, ülke, kültür, toplum, kurumlar, ailemiz, arkadaşlarımız, yaşadığımız çevre, okuduklarımız, dinlediklerimiz, okullarımız, işyerlerimiz, yediklerimiz, içtiklerimiz vb. yani yaşamımızın bütün değişkenlerini bu başlıkta düşünebiliriz. Bunların bir kısmını değiştirme imkanımız varken bazılarını değiştirme imkanımız olmaz ve bunlarda oluşan değişim dalgaları bizi de etkiler ve başarılı olma veya olmama durumunu belirleyebilir.
• Hedef: Başarı tanımımızda yer alan istenen sonuç yani hedef başarı durumumuzu belirler. Bu nedenle doğru hedef seçmek çok önemlidir. Ulaşılması imkansız hedefler belirlemek motivasyonu düşürdüğü gibi çok kolay ulaşılabilecek hedefler de gelişimi ve ilerlemeyi örseler.
• Çaba: Tamamen bize bağlı olan, başarı ve başarısızlık arasında en çok fark yaratabileceğimiz faktörün bu olduğunu düşünüyorum.

Yukarıdaki faktörleri birleştirince herhangi bir alandaki başarıyı şu şekilde formülüze edebileceğimizi düşünüyorum:

• Sonuç = Sahip Olunanlar + Çevresel Koşullar + Çaba
•  Sonuç >= Hedef (Başarı)

Bu denklemde öncelikle bir Sonuç elde etmek için sonuca etki edecek tüm parametreler toplanıyor. Sonucun Hedef'ten büyük veya eşit olması durumunda başarı tanımındaki “istenen sonuç” ortaya çıkıyor ve başarılı kabul ediyoruz. Çaba ve Hedef bizim en çok belirleyici olduğumuz alanlar. Eğer Hedef yüksekse buna uygun Çaba harcamadan başarıya ulaşılamaz. Başarı faktörlerini grafikle de gösterebiliriz. Grafiklerde konunun daha net görülebilmesi için her bir faktöre rakam verdim. Bu faktörleri ve etkilerini rakamlara dökmek başlı başına bir bilimsel çalışma olabilir. İlk grafikte elde edilen Sonuç, Hedef'in altında kalıyor. Sonucun Hedef'i geçebilmesi için izlenecek ilk yol ikinci grafikteki gibi Hedef küçültmek olabilir. Bu sayede başarı yakalanabilir. Ancak bu daha fazla Çaba harcamamak için yapılan bir kandırmacadır. Üçüncü grafikteki yaklaşımda ise Çaba artırılmış ve istenen sonuca ulaşılmıştır.

Sahip Olunanlar ve Çevresel Koşullar’ın uygun olduğu bir alan seçilmesi durumunda yeterli Çaba da gösterilirse büyük ve etkileyici başarılara ulaşılabilir. Örneğin doğuştan müzik yeteneği olan bir çocuğun, uygun müzik eğitimlerini alması ve yeterli Çaba'yı göstermesi ile tanınan bir sanatçı haline gelmesi mümkündür. Eğer müzik yeteneğini yokken veya uygun eğitimleri almadan, sadece Çaba gösterilirse ilerleme kaydedilir ancak tanınan bir sanatçı olmaya yetecek başarıya ulaşılamaz.

Bir başka konu da her alanda Sahip Olunanlar ve Çevresel Koşullar'ın aynı oranda etki etmediği gerçeği. Bazı alanlarda Sahip Olunanlar'ın etkisinin yüksek olabildiği, bazı alanlarda Çevresel Koşullar'ın daha belirleyici olduğunu hepimiz biliyoruz. Her ne kadar bu iki faktörün etkisi yüksek de olsa Çaba ile en zor alanlarda bile değişim sağlanabiliyor. Örneğin insanın zeka tiplerinden en çok bilineni ve en çok ölçüleni IQ'nun genetik olduğunu düşünürüz ve Çaba ile değişmeyeceği kanaati hakimdir. Bunun tam tersini söyleyen araştırmalar bulunmakta yani Çaba ile IQ'nun artabildiği veya tembellik ile azalabildiği yönünde. Yani IQ'nuzu 5 puan artırmak gibi bir Hedef belirlerseniz, bunu yeterli Çaba ile başarmanız mümkün. 

Yukarıda anlattıklarımdan hareketle iki temel prensibin başarı için önemli olduğunu düşünüyorum:

• Sahip Olunanlar ve Çevresel Koşullar’ın uygun olduğu bir alan ve gelişimi zorlayıcı akıllı bir Hedef seçilmesi
• Yeterli Çaba’nın harcanması

Bu iki prensip bir araya geldiğinde etkileyici başarılardan söz etmek mümkün olabilir.

Çevik Yöntemlerde Performans Ölçümü

Çevik yöntemlerle ilgili çeşitli güncel başlıklara daha önce değinmiştik (İlgili Makaleler: Çevik Yöntemlerde Sık Yapılan Hatalar, Çevik Yöntemler ve Teknik Mükemmellik, Çevik Yöntemlerdeki Rollere Uygun Profiller). Çevik yöntemler ve ölçme yan yana düşünül(e)meyen kavramlar gibi görünüyor, bir araya gelebilirler mi? Bildiğimiz performans ölçümü yaklaşımları çevik projelerde işimize yarar mı? Bu yazıda bu sorulara yanıt arayacağız ve performans ölçümünün çevik dünyadaki yerini aktarmaya çalışacağız. 

Çevik yöntemlere dönüşümün başarılı olabilmesi için organizasyonel, süreçsel, yönetsel ve kültürel dönüşümün birlikte olması gerekliliği bilinen bir gerçek (İlgili Makale:Çevik Yöntemlere Dönüşüm). Bu parçalardan birinin dönüşmemesi, çevik dönüşümün tamamını zedeleyebiliyor. Hangi parçanın ne kadar dönüştüğü ve ne kadar geliştiği ise performans ölçümü ile ortaya çıkarılabiliyor. Dahası performans ölçümü ile elde edilen sonuçlar geri bildirim olarak kulllanılarak hangi alanda ne kadar yol katedildiği, hangi alanların gelişime açık olduğu belirlenebiliyor. Bu sayede çevik yöntemlerin daha etkin kullanılmasına da olanak sağlanıyor.  

Çevik projeleri klasik performans ölçüm yaklaşımı ile değerlendirmek yeterli olmuyor. Örneğin klasik yaklaşımda proje başarısı “başta belirlenen tüm kapsamın”, belirlenen bütçe ve zaman limitleri dahilinde gerçekleştirilmesidir. Çevik yaklaşımlarda “tüm kapsamın” tamamlanması bir amaç değildir. Kapsam, Ürün Talep Listesi’ne (Product Backlog) eklenen ve çıkarılan her bir madde ile sürekli değişebildiği için “başta belirlenen tüm kapsam” maddesinden çevik yaklaşımlar otomatik olarak sınıfta kalacaktır. Çevik dünyada kapsam yerine müşteriye sunulan "değer" ön plana çıkarılıyor. Değeri sağlamak için tüm kapsamı yapmak gerekmiyor, öncelikli ve çalışan parçaları mümkün olduğu kadar erken ve sık teslim etmek tercih ediliyor.

Klasik “başarı” ölçümü yaklaşımı bir hedef belirlemek ve sonucu bu hedefle kıyaslamaktan geçiyor. Bu her zaman “başarılı” ve “başarısız”ı doğru olarak ölçebilir mi? Bir örnek vermek gerekirse, bir sınava gireceğinizi ve hedefinizin 10 üzerinden 7 almak olduğunu düşünün, eğer 7 alırsanız, sonuç hedefinize uygun olduğu için performansınız “başarılı” olacaktır. Eğer aynı sınavdan 9 almayı hedeflediyseniz ve 8 aldıysanız klasik performans ölçümü yaklaşımı ile hedefe ulaşamadığınız için “başarısız” olarak niteleneceksiniz. Peki sınavdan 7 almak mı yoksa 8 almak mı daha büyük bir başarı? 

Çevik dünyada sürdürülebilir gelişim ve iyiye doğru devamlı ilerleme teşvik ediliyor. Örneğin 3 sınavdan sırasıyla 9,8,7 (ortalaması 8) almak mı yoksa 6,7,8 (ortalaması 7) almak mı daha iyi? Sınavın ortalama puanına göre ilk durum daha iyi gibi görünüyor. Ancak artan bir performans çevik dünyanın felsefesine daha uygun.

Yukarıdaki yaklaşımlardan yola çıkarak çevik yöntemlerde 2 boyutlu bir performans ölçümü öneriliyor. İlki ürünün müşteriye sağladığı katkı yani değer (business value). Bunu ölçmenin en temel yolu ürünün sağladığı ekonomik katkının, Yatırım Geri Dönüşü (ROI-Return on Investment, ilgili makale: Proje için Finans) gibi parametrelerle belirlenmesinden geçiyor.  İkinci boyut ise ürünün ortaya çıkarılmasındaki performansın ölçülmesi,  bunlardan başlıcaları:

• Üretkenlik: Yapılan iş/fonksiyonalite miktarının (tamamlanan kullanıcı hikayesi, use case, özellik vb.) belirlenmesi. Bu ölçümün trend olarak izlenmesi, çevik takımın kendi gelişimini de görmesine yardımcı olacaktır. Gelişimin izlenmesi için Epic Burn-up Chart veya Product Burn-down Chart kullanılabilir.

•  Verimlilik: Birim zamanda üretilen iş miktarının ölçülmesi ile çevik takımın verimliliğini izlemek mümkün olacaktır. Örneğin çevik takımın bir döngüde (iterasyon) üretebildiği iş miktarının belirlenmesi ile sonraki döngülerde taahhüt edeceği iş miktarını da buna uygun seçme imkanı olacaktır. 

• Güvenilirlik: Sunulan ürünün sağlamlığı, güvenilir oluşu bu başlıkta izleniyor. Bu amaçla farklı metrikler tasarlanabilir. Örneğin yazılım projelerinde kod satır sayısı başına düşen hata oranı ile ürünün teknik kalitesi ve güvenilirliği ortaya konabilir. Ürünü teknik yönden kararlı olmasını sağlayan tüm metrikler de bu başlık altında düşünülüyor. 

Yukarıdaki başlıklar altında tasarlanacak performans metrikleri ile çevik takımın kendi içindeki gelişimini izlemesi, iyileşme potansiyelini fark edip artan bir performans grafiği yakalaması bekleniyor. Her çevik döngü sonunda yapılan retrospektiflerde (İlgili Makale:Çevik Yöntemlerde Retrospektif) bu amaca hizmet edilerek bir sonraki döngü için bir gelişim teması belirleniyor. 

Çevik yöntemlere dönüşümü hedefleyen kurumlarda daha en başından itibaren mevcut durumun belirlenmesi, gelişimin ölçülmesi ve trendinin izlenmesi, çevik yaklaşımların kattığı değerin net olarak görülebilmesi için çok büyük önem taşıyor. Burada da üç boyutlu :bir yaklaşım öneriliyor:

• İlki dönüşüme konu ekiplerin kendi içindeki gelişimin trend analizi.
• İkincisi dönüşüme konu olan ve olmayan ürünlerin kıyaslamasının trend analizi. Bunu dikkatli yönetmek gerekiyor. Takım bazında değil, ürün bazında yapmak lazım. Takımlar kıyaslanmamalı.
• Üçüncüsü şirketin toplamında yaratılan değişimin trend analizi.

İster çevik yöntemlere dönüşüm yolunda olsun, ister çevik metodolojileri daha iyi kullanabilme yolunda olsun, gelişimi izleyebilmek ve iyileşme fırsatlarını görebilmek için ölçmek gerekiyor. Son söz olarak ölçmeden yönetemeyeceğimizi unutmamak gerekiyor.

Çevik Yöntemlerde Sık Yapılan Hatalar

Ülkemizde giderek daha fazla ilgi çeken çevik yöntemlerle ilgili çeşitli yazıları (İlgili Makaleler: Çevik Yöntemlere Yolculuk, Çevik Yöntemler ve Teknik Mükemmellik, Büyük Ekipler Çevik Yöntemleri Uygulayabilir mi? ) daha önce kaleme almıştık. Bu yöntemleri uygulamaya çalışan bazı kurumlar istenen sonucu alamıyor ve bir süre sonra pes ederek eski alışkanlıklarına dönüyor. Bu başarısız dönüşüm çabalarından sonra çevik yaklaşımın kendi kurumlarına göre olmadığını belirtenlerin sayısı da azımsanmayacak kadar yüksek. Aslında çevik yöntemlerdeki uygulama hataları da bu başarısız dönüşüm çabalarında önemli yer tutuyor. Bu yazıda sık yapılan uygulama hatalarını ele alacağız:

• Yanlış Çevik Metodoloji Seçimi: Yapılan çalışmaya, ekibe ve projeye uygun olmayan bir yaklaşımla çalışılması doğal olarak başarı getirmeyecektir. Örneğin Kanban kullanmanın uygun olabileceği yerlerde herkes Scrum kullanıyor diye bu yaklaşımın kullanılması, ekibin motivasyonunu da verimliliğini de olumsuz etkileyecektir. Doğru çevik yaklaşımın belirlenmesinin proje, ürün ve ekip özelindeki dinamiklerin incelenmesi ile mümkün olacağını unutmamak gerekiyor.
• Yetkin Olmayan Ekipler: Tüm çevik yaklaşımlarda ortak olan konulardan bir tanesi çevik takımın kendini organize edebilmesi, işi küçük parçalara ayırabilmesi ve bunları kendini içinde planlayarak yapabilmesidir. Bu kabiliyetleri olmayan, dahası yönlendirmeye gereksinim duyan, direktifsiz çalışamayan ekiplerle çevik takım kurmak ve bu takımlardan üretim beklemek haksızlık olacaktır. Hem organizasyonel becerileri, hem iletişim becerileri hem de teknik yetkinlikleri yüksek olan takımların çevik yöntemleri hakkıyla uygulayabileceğini unutmamak gerekiyor.
• Dokümantasyon Yapılmaması: Çevik çalışmayı hiçbir dokümantasyon yapmadan çalışma olarak algılayan ekipler de var. Bu yaklaşım doğru değil, çevik metodolojilerle çalışırken gerekli olan dokümantasyonun mutlaka yapılması gerekiyor. Ürün kalitesine, sürdürülebilirliğe katkı yapacağı için bunu atlamamak gerekiyor. Burada en önemli prensip asgari yeter (barely sufficient) prensibine uygun olarak gerekli dokümantasyonu asgari yeter seviyede yapmak, ötesine geçmemek gerekiyor. Eğer süreçler gereği kullanılmayan dokümanlar üretiliyorsa, bunu kendiliğinden yapmamak yerine süreçlerden kaldıracak girişimlerde bulunmak da doğru bir yaklaşım olacaktır.
• Kısmı Uygulama: Çevik manifestonun ve arkasındaki prensiplerinin işine gelen kısmını uygulamak işine gelmeyenlerini göz ardı etmek, seçilen metodolojinin bazı kısımlarını yok saymak gibi yanlışlar ne yazık ki yapılıyor. Bu da istenen sonuçların alınmasını engelliyor.
• Sadece Mühendislik Ekipleri ile Sınırlama: Genellikle çevik yaklaşımların sadece mühendislik ekiplerinin çalışmalarını düzenlediğini düşünen ve kendini bu çemberin dışında gören ekipler ve paydaşlar da oluyor. Örneğin müşterinin, üst yönetimin, kalite ekiplerinin de çevik yaklaşımlara uygun olarak kendi çalışma yaklaşımlarını değiştirmeleri ve uygulanan çevik metodolojiye uygun hale getirmeleri gerekiyor.
• Şampiyon (CEO vb.) Olmaması: Çevik çalışmaların arkasında duracak, bu dönüşümün
  sponsoru olacak, eskiye dönüş konusunda gelecek baskıları durdurabilecek güçte bir kişinin 
  yani şampiyonun desteği mutlaka gerekiyor. Özellikle CEO’ların bu şampiyon olması tercih
  edilen bir durum.
  
• Hatalı Yönetim Tarzı: Direktif verici ve kontrol edici yönetim tarzının (command and control) çevik dünyaya uygun olmadığı bir gerçek. Çevik takımların kendi işlerini organize edebilen, bu işleri kimsenin talimatına ihtiyaç duymadan yapabilen takımlar olduğu gerçeğinden yola çıkınca direktif veren bir yöneticinin böyle bir takımın harmonisini nasıl bozacağını tahmin etmek zor olmayacaktır. Çevik dünyada istenen yönetim tarzı ise hizmet eden liderlik (İlgili Makaleler: Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerdeki Rollere Uygun Profiller) anlayışını barındırmalıdır.
• Ekibin Başına Buyruk Davranması: Çevik takımların kendini organize edebilme yeteneğini kötüye kullanarak, müşteriyi, ürün sahibini ve diğer paydaşları dikkate almadan çalışması da çevik yöntemlerden istenen sonuçların alınmasını engelleyen bir durum olarak karşımıza çıkıyor. Özellikle gelişmeleri görmek isteyen müşterinin reddedilmesi, geri bildiriminin yeterince alınmaması “çalışan ama işe yaramayan” ürünlerin ortaya çıkmasına sebep olmaktadır.
• Liderlerin İlgisiz Davranışları: Çevik takımlardaki ürün sahibi veya yönetici rolündeki (scrum master vb.) kişilerin geliştirme takımlarının yaşadıkları sorun ve karşılaştıkları engellere duyarsız kalmaları ve “siz kendiniz çözün” gibi yanıtlar vererek takımın önünü açmamaları da çevik yöntemlerde yaşanabilen bir hatadır.  Bu tür durumlarda çevik takımlar, ilerlemek için harcayacakları enerjiyi sorunların takibi ve çözümü gibi konulara kaydırmak durumunda kalıyor.
• İş Biriminin/Müşterinin Yetersiz Katılımı: Müşterinin veya iş birimlerinin projeye tam olarak dahil olmaması, gerekli yönlendirmeleri yapmaması, zamanda karar alamaması ile çevik takımların önü tıkanıyor. Bu da sık yaşanabilen ve çevik yöntemleri kullanan takımların istenen üretkenliğe ulaşmasını engelleyen bir durumdur.
• Kovboy Kodlaması: Çevik yazılım yapmayı kuralsız çalışmak olarak algılayan kişiler ne yazık ki bulunuyor. Bu da çevik yaklaşımların ortak prensiplerinden olan sürdürebilirlik ve teknik mükemmeliyet başlıkları ile çelişiyor.

Yukarıdaki tespitlere başka maddeler de eklemek mümkün. Çevik yöntemlerin başarılı olabilmesi için bu sık yapılan hataları tekrarlamamakta fayda var. Ayrıca çevik yöntemlerden istenen sonuç alınamıyorsa, bunun faturasını çevik yönteme kesmek yerine uygulama biçimini gözden geçirmek, doğru uygulamanın yollarını bulmak ve en iyi örnekleri incelemekte de yarar görüyorum.