Öğrenci sendromu olarak da bilinen erteleme sendromu, aslında çalışmamak ya da tembellik etmek değil bir türlü başlayamamaktır. Genellikle kökeninde “mükemmel yapmak yerine hiç yapmama” düşüncesi ya da “kötü yapma” kaygısı yattığı için, işe bir türlü başlayamama durumu ortaya çıkar. İşin “kötü” olacağı düşüncesi şevki kırar ve moralsizliğe neden olur. İşe başlamak için tüm istek tamamıyla yok olur. Bir detaya takılıp, o detayı nasıl yapacağı üzerine düşünüp, “mükemmel” olması için saatlerce araştırmalar yapıp, zamanın kısıtlı olduğunu da unutacak kadar detayda boğulup sonuçta hızla yetiştirmeye çalışmak zorunda kalınır ve “mükemmel yapma” iddiasından eser kalmaz. Erteleme sendromuna stresin eşlik etmesinin temel nedeni kaygıdır. Başlangıçta “kötü” yapma ya da “mükemmel” yapamama kaygısı yerini daha sonra yetiştirme kaygısına bırakır.
Procrastination bir kişide olabileceği gibi bir kültür olarak şirket çalışanlarına da bulaşabilir. Bir işin tüm detaylarına hakim olmadan hiç bir parçasına bile başlayamamak, işin bütün detaylarına derinlemesine hakim olmadan işin büyüklüğünü tahmin edememek, mükemmel bir tasarıma ulaşmak için bitmek bilmeyen toplantılar yapmak, işin içeriğini ve katacağı değeri göremeyecek bir körlük ile her işin muhteşem olması gerektiği düşüncesiyle temel hedeften uzaklaşmak vb. kurum davranışları sonucunda bir türlü başlanamayan işe zamanın kısıtlı olması ve yetiştirme kaygısı eklenir ve tüm çalışanlar stresi yoğun olarak hissetmeye başlar.
Scrum uygulama iddiasındaki kurumlarda takımlar büyüklük tahmini yaparken, erteleme davranışına kapılabilirler. Bu durumun, planlamayı ve işi “mükemmel” yapmak kaygısından kaynaklanma olasılığı oldukça yüksektir.
Bir işi kusursuz yapmak için tüm detaylarına hakim olunması gerektiği düşünülür ve takım tüm teknik tasarımı yapabilecek düzeyde her detayı en ince ayrıntısına kadar düşünüp hesaplamadan işin büyüklük tahminini yapmak istemez.
Bir işe başlamak ya da bir işin büyüklüğünü tahmin etmek için, işin yapılması amacıyla gerekli olan teknik ve teknik olamayan bütün detayları bilmek gerekir mi?
Bir inşaat projesi ile ilgili işin büyüklüğünü tahmin edeceğinizi varsayalım, 3 katlı tek bir apartman içerisinde 6 daire olacağını düşünelim, bu inşaatın yapımı için ne kadar süreye ihtiyacınız olduğunu tahmin edeceksiniz. Bunun için kullanılacak inşaat demirlerinin teknik detaylarını, onların nasıl dikileceğini, tuğlaların ölçülerini, kumun cinsini, nasıl örüleceğini vs bilmeniz gerekir mi? Daha önce yapılmış benzer bir yapı ile karşılaştırarak, ayrılacak bütçe, çalışacak insan sayısı ve kullanılabilecek iş makinaları gibi bilgilerden sonra inşaatın ne kadar sürede bitebileceğini yaklaşık olarak söyleyebilirsiniz. Benzer bir inşaatın ne kadar sürdüğü de size fikir verecektir.
Yazılım projelerinde yapılacak işin büyüklüğünü tahmin etmek de benzer şekilde bütün detaylara hakim olmanızı gerektirmez. Eğer ki işin tamamlanacağı süreyi tahmin etmeniz istenseydi şüphesiz her bir görevi detaylı olarak çıkarıp işin tamamlanması için gerekli bütün adımların ne kadar süreceğini bilmek isteyecektiniz, fakat işin süresi değil büyüklüğünü tahmin etmek
istememizin nedenlerinden birisi de süre tahminine oranla daha kolay verilebilmesidir. (Şüphesiz ki bu tek neden değil.) İşin tamamlanması için gerekli tüm sürenin tahmin edilmesi zordur çünkü işin tamamlanmasını etkileyen bütün faktörlerin öngörülüp hesaba katılması gerekir. Farklı tecrübe ve özellikteki takım üyelerinin hangisine göre süre tahmini yapacağımızı bilemeyiz bu nedenle, işin büyüklüğünü tahmin etmek ve takımın hızını hesaplamak uzun vadede takımın ne kadar iş çıkaracağını bize gösteren gerçekçi bir metrik olmalıdır.
Bir işin büyüklüğü ise herkes için aynı olan bir ölçüm aracıdır tıpkı uzaklık, ağırlık vb hesaplamaları yapabilmek amacıyla kullandığımız ölçüm birimleri gibi. Bir işin büyüklük cinsinden ifade edilmesi amacıyla “story point” , t-shirt size, 1-10 arası büyüklük rakamı vs. kullanabiliriz. Büyüklük zaman birimi değildir. A ile B lokasyonları arasında 1 km’lik bir mesafe olduğunu varsayalım, tabii ki yürüyerek ya da araba ile bu iki mesafe arasını gitmenin alacağı bir süre vardır ama aralarındaki uzaklık bir başka birim ile ölçülür. Yazılım geliştirme işlerinin de bir büyüklüğü vardır ve bu büyüklük tahmin edilirken diğer bir yazılım işi ile kıyaslanabilir.
2 lokasyon arasındaki uzunluğu tahmin etmek için tam olarak nasıl gidileceğini, hangi araç kullanılacağını düşünüyorsanız süre tahmini yapma niyetindesinizdir. Aradaki mesafeyi tahmin etmek için bu bilgilere ihtiyacınız yoktur. Yazılım işlerinde de büyüklük tahmini yapmak için software design yapmaya, işlerin nasıl yapılacağını tüm detayıyla bilmeye ihtiyacınız yoktur. İşlerin yapmak için gerekli süre, sizin onu nasıl yapacağınıza göre değişse de bu o işin büyüklüğünü değiştirmez.
İşte mükemmel bir tasarım oluşturmak, hiç hata yapmamaya çalışmak, tam isabet estimation vermek, nasıl yapacağını tam ve net olarak çıkarmadan estimation vermemek, planlamanın kusursuz olması için kusursuz tahminler yapmak, story’nin yapılması için gerekli her şeyi en ince detayına kadar kontrol altında tutmaya çalışmak vb nedenler ile büyüklük tahmini vermemek ya da sprint’i ertelemeye çalışmak scrum takımlarında görülebilen ve mutlaka geliştirmesi gerekli ilerleme noktalarından birisidir.
Tabii ki, story’nin kabul kriterleri net değil ise, gereksinim net olarak tarif edilemiyorsa, ne yapılacağı anlaşılamıyorsa takım story için büyüklük tahmini yapamayacaktır. Ama erteleme hastalığı bu durumdan oldukça farklı. Takımın story kabul kriterleri belli iken büyüklük tahmini yapmak için derin teknolojik araştırmalar yapmaya ihtiyaç duyması, yazılım mimarisini tam olarak kendi aralarında netleştirmeye çalışması vb yukarıda bahsettiğimiz durumlar.
Erteleme sendromu scrum takımı sprint koşarken de karşısına çıkabilir. Bir iş parçacığına başlayamamak sprint hedefinden sapılmasına yol açacak seviyelere bile gelebilir. Takım üyeleri bu gibi durumların sinyalini günlük scrum toplantılarında verebilir. Bu nedenle scrum master’ların ve agile coach’ların bu duruma dikkat etmeleri ve takımın başlayamama sendromuna yakalanıp yakalanmadığını fark etmeleri için, özellikle günlük scrum toplantılarını bu gözle izlemeleri gerekir. Günlük scrum toplantılarında takım uzayan design tartışmaları yapıyorsa, bazı iş parçalarına bir türlü başlanamıyorsa scrum master’ın durumu fark edip bir geliştirme noktası olarak takımın önüne getirmesi gerekir.
