Son yılların en popüler kavramlarından biri de “agile”, yani çeviklik. Ülkemizde de özellikle bilgi teknolojileri alanında çok yaygın olarak uygulanmaya başlanan bir yaklaşım. Üzerine fazlaca yazılıp çizilen agile yöntemler etkin uygulandığında (elbette uygulandığı alana bağlı olarak) üretimi olumlu yönde etkilediği kanıtlanmış bir gerçek. Ancak bazı organizasyonlarda çeşitli sebeplerden ötürü istenildiği kadar verim alınamayan bir yaklaşım haline gelebiliyor.
Peki neden bazı organizasyonlarda efektif olurken bazılarında verim alınamayan bir yaklaşım? Bunun en temel nedeni şüphesiz ki kurum kültürüdür. Bir organizasyon içerisinde yer alan tüm birimler ya da kişiler bu yaklaşımı benimsemezse, sadece kurum içerisinde belirli takımların agile metodla çalışması çok şey ifade etmez. Literatürde her zaman söylenen bir şey vardır: “Agile is a mindset” yani insanların çevik yaklaşımları başarılı şekilde uygulayabilmesi için öncelikle düşünce şekillerinin, kafa yapılarının çevik olması gerekir. Özetle; buna inanmaları gerekir.
Çoğu kez agile çalışma şekli kurumlar içerisinde üst yönetimden aşağı inen bir şekilde insanlara dayatılan bir uygulama olarak karşımıza çıkıyor. Bunun sonucunda da “agile olmuş” değil “agile yapmış” olunuyor. Bu bağlamda öncelikle kurum içerisindeki insanların çevikliği özümsemesi ve değişim için motive edilmesi sağlanmalıdır diyebiliriz. Aksi takdirde, organizasyon içerisindeki belirli takımlar ya da kişiler çevik yöntemleri uygulamaya çalışsa da bu bir kurum kültürü haline gelmediği için ister istemez engellenecek, kısıtlanacak ve kendilerini eski çalışma yönteminin girdabında tekrar bulacaklardır. Daha da kötüsü agile olmakla olmamak arasında garip bir döngüde bulacaklardır. Yani görünürde scrum’ın bütün ritüellerini eksiksiz yerine getirirken iş yapış şekilleri maalesef ki waterfall kalmaya devam edecektir. Hatta öyle bir durumda scrum’ın ritüellerini yerine getirmek takım için vakit kaybı olarak bile görülebilir.
Agile metodolojilere yeni geçilen organizasyonlarda yaşanan başarısızlıkların çok fazla örnekleri vardır. Örneğin; yazılım ekibi projenin bitiş tarihine yetişmek için hem analiz hem de yazılım task’larını bir bütün olarak aynı sprint’e alarak önce analizin; ardından da yazılımın gerçekleştirilmesini planlıyor. Bu noktada yazılım ekibi ilgili projeyi task’lara ayırmadan bir sprintte tamamlamaya çalıştığından ve çoğunlukla da bitiremediğinden dolayı sprint sonunda çıktı verememiş gibi gözüyor. Sonuçta yine o task bir bütün olarak bitiş tarihine kadar her sprintte tekrar ele alınmaya devam ediliyor ve bu zaman baskısıyla birlikte o tarihe kadar bitirilip üretim ortamına alınmaya çalışılıyor. Böyle bir durumda ise üretim ortamı sorunları baş gösteriyor ve çeşitli sürümler çıkılarak sorunlar üretim ortamında düzeltilmeye çalışılıyor ki bu çok riskli bir durumdur; çünkü üretim ortamında çalışan başka sistemleri etkileme olasılığı yüksektir.
Agile uygulamaların başarılı olamamasının diğer bir nedeni de agile yöntem olarak genellikle scrum metodunun uygulanmaya çalışılmasıdır. Oysa scrum, agile yöntemlerden sadece biridir ve her organizasyonda verimli olamayabilir. Belki o organizasyonun dinamikleri ya da kültürü scrum uygulanmasına elverişli olmayabilir. Böyle bir durumda da scrum uygulamaya çalışan ancak başarılı olamayan, sprint sonunda “burn-down” grafiğine baktığında çıktı verememiş ya da çıktı oranı çok düşük takımlar ortaya çıkar. Benim görüşüm, bu durum aslında takımın başarısız oluşuna değil; scrum’ın düzgün uygulanamadığına işaret ediyor.
İş analizi bağlamında agile dönüşüm sorunlarını ele almak istersek de şunu görürüz; genellikle kurum içerisinde bir işin analiz, geliştirme, test ve sonrasındaki kullanıcı kabul testi ile üretim ortamına geçiş döngüsünde yani yazılım geliştirme hayat döngüsünde maalesef ki halen çoğunlukla proje merkezli waterfall bir süreç uygulanır. Bu da işlerin alışkın olunduğu şekilde sırayla yapılması ve dolayısıyla da analizin, işin en başında hızlı bir şekilde tamamlanması gerektiği anlamına gelir. Oysa agile mantığında yazılım ekibi işi sprint planına alırken parçalara bölerek alması ve analizi de aslında parçalara bölerek yapması gerektiği için iş tamamlanana kadar analizde de bir çok güncelleme yapılır ve son halini alması belki de son noktada olur. Bu noktada analist hem agile çalışıp, hem de analizi en başta bitirmek gibi bir durumla karşı karşıya kaldığı için tıpkı yazılımdaki kod sürümleme örneğinde olduğu gibi analiz dokümanında da birden çok versiyon ortaya çıkar.
Yukarıdaki maddelere elbette eklemeler yapılarak örnekler çoğaltılabilir çünkü herkesin, her kurumun ya da takımın agile deneyimi farklıdır. Ancak toparlayacak olursak dışarıdan bir organizasyona empoze edilmeye çalışılan her sistem gibi agile yöntemler için de kurumun bunu kendi dinamiklerine uygun şekilde uygulaması çok önemlidir. Belki sadece scrum değil, birkaç çevik model birleştirilerek uygulandığında daha başarılı bile olunabilir. Hatta proje bazında bile çevik yöntemlerin uygulanmasında farklılaşmaya gidilebilir. Bu dönüşüm sorunlarının üstesinden gelmek için de doğru yöntemi bulmak gerekir.
Güneş KARA BULUT
Senior Business Analyst @ŞekerBank
Content Writer @BA-Works