Agile Nedir?

Son 3 yıldır performansından memnun olmadığımız ne varsa başına Agile/Çevik ekleyerek iyileştirmeye çalışıyoruz gibi bir durum yaşanıyor. “Çevik Lider”, “Çevik Şirket”, “Çevik Proje Yönetimi”, “Çevik Takım”, “Çevik …”.  Nereden çıktı bu Agile/Çevik? Dilimizde “Çeviklik” olarak kullanılan “Agile” nedir?

Çevik yöntemler nasıl ortaya çıktı

Çevik yöntemleri kullanan ekipler işleri geleneksel süreçleri kullanan ekiplerden daha hızlı yapmaktadırlar. Çevik yöntemler özellikle Bilgi Teknolojileri (BT) alanında yazılım geliştirme süreçlerini önemli ölçüde değiştirdi ve geliştirdi. Ilginç olan çevik yöntemlerin BT alanı dışında gelişmesi.

Tarihte uygulanan çevik yöntemlerin arayışı bizi Bell Labs’teki fizikçi ve istatistikçi Walter Shewhart’ın ürünlerin ve süreçlerin iyileştirilmesi için Planla-Uygula-Kontrol Et-Önlem Al (PUKÖ) döngü metodolojisini uygulamaya başladığı 1930’lara götürüyor. Shewhart bu yineleyici ve aşamalı geliştirme metodolojisini öğrencisi W. Edwards Deming’e öğretti ve Deming bunu İkinci Dünya Savaşı’ndan sonraki yıllarda Japonya’da yaygın şekilde kullandı.

Çeviklik ve yalın yaklaşımlar

Toyota, yüzlerce şirket yöneticisini yetiştirmek için Deming ile çalıştı ve sonunda bugünkü “yalın” düşüncenin birincil kaynağı olan ünlü Toyota Üretim Sistemini geliştirdi. Yinelemeli ve artımlı geliştirme yöntemleri, 1950’lerde X-15 hipersonik jetin de başarılı bir şekilde oluşturulmasına önemli bir katkı sağladı.

1986’da, Hirotaka Takeuchi (Harvard Business School Öğretim Üyesi) ve İkujiro Nonaka tarafından, “Yeni Yeni Ürün Geliştirme Oyunu” adlı Harvard Business Review’da bir makale yayınlandı. Yazarlar, başarılı inovasyonları rakiplerinden çok daha hızlı bir şekilde yapan firmaları araştırarak ekip odaklı bir yaklaşım belirlediler. Bu yaklaşım Fuji-Xerox’daki fotokopi makineleri, Honda’daki otomobil motorları ve Canon’daki kameralar gibi ürünlerin tasarım ve geliştirme sürecini etkileyip değiştirdi. Bu şirketler, geleneksel “bayrak yarışı” ürün geliştirme yöntemlerini izlemekten ziyade (ki bu bir grup uzmanın çalışma aşamalarını tamamladıktan sonra süreci bir sonraki işlevsel aşamaya geçirmeleri şeklinde tarif edilebilir), Takeuchi ve Nonaka’nın “rugby” yaklaşımı dediği şeyi kullanıyordu ve burada, “ekip mesafenin tümünü hep beraber bir birim halinde topu ileri geri atarak kat eder.”

Çevik yaklaşımların BT alanındaki ilk uygulaması

1993 yılında, bir diğerimiz (Sutherland) imkansız görünen bir görevle karşı karşıya kaldı: Bir yazılım şirketi olan Easel Corporation’ın, altı aydan daha kısa bir sürede eski tekliflerini değiştirmek için yeni bir ürün geliştirmesi gerekiyordu. Sutherland, hızlı uygulama geliştirme, nesneye yönelik tasarım, PUKÖ döngüleri ve skunkworks gibi metodolojilerde zaten güçlü bir geçmişe sahipti. Şirket merkezinin ortasında, hem organizasyonel ayrılık hem de entegrasyonun faydalarını harmanlayarak, skunkworks benzeri bir kültür yaratmayı umuyordu. Bu yüzden örgütsel üretkenliği en üst düzeye çıkarmak hakkında elinden gelen her şeyi öğrenerek başladı. Yüzlerce makale okurken ve önde gelen ürün yönetimi uzmanlarıyla röportaj yaparken, çeşitli kışkırtıcı fikirlerin ilgisini çekti.

