Çevik çalışan ekiplerin en vazgeçilmezi, çevik olmayan ekiplerin dahi uyguladığı en yaygın pratik: Daily Scrum. Bu kadar çok yaygın olmasının sebebi kuşkusuz hız ve verimlilik katması. Herkes biliyor, kullanıyor, peki gerçekten verimli mi geçiyor? Etkili Daily Scrum için neler yapılabilir?

Etkili Daily Scrum Önerileri

Malum 3 soruyu yanıtlamaktan vazgeçin!

Geçmiş Scrum Guide’ların bize miras bıraktığı 3 soru kalıbı var.

1. Sprint Hedefine ulaşılması için dün ne yaptım?
2. Sprint Hedefine ulaşılması için bugün ne yapacağım?
3. Sprint Hedefine ulaşmaktan alıkoyacak bir engel var mı?

Scrum Guilde 2020 ile bu sorular kılavuzdan kalktı ama dailylere yerleşti kaldı. Kılavuzdan kalkmasının nedeni daha yalın bir kılavuz oluşturmak ve işin nasıl yapılacağını yönlendirme yapmadan bize bırakmaktı. Kılavuzdan kalkmış olması bu soruların yanlış olduğu anlamına gelmiyor. Fakat daily’i sadece bu soruları cevaplayarak yapmak verimsiz bir daily’e neden oluyor. Maalesef takımlarda bunun bir alışkanlık haline geldiğini görüyorum. Sıkıcı, verimsiz, bitse de gitsek dediğimiz bir daily oluyor.

Scrum Guide 2020

Genellikle daily’ler kişilerin sırayla bu 3 soruyu cevaplaması ile geçip, bitiyor. Adeta bir rapor gibi oluyor. Yapılan iş için ekstra bir iletişim kurulmuyor. İletişim olmayan bir daily’nin verimli geçmesini bekleyemeyiz. Sadece daily’nin verimsizliği değil, yapılan işin verimliliği de riske girer. Bilginin dağılmasına engel olur, cross functional olmayı zorlaştırır, çeviklikten uzaklaştırır. Kelebek etkisini görüyorsunuz değil mi?

Cross functional takımlar sadece “dışa bağımlı olmayan takımlar” anlamında değildir. Eğer takımın içindeki tek bir kişide bilgi birikmişse, bu da bir bağımlılıktır. Bağımlılığın her türlüsüne karşıyız. Bu durum da cross functional olmayı zorlaştırır. Bilginin takım içinde dağılmasını da sağlamak gerekir. Etkili Daily Scrum, bilginin dağılmasına yardımcı olur. Hem de ekstra bir çaba sarfetmeden bunu sağlar.

Bir de demezsem olmaz. Özellikle ilk iki soru çok “ben” içeriyor. 🤣 Daha çok “biz” içeren cümleler kullanmaya özen göstermeliyiz.

Alternatif sorular üretin. Bu soruları kalıp halinde getirmeden, cevaplamak için sıraya girmeden, işi konuşurken ekipçe birbirinize sorun. Peki iletişimi arttıran alternatif sorular neler olabilir?

• Bana bu iş için kim nasıl yardımcı olabilir?
• Biz sana bu iş için nasıl destek verebiliriz?
• İşin bitmesi için ne gerekli?
• Bunun benzerini şurada yapmıştık, birlikte bakalım mı?
• İşi kim review etmek ister?
• PO ve/ya paydaş ile görüşmek gerekir mi?
• …

Scrum Master’dan Kurtulun!

Don’t panic! Scrum Master’lar başımızın tacıdır. Onlara ihtiyacımız tabii ki var. Ama her daily’de ihtiyacımız var mı?

Daily Scrum, geliştiriciler için var olan 15 dakikalık bir etkinliktir. Guide 2020‘ye göre SM ve/ya PO sprintte geliştirici olarak görev almışlarsa, daily’lere katılabilir. Onun dışında PO’nun katılımı sessiz olmalı, SM bir fasilitasyon ihtiyacında katılmalıdır.

