Scrum Seremonileri

Scrum seremonileri diğer scrum uygulamalarına da olduğu gibi her firma ve ekibe göre değişik yöntemlerle ve çeşitlerle uygulanabilir. Temelde beş farklı scrum seremonisi varken, bunları değiştirip dönüştürmek ve kendimize uyarlayarak yeni seremoniler türetmek mümkün. Öncelikle bu beş temel scrum seremonisini tanıyalım. 

Daily 

En yaygın ve hemen her ekibin uyguladığı scrum seremonilerden biri olan daily, aynı zamanda stand-up ya da sabah toplantısı olarak da kullanılabilir. Her gün scrum ekibindeki developerlar başta olmak üzere, scrum master ve product owner (kimi firmada bu rol project manager olarak da değişebiliyor) en fazla 15 dakika sürecek olan bu toplantıda bir araya gelerek proje gidişatını konuşur. Daily, herhangi birine bağlı bir toplantı değildir; yani ekipten herhangi biri katılamasa dahi geri kalanlarda mutlaka her gün düzenli olarak yapılır. 

Daily neden yapılır? 

Birçok developer daily’lerin faydasını anlamayıp bunun bir zaman kaybı olduğunu görebilir. Böyle düşünen bir developer daily’lere genelde hazırlıksız gelir ve daily sırasında dikkatini toplantıya pek fazla veremez. Böyle durumlarda scrum master, developerlara daily’nin bir proje raporlama seansı olmadığını, bunun tüm ekibin projenin geneli ve projede çalışan her bireyin çalıştığı kısım hakkına bilgi sahibi olması için bir yardımlaşma seansı olduğunu açıklamalı. Daily’lerin amacı genelde ekibi tıkayan durumları çabucak tespit etmek ve bu tıkanıklığı çözecek ideal çözüm yolu ve destek verebilecek kişileri organize etmektir. Bu sayede proje daha hızlı akabilir ve eğer ihtiyaç varsa da kolayca yön değiştirebilir. 

Developerlar, daily sırasında yaşadıkları problemden bahsetmekten çekinebilir. Takım arkadaşlarının onun yaşadığı problemi aptalca bulmasından, soru sorarak toplantı zamanını çalacak olmaktan dolayı sorularını sormamayı tercih edebilir. Yine scrum master olarak, developerlara bu vaktin zaten projedeki problemleri çözmek için ayrıldığını, dolayısıyla developerların soru sormaktan çekinmemeleri gerektiğini, bir takım lideri gibi değil, bir dost olarak anlatmalı. Eğer dailyler yapılmazsa, sırra kadem basmaya eğilimi olan developerlarınızın günlerce ne yaptığına dair hiçbir fikriniz olmaz. 

Daliy toplantılar aynı zamanda ekibe yeni katılan kişiler için de daha hızlı bir adapatasyon imkanı tanır. Yeni ekip üyeleri, kendilerine verilen işi, mesai saatleri boyunca inceleyip keşfetmeye çalışırken, dailylerde projenin geneliyle ilgili bilgi sahibi olur ve kendi sorumlu olduğu kısmı da daha iyi kavrayabilir. 

Daily için göz ardı edilmemesi gereken hatalar

• Katılım sağlamamak : Geçerli bir mazereti yoksa (çok yoğun olmak bir mazeret kabul edilemez)  tüm ekip üyeleri her gün katılmalı. 
• Geç kalmak : Katılım mutlaka tam saatinde olmalı. Aksi halde bu davranış biçimi kronikleşebilir. 
• Scrum’ın fayasız olduğundan bahsetmek : Eğer toplantıları aptalca bulan ekip üyesi varsa daiyler bundan şikayet etmek için uygun yerler değil. Bu konu ile ilgili ayrıca bu ekip üyesi ile konuşulmalı ve ikna edilmeli. 
• Ekip üyelerinin birbirini dinlememesi : Daily ‘e anlatılanlar sadece ekip liderine proje durumu hakkına bilgi vermek için değildir. Herkes birbirinin dinlemeli. Herhangi bir problemin nasıl çözüldüğü bilgisi bugün olmasa dahi mutlaka bir başka zaman diğer developerın da işine yarayacak. 
• Developerların çok az konuşması : Yaşanan problemler mutlaka detaylıca aktarılmalı ve gerekirse bir beyin fırtınası yapılmalı. 

Sprint çalışma saatlerine değil, sonuca odaklanmak hem ekip üyeleri hem de proje sahipleri için her zaman daha verimlidir. Bu sayede ekipler başarı elde ettikçe bir sonraki sprintte daily ve diğer tü scrum seremonilerini daha güçlü bir inanç ile uyguluyor olacaktır. 

Sprint Review

Her sprintin tamamlanmasının ardından mutlaka yapılması gereken değerlendirme toplantısıdır. Sprint review seremonisinin asıl amacı bir raporlama yapmak değil, ekibin gelişmesini ve birbirine daha bağlı bir takım olmasını sağlamaktır. 