2000’lerin başında teknolojinin çok hızlı gelişmesi, internet kullanımının artması ve en önemlisi “Bilgi”nin petrolden daha değerli bir maden olarak görülmeye başlaması ile “Bilgi Çağı” na girildi. Hızla gelişen yıkıcı teknolojiler, yavaş davranan işletmeleri sahneden hızla silmeye başladı. Teknoloji odaklı yeni kurulan şirketler ve piyasadan silinmek istemeyen mevcut şirketler, bu yeni ve çalkantılı ortama uyum sağlamanın daha iyi yollarını aradılar. Bir satır kod ile Dünya’yı değiştirecek bir dönem başladı. “Yazılımlar” neredeyse her işin ayrılmaz bir parçası haline geliyordu ve birçok yaratıcı yazılım geliştiricisi daha iyi programlama yöntemleri üzerinde yoğun çalışıyordu.

Çevik yaklaşımların doğuşu

2001’de, kendilerini “örgütsel anarşist” olarak adlandıran 17 yazılım geliştirici, yazılım geliştirme sürecini daha iyi hale getirebilmek için Utah’daki Snowbird’de bir araya geldi. Toplantı da bir çok konuda fikir ayrılığı olsa da nihayetinde yazılım geliştirme süreçlerini daha iyi hale getirecek dört temel değer üzerinde mutabık kaldılar. Bu değerler “Çevik Yazılım Geliştirme Bildirgesi” adıyla yayınlandı.

Kendilerine Çevik İttifak adını veren grup, toplantı sonrasını takip eden birkaç ay boyunca devam ederek “Çevik Bildirgenin Ardındaki İlkeler” adlı 12 ilkeyi geliştirdiler. 2001’den itibaren bu değerler ve ilkelerle uyumlu tüm gelişim çerçeveleri çevik teknikler olarak anılmaya başlandı.

Bu toplantıdan sonra çevik hareket hızla yayıldı. Bildirgeyi imzalayanlar ve birçok kişi hareketi desteklemek için Çevik İttifak adılı kar amacı gütmeyen bir organizasyon kurdu. Bugün Çevik İttifak’ın yaklaşık 72.000 üyesi ve abonesi bulunuyor.

Bu arada, çevik metodolojiler gelişmeye devam etti. 1980’lerin sonunda ve 1990’ların başında, MIT’den araştırmacılar Japon üretim sistemlerini, özellikle de Toyota üretim sistemini incelemeye başladılar. Düzensiz iş akışlarındaki azalmalar (“mura”) ve yıkıcı aşırı yüklenme (“muri”) yoluyla israfı (“muda”) ortadan kaldırarak sistemin üretkenliği artırma yöntemlerini tanımlamak için “yalın” terimini icat ettiler. Yalın metodolojiler Snowbird’de çevik çerçeveler olarak sunulmasa da, resmi yalın ve kanban yazılım geliştirme sistemleri 2000’lerde ortaya çıktı. İlk başta, bazı çevik safçılar bu yaklaşımları çevik metodolojiler olarak tanımayı reddettiler. Ancak yalın savunucular, müşteri işbirliğine odaklanmalarını yoğunlaştırdı ve sonunda daha çevik uygulayıcılar yalın, kanban,

Başarının birçok babası vardır ve çevik yeniliğin renkli bir mirası vardır. Agile’ın karmaşık soy ağacı bazen Agile uygulayıcıları arasında tutkulu tartışmalara yol açsa da, iki şey açıktır: Birincisi, Agile’ın kökleri bilgi teknolojisinin çok ötesine uzanır ve ikincisi, Agile’in dalları neredeyse her sektörün her işlevinde inovasyon süreçlerini iyileştirmek için yayılmaya devam edeceği.

