Scrum metodolojisinin sağlıklı çalışabilmesi için en doğrusu takımın tek bir odada birlikte çalışmasıdır
Omnichannel’in şirketlerin hayatına girmesi ile birlikte müşteri deneyimlerinin değiştiğini, buna bağlı olarak da şirket içinde ürün hazırlama süreçlerinin değişmek zorunda kaldığını belirtmiştik.
Bu bakış açısı ile belirsizliğin (VUCA – Volatility, Uncertainty, Complexity, Ambuiguity) arttığı günümüz iş dünyasında özellikle IT projelerinde artık eskiden kullanılan şelale (waterfall) tarzı proje yönetim metodolojilerinin kullanılamayacağından, bunun yerine daha çevik (agile) metodolojilerin kullanılması gerektiğinden bahsetmiştik. Örnek olarak da scrum’ı göstermiştik.
Peki iş dünyasındaki bu belirsizlik ve karmaşıklıktan etkilenen sadece IT fonksiyonu mudur? Diğer fonksiyonların yönetim ve proje/ürün geliştirme yöntemlerinde bir değişikliğe gitmek gerekmez mi? Ya da daha açık bir ifade ile scrum proje yönetim metodolojisi IT dışındaki fonksiyonlarda da kullanılabilir mi?
Tekrar hatırlatmak gerekirse; scrum, öngörülebilirliği en iyi seviyeye çıkarmak ve riski kontrol etmek için iterasyonlu ve artımlı (incremental) bir yaklaşım kullanır. Bunları yaparken 3 konuya odaklanır; şeffaflık, gözlem ve adaptasyon.
Konuya bu açıdan baktığımızda IT dışındaki fonksiyonların da efektif kaynak (zaman ve para) kullanımı ihtiyacının olduğunu görüyoruz. Özellikle de birçok fonksiyonun birlikte katıldığı projelerde bu yaklaşımın etkisini çok daha iyi bir şekilde görebiliriz.
Peki bu durumda scrum’ın hangi kuralları ve ritüelleri bu tip çok fonksiyonun katıldığı projeler için efektif bir yöntem olarak uygulanabilir?
- Öncelikle bir veya ikişer haftalık sprint’ler koşmadan önce ilgili fonksiyon içinde bir yol haritasının (roadmap) hazırlanmasında fayda var. Bu yol haritası, gidilecek yolu genel hatları ile tanımlıyor olmalıdır.
- İlgili yol haritası içinde bir MVP (Minimum Viable Product) tanımı yapmanın çok büyük bir faydası var. Aksi takdirde “en iyi, iyinin düşmanıdır” sözünün ne kadar doğru olduğunu ispatlarcasına detaylarda boğulma ihtimali artar.
- Yol haritası ve MVP tanımlandıktan sonra, artık odaklanmış bir şekilde, scrum’ın diğer uygulamaları kullanılıyor olur. Buradaki en önemli konulardan bir tanesi takım toplantılarının klasik olarak konuların sadece tartışıldığı bir toplantı şeklinde değil, doğrudan işlerin çözüldüğü workshop şeklinde yapılıyor olmasıdır. Bu bakış açısına sahip olduktan sonra aşağıdaki ritüelleri uygulamak daha kolay ve verimli olacaktır:
a)Daily stand-up toplantıları: Temelde her bir takım üyesi dün ne yaptığını, bugün ne yapacağını anlatırken dün neyi yapabilse daha iyi sonuç alabileceğinden de bahseder. Ayrıca takım arkadaşlarından istediği yardımı belirtir.
b)Sprint review/retrospective toplantıları: Sprint sonucunda sprint’in genel değerlendirilmesinin yapıldığı ve birçok dersin çıkarılıp dokümante edildiği toplantılardır. Sprint’lerin kalitesinin artması için çok büyük önemi vardır.
c)Sprint planlama toplantıları: Sprint’e başlamadan önce eldeki yapılacaklar (backlog) havuzundaki işlerin önceliklerine karar vererek ve elde kaynakların iş bitirme kapasitesine bakarak üzerinde mutabık kalınan görevlerin (task) ilgili sprint’e alınmasına karar verildiği toplantılardır. İlk başlarda kapasite kullanımlarında öngörü hataları olabilir. Ancak süreç ilerledikçe sprint planlama aktivitesinin kalitesi artacak ve sprint sonunda takımın üzerine aldığı tüm işler tamamlanmış olacaktır.
Bu metodolojinin sağlıklı çalışabilmesi için en doğrusu takımın tek bir odada birlikte çalışması ve yukarıda bahsedilen toplantılarını burada duvarda asılı olan bir pano (board) üzerinde görselleştirilmiş şekilde çalışmasıdır. Bu deneyimin benzerinin dijital ortamda yaşanmasını sağlayan Trello benzeri programlar da kullanılabilir.
Bu bakış açısı ile sadece IT ekiplerinin değil, tüm çoklu fonksiyon projelerinde ekiplerin daha hızlı, daha verimli ve daha keyifli iş yapmasının mümkün olacağını düşünüyorum.
Diğer e-ticaret köşe yazılarını okumak için tıklayın.
E-ticaret Çağı Mart sayısını ücretsiz okumak için tıklayın.
You may also like
