Scrum'da Uygulanan Kötü Pratikler

Scrum uygulanırken bir çok farklı pratik ile sıklıkla karşılaşırız. Bunların bir kısmı iyi pratikler olarak görülebilir ancak kayda değer bir kısmı da Scrum’ın temel prensiplerine ters düşen uygulamalar olarak göze çarpmaktadır. Bu yazıda Daily Scrum toplantılarının amacından sapması, sprintlerin belirsiz sürelerinin olması, planlama yaparken aşırı düşünme, sahip olunan scrum rolü en iyi nasıl uygulanır gibi bir çok noktaya değinilmiştir.

Scrum Etkinlikleri

Sprint

Sprintlerin süresi değiştirilemez ve içeriğinin de mümkün olduğunca değiştirilmemesi gerekir. Bu yüzden sprint hedefine ulaşabilmek için süreyi uzatmamak gerekir. Sprint içerisinde tamamlanmamış olan işler product backloga alınır ve sonraki sprinte dahil edilebilir. Sprint uzamaya başladığında ne kadar uzayacağı belli değildir. Sprint uzatılırsa toplantılar da planlanan zamanlarda yapılamaz ve ertelenir. Bu da planın bozulmasına sebep olur ve hatta sprintin ne zaman biteceği belli olmadığı için plansız ilerlenmesine sebep olur. Bu durumda -yani sprint süresini uzatılma ihtiyacı hissettiğimizde- tahmin süreci iyileştirilmelidir. İşlerin büyüklük tahmininde hatalar olmuşsa, işlerin yeterince açık olmaması nedeniyle tamamlanma sürecinde ekstra yapılacak işler çıkmışsa veya buna benzer şekilde daha önceden yapılan planı bozacak veya geçersiz kılacak durumlar oluşmuşsa bunlar değerlendirilmelidir. Örneğin, bir sprintte belirlenen sürede tamamlanamayacak bir iş varsa bu hataya tekrar düşmemek gerekir. Sonraki sprintlerde işler ona göre parçalanmalı ve hedefler de buna göre belirlenmelidir. Sprint uzatılınca sprint tamamlanmış gibi olduğu bu için scrum uygulamasında yapılan hataların görülememesine yol açabilir. Mesela tahmin süreci iyileşmez ve büyük işler product backloga eklenmeye devam edebilir. Yani genel olarak sprintin uzatılması ihtiyacını hissetmeye sebep olacak problemlerin çözülmesi ve bir sonraki sprint için planlamanın ona göre yapılması gerekir. Planlama tamamlandıktan sonra da sprint backloga iş eklenmemelidir. Çünkü eklemek odağı dağıtabilir, takım üzerinde baskı oluşturabilir ve hedefe ulaşılamamasına sebep olabilir. Bu durumların sonucunda takımın morali bozulabilir.

Scrum kılavuzunda “Sprint, diğer tüm etkinlikleri içinde barındıran bir etkinliktir.” ifadesi vardır. Yani sprint ile ilgili tüm etkinlikler sprint içinde yapılır. Sprint süresi dolduktan sonra toplantıları yapmak scruma aykırı bir davranıştır. Bu yüzden toplantılar da sprintin bir parçası olarak düşünülmeli ve planlama buna göre yapılmalıdır. Ayrıca bu etkinliklerden birinin yapılmaması scrumın temel direklerinde zayıflık oluşturur. Mesela sprint retrospektifin yapılmaması gözlem (inspection) ve adaptasyonun gerektiği şekilde yapılamamasını sağlar. Tüm etkinlikler, scrumın önemli bir parçasıdır ve plana uygun olarak yapılmalıdır.

