Daily Scrum Nedir?

Scrum Klavuzu’nda dört resmi toplantıdan bahsedilir. Bunlar Daily Scrum, Sprint Planning, Sprint Review ve Sprint Retrospective’dir.

Daily Scrum, Development Team üyelerinin katılımıyla 24 saatte bir aynı yer ve saatte gerçekleştirilir. Development Team üyelerinin katılımının zorunlu olduğu bu toplantıda üyeler aşağıdaki üç soruya yanıt verirler.

1. Dün ne yaptım?
2. Bugün ne yapacağım?
3. Önümde bir engel var mı?

“Dün ne yaptım?” sorusuyla planlamada nerede olduklarını anlatırlar.

“Bugün ne yapacağım?” sorusuyla yeni günün planlamasını yaparlar.

“Önümde engel var mı?” sorusu ise geliştirmeyi geciktirecek herhangi bir engel varsa bunu tespit etmek ve ortadan kaldırmak için cevaplandırılır.

Birçok kişi ve birçok Takım tarafından bu toplantı statu alma ve verme toplantısı olarak değerlendirilse bile gerçekteki amacı yapılan Sprint Planlama’sına adapte olmak ve olabildiğince bu planlamaya sadık kalmak olarak düşünülmelidir.

Bazı koçlar ya da uygulayanlar Product Owner’ın bu toplantıya katılımını faydalı bulsa bile öncelikle zorunlu değildir ve faydalı olacağı kesin değildir. Örneğin; kurumsal bir firmada çalıştığınızı ve eski yöneticinizin de Product Owner olduğunu düşünelim. Evet, Scrum’da roller yataydır, Product Owner, Takım’a ya da kişilere iş atayamaz. Buna rağmen eski yöneticinizin yanında Development Team üyeleri ne kadar rahat olabilirler? Ne kadar rahat konuşabilirler? Birde eski yöneticiniz hala gerekli Product Owner reflekslerini kazanamamışsa ve eski command-control anlayışını devam ettiriyorsa vereceği zararı kısaca düşünürsek şu noktaya ulaşırız. Öncelikle Takım üyeleri rahatsız olması nedeniyle şeffaflık bozulacaktır. Şeffaflık bozulduğunda yapılan gözlemler doğru sonuç vermeyecektir.

Bu şöyle gerçekleşebilir; Product Owner’ın varlığından rahatsız olan Development Team üyesi Product Owner’ın sorularından kaçınmak için bitirmediği bir işi “bitirdim” diyebilir ya da Product Owner’ın toplantılara katılımına alışık bir Development Team üyesi onun gözüne girmek için hızlıca işleri bitirir ve kaliteyi düşürebilir. Bu durumda Takım’ın velocity’si artacaktır fakat ilerleyen Sprint’lerde sürekli bug çözmekle uğraşacakları için toplama bakıldığında velocity’lerini düşürmüş olacaktır. Her iki durumda Product Owner’ın yaptığı release planı bozuluyor olacaktır. Ayrıca Takım kaliteli iş çıkarmadığı için sürekli rework yapıyor olacaktır. Sürekli rework yapma maliyeti arttıracaktır dolayısıyla Product Owner ROI’ı yükseltme sorumluluğuna sahipken Daily Scrum’lara katılarak ROI’yı düşürecek ve bu çalıştığı kuruma para kaybettirecektir.

Product Owner, hem şeffaflığı bozdu, hem kaliteyi düşürdü, hem de maliyeti artırdı ve ROI’ı düşürdü. Bu oldukça kötü bir pratik olabilir.

Scrum Master’ın bu toplantılara katılma gibi bir zorunluluğu ya da sorumluluğu bulunmuyor. Fakat bu toplantının amacına uygun yapıldığından ve 15 dakika zaman limitine uyularak gerçekleştirildiğinden emin olmalıdır.

“Development Team, bu toplantıda 3 soruyu cevaplarken nasıl bir yaklaşım sergilemelidir?”

Sorulara verilecek cevaplar açık ve net olmalıdır. 7 kişiden oluşan bir Development Team’i düşünürsek bir üyenin konuşabileceği 128 saniyesi olacaktır. Her soruya cevap verilecek süre ise 43 saniyedir.

İyi ve kötü pratiklere örnek vermek gerekirse;

Kötü örnek:

• Dün test yaptım.
• Bugün iş birimine kullanıcı kabul testi konusunda destek vereceğim.
• Önümde bir engel yok!

İyi örnek:

• Dün müşteri tanımlama ekranını test ettim, herhangi bir sorunla karşılaşmadım.
• Bugünse müşteri tanımlama ekranının, bireysel kredi planı çıkarma ekranı arkasındaki bağlantıyı test edeceğim eğer vaktim kalırsa da vadeli müşteri hesap ekranındaki ya da doğası gereği riskli ekranını test edeceğim. Sonra da Zeynep ile code review yapmayı planlıyorum.
• Önümde veritabanı bağlantı hatası var. Sürekli aynı hatayı alıyorum. Sizlerden biri karşılaştıysa beraber bakabilir miyiz?

Eğer bu şekilde cevapları sıralama da sıkıntı yaşanıyorsa, konuşma sırası geldiğinde düşünülüyorsa ve Takım üyeleri “eee” diye ses çıkartıyorlarsa bir gün öncesinde not tutmak ve Daily Scrum başlamadan önce bu notlara göz atmak harika bir pratik olabilir.

Daily Scrum’larda sonu olmayan teknik ya da mimari konulara girilmemelidir.

Dün senin çocuk ne yaptı? Hafta sonu nasıl geçti? gibi cümlelerin hiç yeri değildir. Bu tip sosyal konuları ya da derinlemesine konuşulması ve aksiyon çıkarılması gereken teknik ve mimari konular için ilgili kişiler kendi aralarında toplantı ayarlayabilirler. Bu toplantıya Development Team üyelerinin tamamı katılması gerekebilir ve “hazır buradayken hadi konuşalım” diye düşünülebilir. Bu durumda Daily Scrum amacından sapmış olur. Amaçtan uzaklaşmamak için tüm üyelerinin katılım göstereceği başka bir toplantı ayarlanabilir.

Bilmiyorum, akşamları hiç Daily Scrum yapmadım ama sabahları işe başlamadan hemen önce günü planlamak ve o planlamaya sadık kalmak bence çok iyi bir pratik. Tabii akşamları 17:40’ta mesai bitmeden hemen önce gerçekleştirenler de var. Tabii bu da farklı bir deneyimdir.

Bir başka kötü pratik ise birden fazla takımı olan Scrum Master’ların bütün takımlarının Daily Scrum’larına katılmak istemesidir. Öncelikle bütün Daily Scrum’lara katılabilmek için takımlarından Daily Scrum saatlerini kendilerine göre ayarlamalarını isterler. Halbuki takım için ideal saat farklı olabilir. Daha sonra ise tek tek takımların Daily Scrum’larına elinde küçük not defteriyle katılarak her Development Team üyesinin söylediklerini not almak ve zamanı geldiğinde bu notlardan yola çıkarak hesap sormaya çalışmaktır. Bu davranışlar biraz evvel yukarıda bahsettiğim gibi şeffaflığı öldürecek, self-organize ve takım olmanın önündeki en büyük engel olacaktır. Development Team’lere özgürlük vermek yeterli zamanda onları kendiliğinde takım yapacaktır.