Her sprint, projenin büyük ya da küçük herhangi bir özelliğinin ortaya çıkması için planlanır. Yani her sprint bitiminde ürünün bir özelliği de bitmiş olur. Sprint review toplantılarına bu özelliğin üzerinden konuşulur, minik bir demo yapılır. Demo esnasında bir sonraki sprintte plana alınacak hata ve eksikler ya da yanlış alınan business kararları da netleşmiş olur. 

Önemli not: Demo hiçbir developerın local ortamında yapılmamalıdır. 

Sprint review toplantılarına üst yöneticiler ve müşteriler (projenin tüm paydaşları) katılabilir. Bu toplantılar aynı zamanda geliştirici takımın ortaya çıkardığı işi sergilemesi ve kendisini geliştirecek geri bildirimler alması için de bir fırsattır. Herhangi birinin yönetmesine ihtiyaç duyulmayan bu toplantıda her zaman olduğu gibi scrum masterın sorumluluğu, toplantının akışını kolaylaştırmaktır. Eğer toplantıya müşterinin kendisi katılmadıysa, product ownerın sorumluluğu ise müşteri adına geri bildirim yapmaktır; müşteri demodaki hangi detaylardan hoşlanır, neleri sevmez, hangi kısımlar müşterinin kullanım deneyimini zorlaştırır, müşterinin yapmak isteyeceği ilk değişiklik ne olabilir, müşterinin gelecekte hangi ihtiyaçları doğabilir ya da piyasadaki benzer ürünler için geçerli problemler / avantajlar neler gibi…

Retrospective

Sprint sonlarında sprint review toplantısının ardından gerçekleştirilen bu seremoni, takımın atlamaması gereken en önemli toplantılardan bir diğeridir. Her sprint bitiminde, dönüp nasıl bir sprint geçirildiğine bakmayı amaçlayan bu seremoni sayesinde, süreçlerde sürekli olarak iyileşme hedeflenir. 

Retrospective genelde takımların keyif alarak gerçekleştirdiği scrum seremonilerindendir. Tamamlanmış bir sprintin ardından, birikmiş tüm stresin boşaltıldığı yer olarak da tanımlayabiliriz. Takım, süreç içerisinde fark edemediği hatalı ve eksik durumlarını, hemen yeni bir sprint koşturması başlamadan önce durup düşünme ve fark etme fırsatı yakalamış olur. Bir sonraki sprintte bu hataları yeniden yapmamak için çözümler arar ve uygular. Retro boyunca notlar alınır, 

Retrospective nasıl yapılır? 

Retrospective toplantılarının süresi sprinte göre değişkenlik gösterebilir; sadece 45 dk sürenlerin yanı sıra 3-4 saat süren retrospectiveler de olabilir. Ancak ortalama süreler 2 haftalık bir sprint için genelde en fazla 1 saattir. 

Aşağıda her bir bölümü 10’ar dakikadan toplam 30 dakikalık bir örnek bir retro akışı görebilirsiniz; ancak adımları artırıp azaltabilir ya da uygulama şeklini kendinize göre uyarlayabilirsiniz: 

• Neleri iyi yaptık? 

Sprint boyunca takım ya da bireysel (kendiniz ya da bir takım arkadaşınızdan bahsedebilirsiniz) olarak nelerin yoluna gittiğine, size fayda sağladığına, “bunu iyi ki böyle yaptık” dedirten şeylere dönüp bakılan bölümdür. Bu, diğer sprintlerde de hangi alışkanlıkların devam etmesinin bizim için iyi olabileceğine dair fikir verir. 

• Neleri daha iyi yapabiliriz?

Neleri yapamadık, kötü yaptık ya da nelerde başarısız oluk gibi soruların sorulması ekibi aksine daha çok demoralize edebilir. Ancak kendimize karşı dürüst olmak ve süreçleri iyileştirmek için yolunda gitmeyen durumları da kabul etmek gerekir. Bu nedenle bu bölümde nelerin daha iyi yapılabileceği konuşulur. Üstelik iyi olan şeylerin de nasıl daha iyi yapılabileceği tartışılabilir.

• Alınacak aksiyonlar 

Bir önceki bölümlerde konuşulanların iyileştirilmesi için alınabilecek aksiyonlar öneri olarak toplanır ve bir liste yapılır. Öneri maddeleri son olarak takımca tekrar değerlendirilir. Bir sonraki retrospective’e kadar hayata geçirilmiş olanlara karar verilir ve retrospective tamamlanır. 

Retrospective’lerin sonunda alınan her bölümde konuşulanlar ve alınan kararlar bir rapor halinde tüm ekibe paylaşılır. Bu sayede herkes bir sonraki retrospecitve’e kadar sorumluluklarını daha iyi tanımlayabilir ve bu konuda üstüne düşeni yapmak için daha motive olur. 

Sprint Planlama

Sprintler yukarıda da belirtildiği şekilde bitiminde bir özellik teslim etmeyi hedeflediğinden, çoğu zaman 1, 2 en fazla 3 haftalık sprintler olacak şekilde planlanır. Daha uzun sprintler de elbette spesifiki durumlarda, projenin kendi ihtiyaçlarına göre olabilir. Ancak, Agile uygulamanın amacı her koşulda esnek olmak, gelişmeler neticesinde daha “çevik” hareket edebilmeki, hızlı karar alıp yine hızlı bir şekilde uygulamak olduğundan, sprintlerin süresi uzadıkça bunu yapmak zorlaşacaktır. Yani amacımızdan uzaklaşırız. 