Çevik yaklaşımlar

Meslek hayatımın başlarında yıllar süren yazılım projelerine şahit oldum, bir kısmının bizzat içinde bulundum. Eğer bir yazılım geliştirme projesi 6 aydan fazla sürüyorsa projenin başarısızlık oranı oldukça yüksektir. Başarısız olan projelerin detayına baktığınızda aslında nedenleri net bir şekilde ortaya çıkıyor. Bu nedenlere odaklanarak, yapılan yanlışları düzeltmek için yapılması gerekenler çevik yazılım geliştirme bilgirgesi ve o belgenin arkasındaki ilkelerde çok güzel ifade edilmiştir.

Bir anoloji ile anlatmak gerekirse; Bir elbise diktirmek istiyorsunuz. Kumaşı beğendiniz ve terziye nasıl bir elbise istediğinizi anlattınız. Terzi anlattıklarınızı not etti, vücut ölçünüzü aldı ve elbiseyi dikmeye başladı. Aradan aylar geçti terziden ses seda yok, 3 ay sonra terzi elbiseyi bitirirek size getirdi. Elbiseyi denediniz ancak pantalonun beli olmadı, ceket düğmeler kapanmıyor. Çünki siz kilo almışsınız! Elbise 3 düğmeli sipariş etmiştiniz ancak artık 2 düğmeli ceketler moda olmuş! Yelek üzerinize tam oturmadı!

Çevik yöntemde terzi ölçünüzü alıp elbiseyi dikmeye başladıktan sonra her aşamasında sizi bilgilendirip her bir parça için üzerinizde denemeler yaparak ceketin, yeleğin, pantalonun üzerinize tam oturup oturmadığını kontrol eder görüşünüzü alır ve dikim sürecine devam eder. Her bir parçayı sırasıyla diker ve her bir parça tamamlandıktan sonra size teslim eder. Böylelikle elbise dikim sürecinin her aşamasından haberdar olur, zevkinizde yada moda da bir değişiklik oldu ise bunu terzinizle anında paylaşma şansınız olur.

Diğer güzel bir örnek; hiç yapmadığınız bir yemeği yapacaksınız. Tarife bakıp tüm yemeği yapıp sonunda tadına bakıyorsunuz ki olmamış 🙂 Çevik yaklaşımla; yemeğin yaparken her aşamasında tadına bakıp ve o yemeği birlikte yiyeceğiniz kişilere tattırıp görüşlerini alırsınız. Gelen eleştiri ve önerileri dikkate alarak malzemeleri, baharatları ekler çıkartırsınız ve sonuçta bir ekip çalışması sonucu güzel bir yemek ortaya çıkar.

Yazılım geliştirme sürecide benzer şekilde; yazılım geliştirme uzmanları analizleri aldıktan sonra, istediğiniz yazılımı geliştirmek için aylarca çalışıp sonra size yazılım bitti kontrol eder misiniz diye sorduklarında bir çok şey için geç kalınıyor. Şirket hayatlarında 3 ay, 6 ay gibi süreler çok kısa gibi görünse de dijitalleşmenin çok hızlı yaşandığı bir dönemde pazar gereksinimleri, rekabet şartları, müşteri ihtiyaçları hatta teknolojinin kendisi çok hızlı değişiyor. 

Bu değişime ayak uydurmak için çok kısa sürelerde çok hızlı hareket etmek, eğer projede bir hata varsa bunu çok kısa sürede ortaya çıkartmak ve düzeltecek aksiyonları çok hızlı almak gerekiyor.

Temelde çevik yaklaşım bize şunları söylüyor; 