Tüm daily’leri Scrum Master fasilite etmemeli. Daily’ler SM’e yapılmamalı. Daily’nin odağı Scrum Master olmamalı, odak geliştiriciler ve hedefe giden plan olmalı.

Takım ilk kurulduğu zamanlarda Scrum Master’ın hem fasilitasyon için hem de bir kültür oluşturmak için Daily’lere katılması çok okeydir. Ama takımın kendi başına ayakları üstünde durabilmesi için SM’in bir süre sonra kendini çekmesi gereklidir. Ancak bu şekilde SM bağımlılığı azalmış, “Ri” seviyesine gelebilmiş olgun çevik bir takım ortaya çıkar. Unutmayın en iyi Scrum Master, “görünmeyen” Scrum Master’dır.

Shu Ha Ri – Bir Çeviklik Benimseme Modeli

Kişi Bazlı & PBI Bazlı denemeleri yapın  

Takımlarda genellikle Daily Scrum kişi bazlı yapılıyor. Takım üyeleri kendi güncelleme ve günlük planlarını sırayla anlatıyor. O malum 3 soruyu yanıtlıyorlar hatta. Fakat bu sıralı işlem yine verimsizliğe neden olabiliyor. Sırası gelene kadar kimseyi dinlememe, iletişim kurmama, hangi iş hakkında konuşulduğunu anlamama (sormama), sırası geçince daily’den çıkma gibi kötü alışkanlıklar bu verimsizliğin sebeplerinden sadece birkaçı.

Kişi bazlı daily’e alternatif olarak PBI (Product Backlog Item) bazlı daily yapılabilir. Sprintte yapılan işleri sırayla ele alıp, o iş için güncelleme ve planları ekipçe konuşarak yapılır. PBI bazlı daily yapmanın yararlarını şöyle sıralayabilriz;

• İletişim kurmaya teşvik ettiği için iyi bir pratiktir. Sadece iş üzerinde çalışan kişilerin değil, tüm geliştiricilerin bu iş hakkındaki güncellemesi, fikir alış verişi, destek ve/ya engelleri konuşulur.
• Hangi iş için konuşulduğu daha anlaşılırdır. Eğer bir kişi birden fazla iş üzerinde çalışıyorsa, kişi bazlı daily’lerde hangisinden bahsettiğini anlamak zorlaşacaktır. PBI bazlı daily’lerde odak yapılan maddede olduğu için hangi işten bahsedildiği çok açıktır.
• Genellikle bitmeye en yakın işten başlamak iyi bir pratiktir. İşi bitirmeye odaklar. Bu da hız kazandırır.
• Bir kişi olmadığında (izinli, eğitimde vb) onun yürüttüğü işler PBI bazlı daily’lerde konuşulur ve maddenin ilerlemesi için plan yapılır. Kişi bazlı daily’lerde o kişi olmadığı için. çalıştığı işler konuşulmayacak ve ilerletilmeyecektir. (Çoğu zaman)

PBI bazlı daily, kişi bazlı daily’den çok daha iyidir demek istemiyorum. Demek istediğim; PBI bazlı daily verimli olmaya yardımcı pratikler içerir. Kişi bazlı daily’lerin etkili olabilmesi için yüksek ve sürekli farkındalık gerektirir. Uzun vadede yorucu olabilir. Uygulayacağınız pratikleri, işinizi kolaylaştıracak şekilde belirleyin.

Biliyoruz ki, Scrum deneysellik üzerine kurulu. O halde neden deney yapmıyoruz? Mesela bir sprint kişi bazlı, bir sprint PBI bazlı daily deneyin. Sonra da retronuzda hangi yöntemin daha verimli olduğunu tartışın. Bundan sonraki daily’lerinizi bu öğrendiklerinizle nasıl iyileştirebileceğinizi düşünün. Etkili Daily Scrum için kaizen kararları alın.

Kaizen vs Kaikaku