Sprint hedefinin belirlenmesi sprintte yapılacak işler için ortak bir amaç oluşturur ve takımdakilerin bireysel amaçlar yerine bu ortak amaç için beraber çalışmalarını sağlar. Eğer sprint hedefi planlamadan önce belirlenmez veya planlama sırasında tam olarak kesinleşmezse sprint backloga birbiriyle bağlantılı olmayan veya rastgele işler alınabilir. Bu durumda da scrumın faydalarından yararlanılamaz. Eğer hedef belirlenemiyorsa ve bu durum oluşuyorsa ürün belli bir olgunluğa ulaşmış olabilir. Bu durumda ise Kanban kullanmak daha iyi bir çözüm olabilir. Aksi durumda Product Owner, product backlogu olması gerektiği gibi sıralamak yerine paydaşların isteklerine fazla önem verip hedefin odağını dağıtacak şekilde sıralama yapıyor olabilir. Product Owner birden fazla paydaşı temsil edebileceği için bu şekildeki bir durumda hedefe hizmet etmeyen işlerle sprint oluşabilir. Paydaşların istek ve görüşleri ürünün geliştirmesinde rol oynar ama paydaşlar öncelikli olduğunu düşündükleri durumlarda product ownerı ikna etmelidirler ve product owner scrumın dışına çıkmaya sebep olmayacak şekilde product backlogu düzenlemelidir. Bunun yanında birden fazla sprint hedefi belirlemek odağın dağılmasına yol açar ve hedefe ulaşılmasını zorlaştırır. Aynı zamanda organize olmayı ve karar almayı da zorlaştırır. Bir süre sonra hangi hedefin daha önemli olduğu gibi sorulara yol açabilir. Tek hedef belirlense bile sprint hedefine ulaşılamaması anormal değildir. Ulaşılamadığında sprint retrospektifte sebepler tartışılıp iyileştirme yapılmalıdır. Eğer hedefe ulaşamama alışkanlık haline gelirse o zaman Scrum uygulaması doğru ve faydalı olmaz.

“Hardening” veya temizlik sprintleri de scrum felsefesine uygun değildir ve yapılmaması gerekir. “Hardening” sprintleri sürüm çıkılmadan önce ürünün sürüme hazır olduğunu test etmek ve hataları gidermek için yapılır. Temizlik sprintleri ise kodda düzenleme (refactoring) ve hata giderme işlerinin olduğu sprintlerdir. Bu şekilde sprintler yapmadığımızı düşünebiliriz ama eğer sprintte çoğunlukla test işleri, eski hataları düzeltme veya kötü kodları refactor gibi işler varsa bu şekilde sprintler yapıyoruz demektir. Bu duruma gelmişsek Bitti Tanımını tam olarak anlamamışız ve işleri hatalı şekilde kapatmışız demektir. Ayrıca bu sprintlerin de tam olarak bir hedefi yoktur ve bunlar tam olarak planlanamaz. Bu sprintlerde bir gelişme (increment) olmaz ve ürün için yeni bir değer üretilmemiş olur.

Scrum kılavuzunda şu şekilde bir ifade vardır:

Scrum takımı, hızlı davranabilecek kadar küçük ve bir Sprint içinde anlamlı bir işi tamamlayacak kadar büyüktür. Tipik olarak 10 veya daha az kişidir. Genel olarak, daha küçük takımların daha iyi iletişim kurduğunu ve daha üretken olduğunu gördük.

Kişi sayısı fazlalaşmaya başladığında karmaşıklık artar. Daha fazla kişi olması daha verimli olacağı anlamına gelmez. Bu durumda takım ikiye bölünebilir. Takım ikiye bölünürken sorumluluklar olması gerektiği gibi ayrılmalı, takımlara kişiler dengeli şekilde dağıtılmalıdır. Üç veya daha fazla takım olduğunda ölçeklenmiş scrum (Nexus, LeSS gibi) kullanmak iyi olabilir. Birden fazla takım olduğu durumlarda diğer takımların metriklerini göz önüne alarak rekabet etmek uygun bir davranış değildir. Bu durum takım motivasyonuna zarar verebilir. Örneğin bir sprint içinde daha fazla story point tamamlamış diğer bir takıma bakarak rekabet etmek yanlış bir sonuca sürükler. Tamamlanan toplam story point toplam yapılan iş miktarı demek değildir. Bu şekilde davranılırsa takım üyeleri işlere fazla story point verme gibi durumlara sürüklenebilirler ve bu durum sprint planlamanın yanlış yapılmasına yol açar.

Sprint Planlama

