Şu zaman diliminde, neredeyse çalıştığımız sektör ve departman fark etmeksizin tüm organizasyonlar “Agile” kavramıyla çoktan tanışmış ve metodoloji olarak benimseyip; özellikle IT stratejileri içerisinde bu yapıyı oturtmayı vizyonlarına eklemiştir. Bu transformasyon sürecine en hızlı adapte edilebilen ekiplerin ise yazılım dünyasından olduğunu söylemek yanlış olmaz. Bugün yazılım matrisinde rolü olan biz iş analistleriyle birlikte proje yöneticileri, IT yöneticileri, ürün yöneticileri, yazılım geliştirme ekipleri ve tüm işkolları; katıldığımız her konferans, workshop ve etkinlik içerisinde Agile’ı bir köşesinden yakalıyor ve doğru anlamaya / anlamlandırmaya çalışıyoruz. Şirketlerin aldığı danışmanlık destekleri, çalışanlara verilen eğitimlerde hep Agile çerçevesinin altı çiziliyor ve keskince hatları belirlenmeye çalışılıyor. Bunu yaparken belki de unutmamamız gereken bir şey var ki; o da Agile metodolojinin kavramlarını, popüler ve trend haline gelmiş sözcükleri ve aktivitelerini ezberlemek yerine daha derinini keşfetmek! Tam düşünürken zihnim Richard Feynman’ın şu çok sevdiğim sözünü kulaklarıma fısıldıyor: ‘’Bir şeyin sadece adını bilmek, -bilmek- değildir’’. Hadi gelin bugün hep birlikte çok fazla irdelenmeyen “Agile”ın ne olmadığına birlikte bakalım.
En temel yapı içinden başlayacak olursak, bir organizasyonda “Agile” sadece IT ekiplerinin uygulayıp, kullanacağı bir metot, bir iş yapış şekli değildir! XP, kanban, scrum gibi yaklaşımları sadece IT ekiplerine uyarlamak dönüşüm zincirinin parçalarını eksik bırakacaktır. Hızlı ürün çıkabilme, pazardaki fırsatları yakalayabilme, daha yalın, daha az maliyetle daha çok üretebilme için Agile yapmak değil, Agile olmak gerekir! Agile olmak ise; yakalanmak istenen fırsat ya da çözülecek bir problem için talebin doğması ile üretilen her bir parçasının kod taşımasına kadar uzanan tüm döngüsünde “Business Agility” kavramının anlaşılmasıyla gerçeğe ulaşır. Başarılı bir Agile metodolojisi kültür dönüşümü ile desteklenmiş olmasının yanı sıra, akışta olma halinden yapma haline geçmesiyle gerçek çevikliğe ulaşılabileceğini mümkün kılar. Bu çevik yaklaşımın tarihçesine bakıldığında IT’nin çok ötesinde olduğu, bugün birçok firmanın inovasyon süreçlerini iyileştirmede uçtan uca entegre kullandığı yadsınamaz.
Agile bir işi sadece hızlı yapmak değildir! Organizasyonlarda algılanan bir diğer büyük yanlış ise agile’ın acele iş yapma üzerine kurulu bir kavram olduğu. Çeviklik, yalınlık gibi kavramlar sadece hız ile ölçümlenebilecek değerler değillerdir. Dökümantasyonun daha sade hale gelmesi, planlamanın daha sık ve kısa süreli sprintler halinde yapılıyor olması hızı artırırken, kaliteli iş üretmekten vazgeçmiyor olmak gerekir. Aksi halde metodoloji bugün yaptığını yarın bozan, yarın yapacağınızı da nasıl olsa tekrar bozarım mantığıyla, birçok ihtiyaca kısıtlı ve geçici çözüm üreten bir döngüyü doğurur. Bu yanlış algı belki de büyük resmi gözden kaçırmanızı, fırsatın büyük dilimi yerine ufacık bi ısırığıyla yetinmenizi, ya da problemlere ancak geçici çözümler ile tampon yapmanızı sağlar. Agile bundan çok daha ötesini ifade etmenin yanı sıra aynı hedefe hep birlikte koşan takımların doğru işlere çeviklikle adapte olup, hızlı üretme kabiliyetini geliştirmesiyle evrilir.
Agile iş analiz aktivitesinin yapılmadığı bir yaklaşım değildir! Belki de bu nokta bu metodoloji için yanlış yorumlanabilecek diğer bir parçadır. Yazılım yaşam döngüsünde artık çeyreklik, 6 aylık, yıllık planların çok da fazla işe yaramadığı; çıkarılan tasarım ve kapsamların proje süresince bile hızla değiştiği eskilerde kalmış söylemler oldular bile. Bunlardan vazgeçiyor olmak iş analiz aktivitelerinden vazgeçilmesini kesinlikle doğurmaz. Şirketleri vizyonlarına ulaştıracak işlerin minimum zamanda üretilmesi için organizasyonda iş kollarından gelecek PBI (Product Backlog Item)’ların hazırlanması, önceliklendirilmesi, önemli iş analizi aktiviteleridir. Projelerin “Epic – Feature – PBI (User Story)” formatında kırılması, kabul kriterleri noktasında sağlanacak mutabakatlar, yapılan tasarımlar, tamamlanacak her bir user story’nin tüm sisteme etkilerinin detaylandırılması, en temel iş analizi aktiviteleri olmaya devam edecektir. Bu yapılardan uzaklaşıldığı takdirde; sadece çalışan kod parçacığı üzerinden ürün/süreç detaylarına ulaşmak, kurumsal hafızanın yok olması ve denetimsel birçok sıkıntıyı beraberinde getireceği gerçeğinden kaçılamaz.
Agile yaklaşımda “işleri kırmak” sadece küçük parçalara ayırmak demek değildir! Çoğumuz okuduğumuz her kaynakta, incelediğimiz her uygulamada agile oluş şeklinde en fazla değişikliğin büyük, detaylı, kompleks kapsamlardan vazgeçmek ve uzun soluklu geliştirme süreçleri yerine çok kısa sürede parça parça üretime geçebilmek olduğunu anlıyoruz. Burada yanlışa düşülmemesi gereken en kritik nokta sprintler içerisinde ufak waterfall SDLC döngüleriyle proje yapmaya devam etmek olacaktır. Sprint içerisine alınan her item’ın müşteriler/kullanıcılar için anlam ifade eden, tamamlandığı noktada mutlaka + değer sağlayacak olması kaçınılmaz gerçekliktir. Burada da en büyük sorumluluk Product Owner rolüne düşmektedir. Sprint’e alınacak her bir PBI, MVP dediğimiz kavramı desteklemek zorundadır. Yani PBI’lar, müşterilerin zihinlerinde canlandırdığı ürün/hizmetler için şirket stratejileri ile aynı doğrultuda olacak şekilde çalışabilir en temel özellikleri içeren minimum parçalar olmalıdır. Burada işi ufaltmak derken sadece belirli zamanda bir kısmını tamamlamak değil, anlamlı küçük parçalarını sprint içerisine alabilecek kadar kırmak gerçek çevikliktir. Böylece organizasyonları doğru işi üretmede bir adım daha öne çıkaracaktır. Her ne kadar karmaşık, birbirine bağımlı birçok paydaştan oluşan, regülasyonu yüksek, maliyeti fazla yazılım projelerinde bu iş parçalama güç olsa da, gerçek bir agile oluşumunda bu aktivite için gereken eforu harcamak boşa geçen bir zaman olarak ifade edilemez.
Agile yaklaşımda aktiviteleri bireysel bakış açısıyla yürütmek mümkün değildir! Agile tarihine de bakıldığında bu çerçevedeki scrum, kanban, lean gibi metotların tamamı kendi içlerinde takımsal oyunu barındırır. Örneğin Scrum’ı örnek alacak olursak, yapılan daily toplantılarında o gün hangi işlerle uğraşıldığının telaffuz edilmesinin yanı sıra bakış açısı sprint’e bütünsel yaklaşabilmek, takımca o günü en faydalı planlayıp akışa geçmek gerekliliğidir. Yani takım bakış açısı korunur. Sprint planlamada verilen commitment çerçevesinde; sprint sonunda ortaya çıkan “velocity”, “innovation rate” gibi elde edilen çıktılar tüm takım tarafından değerlendirilir. “Retrospective” süreçleri bireysel tartışmalara dönmemeli, takımca sprintin başarısı / başarısızlığı değerlendirilmelidir. En nihayetinde de Agile oluşta tüm aktiviteler her zaman takım çalışmasına dayanır. Hedefe birlikte koşabilen, yetkin kişilerden kurulmuş takımlar çevikliği çok daha yüksek noktalara taşıyabilenler olacaklardır.
Tüm bu “… ne değildir” penceresinden derinlere baktığımizda gördüklerimizi içselleştirebilirsek belki de bu sade, daha yalın, daha değerli işi kısa sürede üretme oluşunu yani AGILE’ı daha iyi anlayabiliriz. Metodolojinin önerdiği rolleri öylesine dağıtmak, aktivitelerin hakkını vermeden gerçekleştirmek, iş kırmayı tek cümle ile tarif etmek olarak algılarsak; çevikliğin yanı sıra üretim kalitesinde azalış, verimsiz süreçler, motivasyonu düşük çalışanlar ve mutsuz müşteriler elde ettiğimiz insightlar olacaktır. Yazılım dünyasının içinde bulunduğu dönüşümün hakkını vermek, yalınlık ve sadelik çatısı altında üretim hızını arttırmak, değer yaratmak için Agile’ın altında yatan felsefe anlaşılmalı ve sürekli öğrenme yöntemiyle organizasyonların kendi kültürleriyle uyumlu evrilmiş takımları oluşturması faydalıdır. Transformasyon sürecinde şirketler kendilerini Agile rüzgarına bırakmamalı, aksine rüzgarı tam arkalarına alarak (Agile oluş) ilerlemeleri gerçekliğinde yaşamalıdırlar.
Bahattin Emre Özdemir
BA-Works