Board önünde, board’u görerek yapın

Görselleştirmenin gücünü artık çoğu yerde kullanıyoruz. Board kullanımı da güçlü bir görselleştirme şekli ve kazandırdığı hız aşikar. Peki bu görseli daily’lerde de kullanıyor musunuz?

Etkili Daily Scrum için özellikle Sprint Backlog önünde daily yapmanızı tavsiye ediyorum. Neyi taahhüt ettiğinizi ve bu taahhütün neresinde olduğunuzu size gösterecektir. Fiziki board kullanıyorsanız direk önünde, online’da ise ekran paylaşarak bunu yapabilirsiniz.

Ekranı paylaşan her zaman aynı kişi olmasın. Bu sorumluluğu takımca paylaşın. Bu bir kişinin sorumluluğu ve/ya görevi olamaz.

Bir önceki öneriyi de tekrar hatırlatmak isterim. Daily’lerde Scrum Master’dan kurtulun! Ekranı paylaşan veya boarddaki güncellemeleri yapacak olan Scrum Master değil, takımın kendisidir. 😎

Agile Manifesto bize çalışan ürün/hizmetin daha değerli olduğunu söyler. Board önünde yapılan daily, görsel olarak işin bitmeye yakın mı, uzak mı olduğunu gösterir. İşleri bitirmeye teşvik eder, nasıl biteceğini konuşmaya ortam hazırlar. Kısaca kaliteden ödün vermeden (DOD – Definition of Done) işi bitimeye odaklar.

Agile Manifesto

Daily’ler performans metriklerine, detay progresslere bakmak gereksizdir. Daily’nin amacı işi bitirmek için plan yapmaktır. Ana progress olan işin ilerleyip ilerlemediğini görmek ve ilerlemesini sağlamak için iletişim kurmaktır. Diğer progresslerin yeri daily değildir.

DOD (Definition of Done) gözünüzün önünde olsun

Daily sırasında işi bitirmeye çok odaklanıyoruz. Bazen o kadar odaklanıyoruz ki kalite standartlarımız gözden kaçabiliyor. Gözden uzak olan, gönülden de uzak olur demişler. Bu yüzden kaliteden ödün vermemek için, DOD’nizi gözünüzün önünde tutun.

Madem board önünde yapıyoruz daily’mizi, işi konuşurken kabul kritelerini de görmek, işi bitirmek için neler yapmak gerektiğini gösterecektir.

Kabul Kriteri vs Bitti Tanımı

DOD’yi board kolonlarınıza işlediyseniz, board önünde yaptığınız daily size DOD’nizi zaten hatırlatacaktır. Tabi kolonları atlayarak gitmediğiniz sürece.🤣 Eğer board kolonlarınız DOD’nizi içermiyorsa, daily sırasında mutlaka DOD’inizi de paylaşın.

Kaizen DOD için de geçerlidir. Kaliteniz neden daha iyiye doğru gitmesin ki. Retrolarınızı DOD’nizi geliştirmek için mutlaka kullanın.

“Bu DOD ile iş bitmiyor!” deyip DOD’yi küçültmekten kaçının. Belirlediğiniz standartlar belki mevcut yetkinliklerinize göre ağır gelmiş olabilir. Çok okey bir durum, hatta kaliteli iş çıkarmak istediğinizi gösterir. Buradaki refleksiniz, DOD’yi küçültmek yerine, bu DOD’yi daha hızlı sağlamak için nasıl iyileşebileceğinizi planlamak olsun.

Retrospective Tekniği : Improve Your Definition Of Done (DOD)

Son Söz

Etkili Daily Scrum geçirmek için bir de bu önerileri deneyin. Nelere iyi geldiğini, nasıl iyileştiğinizi mutlaka kendi içinizde değerlendirin. Bunlara ek sizlerin önerileriniz neler olur, deneyimleriniz nelerdir yorumlarda paylaşabilirsiniz.

İlkim Dilara Kadakaloğlu
d.