Sprint planlama, sprinti başlatan Scrum’daki bir olaydır. Sprint planlamasının amacı, sprintte nelerin sunulabileceğini ve bu işin nasıl başarılacağını tanımlamaktır. Sprint planlaması, tüm Scrum ekibi ile işbirliği içinde yapılır. Scrum’da, sprint, tüm işlerin yapıldığı belirli bir zaman dilimidir. Ancak, harekete geçmeden önce sprinti planlamanız gerekir. İşlerin ne kadar süreceğine, sprint hedefine ve nereden başlayacağınıza karar vermeniz gerekir. Sprint planlama oturumu, gündemi ve odağı belirleyerek sprinti başlatır. Doğru yapılırsa, ekibin zorlanmadığı ve başarılı olabileceği çalışma ortamı oluşturur ve takımın motivasyonunu yükseltir. Kötü sprint planları, gerçekçi olmayan beklentiler belirleyerek takımı raydan çıkarabilir. Bu yüzden öncelikle sprint planlamanın çıktısı olarak sprintin amacını özetleyen ve geliştirme ekibine net hedefler göstermek için “Sprint Hedefi” belirlenebilir. Hedef belirleyerek sprint planlamayı tamamlamaya çalışın. Bu hedefi belirlerken de rasyonel olarak sprinti takımın maksimum kapasitesinde doldurmak da yapmamanız gereken bir diğer husustur. Çünkü, geliştirme ekibinin en önemli başarı faktörü işleri bir an önce tamamlamak haline getiren bu husus düşük ürün kalitesini ortaya çıkarmakla beraber geliştirme ekibinin beklenmedik sorunlarla karşılaştığında tasarruf edeceği zamanı bulmasını engeller. Bu yüzden her zaman ortaya çıkabilecek plansız çalışmalara yer açmak gereklidir. Ayrıca, müşterilerden çok talep gördüğü için kod temelinde kırılgan ilerlemelere sebep olacak geliştirmelere izin verilmemelidir. Bu sebeple geliştirme ekibi ilerlemelerini analizi yapılmış, başarabileceklerinden emin oldukları geliştirmeleri yapmalıdır. Profesyonel Scrum ekipleri teknik mükemmelliği benimser.

Daily Scrum

Scrum kılavuzunda belirtildiği gibi daily scrumın asıl amacı sprint hedefine ulaşılması için yapılan işlemlerin incelenmesi, gerekiyorsa sprint backlogun gözden geçirilmesi ve gelecek çalışmaların planlanmasıdır. 24 saatlik süreci ele alan bir ufak bir planlama toplantısı olmasının yanı sıra kılavuzda da belirttiği gibi sprint hedefine ulaşmak için tüm sprintin bütüncül olarak ele alındığı bir toplantıdır.

Daily scrumların bir rutini olmalı, raporlama toplantısı değil paylaşım toplantısı olmalı, problem çözme yeri değil engellerin ifade edildiği/tespit edildiği yer olmalı, planlama yapılan yer değil gidişatın izlendiği yer olmalı. Takım üyeleri daily scrumda çalıştığı işlerden bahsederken herkesin anlayabileceği şekilde detay vererek konuşmalı, sadece iş numaraları üzerinden konuşmamalıdır. Uzaktan (remote) yapılan daily scrumlarda ise mutlaka ekip üyeleri kameralarını açmalıdır. Yüz yüze konuşamasak da birbirimizi görerek konuşmak hem mimiklerin görünmesi açısından hem de ekrana karşı konuşuyor hissine kapılmamak için önemli bir noktadır.

Sprint hedefine ulaşmayı engelleyen bir durum varsa ifade edilmeli. Çalışılan bir işin uzun süre aynı durumda kalması da daily scrum toplantılarının konusudur. Bunun tespiti için bir görsel kullanılması ve daily scrumlarda tüm ekibin görebileceği yerde olması iyi bir pratiktir. Daily scrumda çok konuşan ekip üyelerinin olması da iyi bir pratik değildir. Bir veya birkaç ekip üyesi her konuda yorum yaparsa diğer üyeler üzerinde baskı oluşturabilir, patronluk hissi uyandırabilir. Daily scrumlarda konuşulan her bilgi sprint hedefi için değerlidir ve her üye dikkatlice dinlenmelidir. Product Owner veya Scrum Master tarafından daily scrumlarda ekip üyelerine işler direkt olarak atanmamalıdır. Problemli veya bekleyen işler varsa sprintin durumunu gösteren çeşitli görseller ile daily scrum esnasında bu durumun farkındalığı sağlanmalı ve ekibin kendi kendine aksiyon alabilmesi için ortam oluşturulmalıdır.