Sprint planlama toplantıları bir sprintin bitiminde, bir sonraki sprintin hazırlanmasına yönelik olarak yapılır. Ortalama 1-2 haftalık bir sprintin planlanması yaklaşık yine 1-2 saat sürebilir. Planlama toplantısının öncesinde, mevcut sprint koşmaya devam edilirken backlog, product owner ve proje yöneticileri tarafından hazırlanmış olmalıdır. Çünkü planlama toplantılarında developer ekip, bir sonraki sprinte gelmesi gerektiği hemen hemen belirlenmiş görevlerin üzerinden teknik ve business ihtiyaçları konuşur ve görevler için ortalama süreler (estimation) belirlenir. 

Planlama toplantısında süreler önceliklendirilmiş görevler için belirlenir. Eğer sprint, belli bir özelliğin eklenmesini kapsamıyorsa, yapılacaklar product owner ve proje yöneticileri tarafından müşteri ve ekiple de iletişimde kalarak önceliklendirilir. Öncelik sırasına göre en üstteki görevden başlanarak süreler belirlenmeye başlanır. Ortalama 2 haftalık (ekip sayısına göre adam saat üzerinden) ya da hedef toplam puana (story pointler üzerinden) sahip göreve ulaşıldığında bir sonraki sprint de genel hatlarıyla belirlenmiş olur.

Backlogta çoğu zaman öncelikli olanlar müşteri talepleridir. Bunlarla beraber müşteri taleplerini gerçekleştirmek için gerekli olan diğer bağlantılı işler gelir. Eğer mevcut bir hata varsa (ve müşterinin süreçlerini tıkıyorsa) öncelik her zaman hata görevlerindedir. Bir önceki sprintten kalan işler varsa; bu durum ekipten ekibe değişkenlik gösterebilir. Kimi ekipler bir sonraki sprinte bu görevleri alır ve hangi developerın sorumluluğundaysa onun planında öncelikli olacak şekilde çalışılmaya devam edilmesini terchi eder. Bu sayede bu developer ekibin geri kalanına yeni plana yetişebilmek için extra efor sarf etmek durumunda kalır. Bir diğer senaryoda da bu görevler (planlama sırasında konuşulandan farklı bir durum ortaya çıkmadıysa) tamamlanana kadar yeni sprinte geçilmez. Çünkü sprint tamamlanmadan yeni bir sprint planlamak çok gerçekçi olmayacaktır. Bazı senaryolarda ise yeni sprint bu görevler olmadan başlar, ancak eski sprint e kapatılmaz ve ekip kendi arasında bir planlama yaparak her iki sprinti kapatmak için mevcut plan haricinde efor sarf eder. Bu yöntemler, ekipler ve proje ihtiyaçlarına göre çoğaltılabilir. Ancak önemli olan, sprint gecikmelerinin kronikleşmesinin önüne geçecek bir öül & ceza sisteminin olmasıdır. 

Backlog İyileştirme

Sprint boyunca hem sprint hem de ürün backlogu kapsamında değişiklikler meydana gelebilir. Sprintteki görevler, başka görevlerin backloga açılmasına sebep olabilir ya da öngörülen sürelerin tahmin edilemeyen sebeplerden dolayı uzaması sonucunda backloga birkaç görev geri gönderilebilir. Bu nedenlde backlog iyileştirme toplantıları sprint boyunca birkaç sefer kısa kısa olacak şekilde yapılabilir. 

Product owner / proje yöneticisi ve geliştirici ekipten ilgili görevlerin oluşmasına sebep olan durumla karşılaşan kişi(ler), bu kısa toplantılarda bir araya gelerek ortaya çıkan değişiklikler üzerinden konuşur ve backlogu günceller. Yeni açılan görevler için efor ve süre detayları belirlenir. Elbette toplantıya diğer ekip üyeleri de eğer isterse katılabilir. Örneğin scrum master, toplantı süresini dengede tutmak amacıyla bu toplantıda yer alabilir; konuşulacak görevlerin her biri için 10 dakikadan fazla süre ayırmamak üzere toplantı gidişatını kontrol altında tutabilir. Eğer 10 dk sonunda hala netleştirilememiş olan bir görev varsa, onun için farklı bir zamanda (üstüne ayrıca düşündükten sonra) yeniden bir araya gelinebilir. 

Sonuç olarak, tüm bu scrum seremonileri hem geliştirici takımın projeler üstünde daha akıcı ilerlemesini sağlamak hem de süreçleri hem zaman hem de maliyetler açısından sürekli olarak iyileştirmeyi amaçlar. Tüm takım bu amacı benimsediğinde ortaya daha verimli sonuçlar çıkar. Bu nedenle scrum uygularken aldığınız kararları, öncesinde bunu neden yaptığınızı ve ne için buna vakit ayırmaya değeceğini takımınıza anlatın.