30 Yıldan fazla geçmişi 20 yıllık şöhreti ve 10 Yıldır da herkesin gözdesi olmayı başarmış bir kavram Agile yani Çeviklik. Aslına bakarsanız güneşin doğduğu topraklarda yazılıyor bu hikayenin özü. Toyota Üretim Sistemi kurmak için en iyisini yapmaya çalışıyor, israfı ve hatayı önlemeye ve de KAIZEN ile sürekli iyileştirmeye başlıyor bundan neredeyse 60-70 yıl önce. Batı geliyor bunu alıyor herkesin benimseyeceği bir hale LEAN yani YALIN isminde bir tanımlamaya sığdırıyor. Üretimde bu yaklaşımlar yıllar yılı hem kullanılıyor hem geliştiriliyor. Kısıtlar teorisi, KANBAN ,kartlarla durum takibi, POKE YOKE derken. Üretim 5S, Toplam Kalite Yönetimi gibi teknikler uygulayıp kendini çok iyi yerlere getiriyor. Teknolojinin gelişimi ile bugün Endüstri 4.0 konuşulurken aslında süreçler ve sistemler bu mantıkla tasarlanmaya ve iyileştirilmeye devam ediyor.
Peki üretim sürecindeki gibi bir süreç olan proje yönetim sürecinde de kaynak kısıtları varsa, hız önemliyse, kuyrukta bekleme olmamalı diyorsak ve hepsinden de önemlisi ne yapabileceğimizi bilerek ya da yaptığımızın olup olmadığını bilerek hareket etmemiz bizi başarılı yapacaksa üretimin başardığını projelerde de başarabilir miyiz? Bu sorunun cevabına EVET diyenler bir çok fikir attılar ortaya ve sonrasında da bu fikri ortaya atanlar bir araya gelip bunun genel adına Agile dediler. Esinlendikleri üretimden çok fazla esinlendiler ama kendi gerçeklerini göz önüne alarak farklı prensipler de belirlediler. Üretim sürecindeki talimatlardan ziyade ekip içi iletişimin önemli olduğunu, sözleşme maddelerinden ziyade müşterinin beklentilerinin önemli olduğu bir yapı önerdiler. Üst kavramlarda anlaşsalar da onlarca çevik uygulayıcısı kendi pratiklerini yazdı. Çoğu da şirketleşti, kendi kitaplarını, kendi sertifika sınavlarını üretti ve bu konuyu ayrı bir ticarete dönüştürdü. Burada durup düşünmemiz gereken bir şey var. Agile yapılır mı? olunur mu? cevap basit Agile olunur çünkü agile bir felsefe, agile bir kültür agile bir uygulama çerçevesi. Agile’a bizi üretilen farklı yaklaşımlar yakınlaştırmalı diyoruz ama her geçen gün bu yaklaşımların bizi farklı yerlere götürdüğünü de görüyoruz. O nedenle önemli olan agile felsefesini anlamak, benimsemek ve uygulayabilmek. Uygulamada kurallar olabilir ama felsefenin çerçevesini değiştirmeden bu kuralların uygulanması önemli.
Burada da en önemli görev projelerin yürütüldüğü organizasyonların yöneticilerinde. Bu değişim ve dönüşümü başlatmak hiç kolay değil. Önce yöneticilerin kendisi agile olmalı ki biz onlara hizmetkar lider demişiz. Kendi kendini yöneten ekipleri motive eden ve onların sorunlarını çözen yöneticiler. Talimat veren veya kontrol eden değil. Ekip’in tabi ki bir düzeni olacak, tekrarlı döngülerinde neler yapacağını planladığı. Bu planlamada ve yolda ona yardımcı olacak, öncelikleri belirleyen ve son karar veren yetkili bir iş birimi sorumlusu çok önemli. Hız ve kalite ne kadar önemliyse ekip içi görüşmeler de o kadar sık ve kolay olmalı. Aynı yerde çalışmalar, her gün aynı yerde aynı saatte yapılan görüşmeler. Her tekrarlı döngü sonunda yapılanların gözden geçirilmesi ve deneysel olan bu sürecin gerektiğinde başa dönmesi de önemli. Ekibin bir durup düşüneceği kendini sorgulayıp daha iyisini arayacağı görüşmeler de olmalı. Bütün bu yapılması gerekenler için bir süre sınırı olması her günümüz her anımız toplantı olmaması için çok önemli. Felsefemiz iletişim, sık sık yapılanı konuşma ve çözüm odaklı olma iken tüm bu kurallar da bunu yapabilmemize imkan sağlayacak ama büyük olmayan bir ekiple. Bunu yapabilen ve başarabilen proje ekipleri var ama projelerinin yapısı, şirketleri, proje ekip üyeleri ve diğer tüm koşulları onlar için bir avantaj diye düşünüyoruz. Agile olmaya çalışanlar ya da agile olduğunu sanıp agile yapanlar hatta agile kurallarını geleneksel süreçlerde uygulayanlarda var. Bu onların eksikliği değil. Bu onların mecburiyeti. O nedenle Hibrit konuşuyoruz hatta Blended yani Harmanlanmış Yaklaşımlar konuşuyoruz. Her zaman hedefe giden birden fazla doğru yol vardır. Hedefe giderken yolda gidiş tarzınız da değişebilir. Hibrit ve Harman Yaklaşımlar bunu ifade eder. Başka bir deyişle gerektiğinde gerekeni yapmaktadır doğrusunu yapmak.
Proje dünyası bunları kendi içinde yaşarken hızını alamayan uygulayıcılar çoktan Organizasyonel Çeviklik ve İş Çevikliği söylemlerini yaygınlaştırdılar yani sadece bir projede değil diğer tüm iş birimi çalışmalarında aynı felsefe verim, hız ve kalite getirecek dendi ve denendi. Bunun da güzel uygulandığı şirketler oldu. Çünkü işin sırrı değişimi ve dönüşümü başarmak. İletişimi geliştirmekle başladılar çalışmalara daha kısa döngülerle planlama yapıp, sonuçları yani olası başarısızlıkları erken fark ettiler. Bu da işin en önemli parçası olan değişime adaptasyonu sağladı. Kimi zaman öncelik kimi zaman talep değişti, kimi zaman da devir değişti. Onlar da bu değişime ayak uydurarak iş yaptıkları ölçüde başarılı oldular. Herkes bunu başarabilir mi? diye sorarsanız bence EVET. Çünkü bu anlatılanlar insanlarla ilgili, bizim yaşadığımız sorunlarla ilgili. Temelinde yine bizden çok önemli kilit konular var. İletişim, iş birliği, ekip olma, güven, hız, kalite ve memnuniyet. Bunlar uygulanırsa başarı da elde edilir.
Uzun lafın kısası 100 yıldan fazla geçmişi olan modern proje yönetiminin 30 yıllık çevik yaklaşımlarla mücadelesi her geçen gün farklı değişikliklerle bizi şaşırtan dünyada beklendiği gibi çevik yaklaşımların galibiyetiyle devam ediyor. Fakat bu iki kavramı bir birine rakip görmemiz gerektiğini de bildiğimiz için bu yenilgiyi resmileştirmeden yapabileceğimiz en iyi şey projesine hatta projenin içinde sürecine uygun geleneksel, çevik, hibrit ve harman yaklaşımı uygulamak olacaktır. Çünkü çevik yaklaşımların cevap vermeye uğraşmadığı bir çok sektördeki uygulamalara sahip olduğumuz geleneksel kaynaklar cevap verebiliyor. Bu nedenle gelecek, geçmişine hakim, geleceğe hazır, bugünün değişimini yönetecek kadar tüm yönetim yaklaşımlarını bilerek uygulayanların olacaktır.
Aşağıda kalan işi Sprint boyunca “kalan saat toplamı” cinsinden izleyen bir takımın Sprint Burndown Grafiği görülüyor. Bu takım aynı A3 boyutundaki grafik üzerine her Sprint’i farklı renklerle çizerek takımın genel olarak oturmuş olan temposunu ve kapasitesini de açık bir şekilde gösterebilmiş. Takımın 3 haftalık Sprint’ler koştuğu, Sprint’in her gününde Daily Scrum sonrası kalan işin saat toplamının ne olduğu grafikte açıkça görünüyor. Aynı kağıt üzerinde ardışık Sprint’lerin gösterilmesi sayesinde bu grafiğe bakarak şu yorumu yapmak da oldukça kolay. Takım ilk Sprint’in sonunda hedeflediği işleri bitirebilmenin oldukça uzağında kalmış, ikinci Sprint’te belki fazla temkinli davranmış ve bu sefer de Sprint’e aldıkları işi hızlı eritip Sprint’in beşinci gününde Sprint Golü’nden sapmadan ve elbette Product Owner’ın geçerli öncelikleri doğrultusunda ek iş almışlar. Sprint-3’ten itibaren ise takımın kapasitesi ve eritme hızı ortaya çıkmış. Şeffaflık o kadar yüksek ki, bu üst üste çizilen Sprint Burndown Grafikleri sayesinde, bir takımın Tuckman Modeli’ndeki doğal adımlardan bu takımın da geçip sonunda iyi işleyen takım haline geldiği bile açıkça görülüyor. Bu tam da Scrum takımlarında yaratılmasını istediğimiz şeffaflığa güzel bir örnek oluşturuyor.
Emre Alıç, PMP 