Daily scrumlar sprint hedefine ulaşmak ve gerekli aksiyonları almak için düşünülmüş scrum etkinliklerinden biridir. Ekip üyelerinin son durum hakkında bilgilendirilmesi sağlanır. Bu iletişim yapılırken ekip üyeleri birbirlerini eleştirmemelidir. Eğer olumlu ya da olumsuz eleştiriler ve sonucunda oluşacak uzun tartışmalar oluşacaksa bu tartışmalar ve eleştiriler daily scrum sonrasında yapılmalıdır.

Daily scrumlarda sprint ile ilgili işler konuşulmalıdır. Sprinti ilgilendirmeyen herhangi bir konuya daily scrumlarda yer verilmemelidir. Örneğin iki kişiyle mülakata girdim, X ekibiyle Y konusu ile ilgili görüştüm, A kitabını okudum, Y makalesine göz attım gibi ifadeler sprint ile ilgili değildir. Daily scrum içerisinde konuşulmamalıdır.

Sprint Gözden Geçirme

Takımdaki tüm kişiler (scrum master ve product owner dahil) ve onun davet ettiği paydaşlar sprint reviewe katılmalıdır. Katılım yeterli olmadığında veya gerekli kişiler katılmadığında sprint review anlamını kaybedebilir. Paydaşların katılımı mümkün olduğunca düzenli olmalıdır. Her sprint reviewda farklı paydaş olursa bu kişilerin işleri takibi zorlaşır ve bu kişilerden ya aynı geri bildirimler alınıp zaman kaybedilebilir ya da alınan geri bildirimler yeterli olmayabilir. Sprint review etkinliğinde takım ürün hedefinin şu anki durumunu paydaşlarla tartışmalı ve geri bildirim almalıdır. “Ne yapılacağını zaten biliyoruz.” şeklinde davranış gereksinimlerin tam anlaşılamamasına ve ürün hedefinden sapılmasına yol açar.

Bitmemiş işler sprint reviewda konuşulmamalıdır. Bitti tanımına uygun olacak şekilde tamamlanmamış işlerin burada review edilmesi işin tamamlandığının sanılmasına yol açar. Fakat bu işle ilgili eksik kalan kısımlarla daha sonra karşılaşılır. Sprint hedefine ulaşılamamış olunsa bile sprint review yapılmalıdır. Bu paydaşlarla olan şeffaflık için önemli bir durumdur. Sprintte yapılan işler her zaman olduğu gibi paydaşlarla incelenir ve tartışılır.

Sprint Retrospektif