• Müşteriler proje yönetimi sürecinde aktif olarak yer almalı. Kısa aralıklarla biten işlerle ilgili görüşleri alınmalı varsa kapsam değişiklikleri, yeni ihtiyaçlar proje yönetimi sürecinde değerlendirilmelidir. 
• Aylar süren çok büyük projeleri küçük küçük alt projelere bölerek her bir alt projede her bir işin kısa sürelerde tamamlanıp bir sonucun ortaya çıkmasına odaklanılmalıdır. Genelde alt projeleri haftalık yada iki haftalık bir iş programı çerçevesinde ele alınmaya başlanmıştır.
• Bu yöntemle iş programlarında bir aksaklık yaşandığında bunun ortaya çıkması en fazla 1-2 hafta gibi bir zaman sürecek ve ilgili aksaklığın giderilmesi için hızlıca aksiyon alınabilecektir.
• Alt projeleri küçük takımlar halinde çalışan ekipler üstlenmelidir. Ekip kendi içinde özgür olmalı ve hangi işi ne zaman yapacağı ile ilgili kararları kendisi almalıdır.
• Her takım günlük sabah ayaküstü toplantıları ve akşam kapanış toplantıları yaparak o günün yapılacak işlerin doğru ve zamanında yapıldığından emin olmalıdır. Ters giden bir şey varsa anında proje paydaşları ile bu bilgiler paylaşılmalıdır.

Çevik yaklaşımlar her derde deva mıdır

Çevik yaklaşımlar o kadar çok kabul gördü ki özellikle kurumlar iyileştirmek istedikleri her konuda çevik yaklaşımları kullanmaya başladılar.  Çevik yaklaşım bildirgesini ve 12 prensibi okuduğunuzda genel olarak bir çok konu için geçerli olduğunu göreceksiniz.

Örneğin; televizyonunuz arızalandı yetkili servise gönderdiniz. Aradan uzun bir süre geçti ancak servisten haber yok ne hissedersiniz? Acaba servis gerçekten işini düzgün yapıyor mu? Hafta sonu taraftarı olduğunuz futbol takımınızın maçına televizyon yetişecek mi? Sürekli servisi arayıp durumunu sorgulamak istersiniz değil mi?

Oysa, servis sizi her gün telefonla ya da e-posta ile düzenli olarak bilgilendirir, televizyonunuzdaki tam olarak arızanın ne olduğunu, parça gerekip gerekmediğini, parçanın stoklarında yoksa temin etme süresini, onarımının yaklaşık ne zaman tamamlanacağını size iletse kendinizi daha iyi hissetmez misiniz? Vay be işlerini ne güzel yapıyor diye düşünürsünüz. Hatta süreçte bir aksaklık olduğunda, örneğin kendilerinden kaynaklanmayan bir nedenle parça temini geciktiğinde dahi sizi anında bilgilendirseler, onlara kızmak yerine teşekkür etmez misiniz? 

Her ne yapıyor olursanız günün sonunda bir ürün ya da hizmet teslim edecekseniz her önemli aşamasında paydaşların bilgilendirilmesi, teslimat durumu, varsa bir aksaklık sebebi ile ne kadar gecikme olacağı mutlaka anında taraflarla paylaşılması oldukça önemlidir. 

Çevik yaklaşımların özüne dönmek

“Kelimeler anlamını yitirdiğinde insanlar özgürlüklerini kaybeder” der Konfüçyüs.

Bugün “Çevik” her şey anlamına geliyor ve giderek hiçbir anlam ifade etmiyor. Neredeyse Çevik yöntemlerin kullanılmadığı tüm süreçlerde problem yaşanıyor gibi bir algı oluşmuş durumda. Bundan kurtulmak ve Çevik yaklaşımların özünü anlamak yeterlidir.

Çevik yaklaşımlarla ilgili aklımızda kalması gerekenler çok basit aslında;

İşbirliği Yap, Teslim Et, Düşün ve İyileştir. (Alistair Cockburn’un Çevik Kalbi)

İnsanları Harika Hale Getirin , Güvenliği Ön Koşul Yapın, Deney Yapın ve Hızla Öğrenin ve Sürekli Değer Verin. (Joshua Kerievsky’nin Modern Çevikliği )

Kaynaklar:

‘https://hbr.org/2016/04/the-secret-history-of-agile-innovation‘