Agile yaklaşımlarla çalışma öncesi detaylı proje planları çalışılır, Gantt chart’lar da ise her bir aktivitenin başlama ve bitiş zamanları gösterilirdi. Proje öncesi ne yapılacağı, ne zaman yapılacağı netti. Talep sahipleri de buna göre planlarını yapardı. Talep sahibinden projenin geliştirilmesini sağlayana kadar herkes planının büyük oranda tutmayacağını bilsede bir huzur bir rahatlık içinde olurdu.
Agile dönüşümle birlikte self-organize olan takımlar proje kapsamında ne ve nasıl yapılacağından sorumlu hale geldiler. Önceliklendirmeden sorumlu Product Owner’da takımın içinde. Projenin ne zaman biteceği, ne gibi sürprizlerle karşılaşacağı ile ilgili net bir bilgi yok. Soruların cevabını verecek takım da daha öncesinde bu sorularla muhatap olmadıysa cevaplar tatmin etmeyecektir. Bir anda gerçekleşme ihtimali az olsa bir gantt chart’ın verdiği rahatlığı ve huzuru özler durumda bulabilirsiniz.
İşte bu aşamada Agile ile birlikte öğrenilmesi gereken yeni bir yetkinlik ortaya çıkıyor. “Belirsizliği yönetmek”. Agile ile birlikte belirsizliği yönetme kasımızı geliştirmemiz gerekiyor.
Belirsizlikleri yönetme konusunda fayda sağlayacak bazı pratiklerden bahsedeceğim.
Sprint 0. Design sprint olarak da adlandırabiliriz. Geliştirdiğimiz projeler oldukça kapsamlı/karmaşık olabiliyor, farklı firmaların katılımı ile ortak projeler geliştirilebiliyoruz. Projelerin başında 2-3 haftalık bir sprint 0 koşulabilir. Sprint 0’ın ilk haftası high level seviyede talepler, ihtiyaçlar, beklentilerin değerlendirildiği business ağırlıklı geçirilebilir. Design thinking pratikleri ile de bu haftanın daha verimli ve etkin geçirilmesi sağlanabilir. İkinci haftasında ise high level seviyede teknik bağımlılıklar, mimari yapının değerlendirildiği teknik ağırlıklı geçirilebilir. Hem business hem de teknik anlamda takım ve paydaşların aynı noktada olması, belirsiz noktaların azalması sağlanabilir.
Product Burndown grafiği. Evimizi boyatmak istiyoruz ve keşfe gelen ustaya ilk sorumuz büyük ihtimal ne zamana ve ne kadara yaparsın olur. Bir de birçok paydaşı olan ciddi yatırımların yapıldığı projelere dikkate alalım. Paydaşların takımdan projenin bitiş tarihi ile ilgili öngörü istemeleri çok normal. Bu aşamada takım ise hedefin ne kadar uzaklıkta olduğu o hedefe ne kadar hızla yaklaştığını belirlemesi gerekiyor ki draft bir zamanı tüm paydaşlara verebilsin. Product burndown grafiği ise yol üzerindeki şartlardan dolayı etkilenen hıza göre de dinamik olarak güncellenmektedir. Yönetim ve paydaşlar dinamik olarak değişen öngörü tarihini görebilecek, alınabilecek kararlar için veri sağlanmış olacak. Elbetteki buradaki zaman net bir tarih olmayacak ama hiç tarih olmamasından daha sağlıklı olacaktır ve belirsizliğin azalmasını sağlayacaktır.
Release Burndown grafiği. Yukarı bahsettiğim yöntemin aynısının takımın önündeki ilk release kapsamı için çizilmesidir. Takım önündeki ilk release kapsamını belirleyerek ne zaman tamamlanacağı ile ilgili draft tarihi verilmesini sağlayan grafiktir. Belirlenen tarihe göre üretim ortamına geçiş zamanı verilebilir. Bu da belirsizliğin azalmasını sağlayacakıtr.
Monte Carlo Simülasyonu. Risk analiz tekniklerinden birisidir. Daha önce geliştirilen projelerin, taleplerin tiplerine göre gerçekleşmiş verileri kullanarak bir olasılık oluşturulmaktadır. Aynı tipteki projelerin, taleplerin geçmiş verileri kullanılarak minimum ve maksimum süreleri ortaya çıkmaktadır. Bu veride projelerin tamamlanma süresi ile ilgili belirsizliği azaltacaktır.
Son olarak bahsedeceğim bir pratik değildir. Yalnız şeffaf iletişimden bahsedeceğim. Bir agile takımında olmazsa olmaz bir özellik. Şimdiye kadar tecrübe ettiğim bazı sorunların çok büyümesinin sebebi şeffaf iletişim eksikliği. Paydaşlarla, yönetimle her daim her türlü iletişim kanalı çok aktif olması, her türlü gelişmelerden, risklerden, sorunlardan zamanında iletişim kurulması, güven ortamının kurulması için çok önemli. Güvenin olduğu ortamda belirsiz noktaları yönetmek de daha kolay olacaktır.