Retrospektif toplantıları, yazılım geliştirme sürecinde direkt iyileştirme imkanı sunar. Çoğu zaman takımlar retrospektife zaman ayırmak yerine bu zamanı geliştirme eforu için kullanıyorlar ancak başarılı bir retrospektif yapmanın sonraki sprinte etkisi büyüktür. Ancak bazı durumlarda sprint retrospektifi yapmak anlamsız hale gelebilir. Öncelikle retrospektif toplantılarına katılım sadece bütün takım içindir. Eksik veya fazla katılım olumsuz sonuçlar doğurmaktadadır. Retrospektif etkinliğine katılımın tam olması geriye dönük inceleme ve gelen sprinte yönelik iyileştirmelerin faydasını ürüne değer olarak yansıtır. Bunun yanı sıra bir grup insanın işbirliği yapmasını sağlamak yeterince zorken başka bir katman eklemek bu etkinlikte işbirliği yapmasını zorlaştırır. Bu etkinliğin yalnızca Scrum takımı için olduğunu unutmayın. Bunun yanı sıra sprint planlama kısaca takımın bir takım sözlerin tutulduğu bir geliştirme dilimidir. Ekip üyeleri, iyileştirmeler yapma konusunda birbirlerine taahhütte bulunmalıdır. Bu taahhütleri görmezden gelmek, ekibin sürekli iyileştirme zihniyetini benimsemediğinin açık bir işaretidir. Verilen taahhütlerin anlamlı olması da bir bu kadar önemlidir. Kayda değmeyen iyileştirmeler, bir retrospektif toplantısının hızlı bir şekilde tamamlanmasının kolay yoludur, ancak gerçek bir iyileştirme yapılmamış olur. Ekip, maksimum potansiyeline ulaşmak için ilişkilerin ve/veya teknik konuların derinliklerine inmelidir. Retrospektif, sprint gözden geçirme kadar ciddi ve profesyonel bir toplantı olmalıdır. Son olarak sprint boyunca takımlarca tasarrufu en mümkün zamanlardan biri retrospektif için ayrılan zamanlardır. Takım bu zamanı geliştirme için harcama konusunda istekli olabilir ancak bu kısa oturumun sprinti en iyi hale getirmek ve sürecin farkında olmak için yapıldığı unutulmamalıdır. Bu yüzden retrospektifin iptal edilmesi sprint planlama için olumsuzluk oluşturur ve takım sprinti iyileştirme fırsatını kaçırır. Son olarak bir sprint sonunda yapılan katılım bu oturumun bir şikayet oturumuna dönüşmesinden kaçınılmalıdır.

Scrum Takımı

Developers

Scrum kılavuzuna göre, bir ürün parçası (increment) oluşturmak için sprint boyunca efor harcayan her bir scrum takımı üyesi aynı zamanda developerdır. Developerlar sprint backlogu oluşturur ve Bitti Tanımı’na bağlı kalarak kaliteyi korurlar. Çok disiplinli, disiplinler arası bir ekip oldukları için kendi kendilerine organize olabilirler. Scrum etkinliklerinde bahsedilenlerin bir çoğunda developerlar aktif olarak görev aldığı için scrum etkinliklerinde bahsedilen hatalı uygulamaların bir çoğu developerlar için de konuşulabilir. Developerların bahsedilen hataları scrum süresince tekrarlamaması gerekmektedir. Sprint planlama yaparken kapasitenin üzerinde iş alınırsa doğal olarak sprint hedefine ulaşmakta zorluk çekilecektir. Hastalanacak ekip üyeleri, resmi tatiller, bayramlar vb. durumlar dikkate alınarak sprint backlog oluşturulmalıdır. Ayrıca her sprinte kod iyileştirmesi(refactor) için zaman ayrılmalıdır. Aksi durumda teknik borçlar çoğalacak ve ilerisi için daha kötü senaryolar bizleri bekleyecektir. Planlama sırasında kod iyileştirmesine(refactor) zaman ayrıldığı gibi geliştiricilere boş vakitte ayrılmalıdır. Tüm bu durumlar göz önüne alınarak sprint planlama tamamlanmalıdır. Sprint planlama esnasında işler üzerinde ne aşırı tahmin yürütülmelidir ne de yetersiz planlama yapılmalıdır.

Product Owner

Product owner takım üyeleri tarafından gerektiğinde ulaşılabilir olmalıdır. Böylece developerların soruları olduğunda ona ulaşabilirler ve cevap alabilirler. Ulaşılamaz olduğu durumda yanlış geliştirmeler ortaya çıkar. Product owner takımla birlikte çalışmalı ve sorumluluklarını ve övgüleri de takımla paylaşmalıdır. Eğer product owner takımın başarılarının tüm övgüsünü kendine mâl eder veya hataların sorumluluğunu da takıma yüklerse takımın morali bozulur ve güvensizlik ortamı oluşur.

Product backlog, product ownerın sorumluluğundadır. Olması gerektiği gibi güncel ve sıralı tutması gerekmektedir. Gerekli işleri eklemediğinde veya gereksiz (eskiden kalıp geçersizleşen veya yapmaktan vazgeçilen) işleri silmediğinde takımın işleri yönetememesine yol açar. İşler product backlogdayken product owner işler üzerinde istediği gibi değişiklik yapabilir ama sprint backloga girdiği zaman işler developerların sorumluluğunda olur. Bu yüzden product owner değişiklik yapamaz. Değişiklik yapıldığında kapsam değişir ve bu da developerlarda kafa karışıklığına, planın bozulmasına ve hedeften sapılmasına yol açabilir.

Çok önemli bir durum olmadığı sürece sprint iptal edilmemelidir. Sprint hedefi ulaşılamaz olduğunda veya yönetim tarafından hedeften vazgeçildiğinde product owner bu durumu düşünmelidir. İptal için mutlaka takıma danışmalıdır. Sprint hedefi ulaşılamaz olduğunda takımdakilerin hedefe ulaşmak için fikirleri olabilir. Hedeften vazgeçildiğinde yine takımın fikirlerini almalı ve buna bağlı olarak ortak fikirle hareket edilmelidir. Tam tersi durum olduğunda ve sprint hedefine sprint sonundan önce ulaşıldığında product owner product backlogdan yeni iş almaları için takımı zorlamamalıdır. Önemli olan hedefe ulaşılmış olmasıdır. Yeni iş alma takımın verebileceği bir karardır. Takım bu sürede yeni iş almak isteyebilir veya yeni teknolojiler için araştırma yapıp takım içerinde paylaşmak isteyebilirler. Bunun yanında bug fix veya refactoring gibi işler yapmak isteyebilirler.

Scrum Master

Scrum master, çevik proje yönetimini kullanan bir ekibe liderlik eden bir profesyoneldir. Ancak yalnızca bu profesyonelin Scrum konusunda bilgili olması takımda büyük bir engel oluşturur. Bu yüzden Scrum Master’ın yanı sıra ekip üyelerinin Scrum çerçevesi, ilkeleri ve değerleri hakkında ortak bir anlayışa sahip olması önemlidir. Scrum Master, Scrum değerlerine ve uygulamalarına bağlıdır, ancak aynı zamanda esnek kalmalıdır ve ekibin iş akışlarını iyileştirmesi için fırsatlara açık olmalıdır. Scrum Master takımın karşılaştığı her engeli kendi çözmemelidir. Bunun yerine, engelleri kaldırmanın yollarını bulmaları için takımla birlikte çalışmalı ve yardımcı olmalıdır. Bu, kendi kendine örgütlenmeyi koruyarak yetkilendirmeyi ve tüm ekibin sorumluluğunu teşvik eder. Bir kahraman olarak Scrum Master tüm sorunları çözüyorsa, Scrum takımı bu kahraman davranışına bağımlı hale gelir. Sorunları ve engelleri çözmeleri için takıma koçluk yapması, ekiplerin büyümesine, olgunlaşmasına ve birlikte başarıya ulaşmasına yardımcı olabilir. Bu yüzden süper kahraman olmak Scrum Master için uygun değildir. Süper kahraman olmanın yanı sıra otoriter adam olmak da geliştirme sürecine ve takıma destek olmaz. Çünkü, scrum takımları kendi kendini yönetir ve kendi kendini organize eder. Otoritenin scrum takımı üzerinde baskısının hissedilmesi sonucunda takım demoralize olur ve kalitede düşüş gerçekleşir.

Sonuç olarak Scrum çatısı genel hatlarıyla bazı süreçleri ortaya koyar. Bu süreçlerin nasıl uygulanacağı takımların sorumluluğundadır. Takımlar kendi kendilerini yöneten, scrum çerçevesine aykırı bir işlem gerçekleştirmeyen yetkin kimselerden oluşur. Bu sayede kaliteli yazılımlar ortaya çıkar. Scrum’ın tavsiye etmediği uygulamalar sonucunda ki biz bunu bu yazımızda kötü pratikler olarak ele aldık, kalitede düşüş gözlemlenebilir. Bahsedilen kötü pratiklerden ekipler arınırsa Scrum’dan maksimum fayda elde edilebilir.

Kaynaklar

08.12.2022

« Dapr: Service Invocation Dapr: State Management »