Daily Scrum: 15 Dakikalık Plan Toplantısı, Status Raporu Değil
Daily Scrum, Developers'ın Sprint Goal'e ilerlemeyi inspect edip Sprint Backlog'u adapt ettiği 15 dakikalık bir planlama event'idir; çıktısı rapor değil, ertesi gün için uygulanabilir bir plandır. Yazı 2020'de üç sorunun neden kalktığını, board'u sağdan sola yürüyen ve item yaşına bakan formatı, remote ve hibrit ekip pratiklerini ve yöneticiye rapor, problem çözme ve süre aşımı tuzaklarını Bookstore ekibiyle anlatıyor.
Sürüm notu: Bu yazı Scrum Guide 2020'yi (Kasım 2020, Ken Schwaber ve Jeff Sutherland) esas alır; Kasım 2026 itibarıyla scrumguides.org'daki güncel resmi sürüm hâlâ budur. Kanban tarafındaki atıflar Scrum.org'un Kanban Guide for Scrum Teams belgesine dayanır.
Önce Tahmin Et
Bookstore'un Daily Scrum'ı sabah 09.30'da. Kerem toplantıyı açıyor ve sırayla söz veriyor; herkes dün ne yaptığını, bugün ne yapacağını ve bir engeli olup olmadığını anlatıyor. Selin her konuşmadan sonra "bu ne zaman biter?" diye soruyor ve notlarını haftalık rapora aktarıyor. Ayşe kargo firmasının API'sindeki (Application Programming Interface) bir hatayı anlatmaya başlayınca Emre ve Can da katılıyor ve konu on dakika sürüyor. Toplantı ortalama 28 dakika.
Bu tabloda Guide 2020'ye göre kaç sorun var? Ve en kritik olanı hangisi: sürenin 15 dakikayı aşması mı, üç soru mu, yoksa başka bir şey mi? Tahminini yaz; cevap ilk iki bölümde.
Daily Scrum'ın Asıl Amacı
Guide Daily Scrum'ın amacını tek cümleyle koyuyor: Sprint Goal'e doğru ilerlemeyi inspect etmek ve Sprint Backlog'u gerektiği kadar adapt ederek önümüzdeki planlı işi ayarlamak. Yani Daily Scrum bir planlama event'i. Çıktısı bir rapor değil, ertesi gün için uygulanabilir bir plan.
Gerisi bu amaçtan türüyor. Daily Scrum Developers için 15 dakikalık bir event. Karmaşıklığı azaltmak için Sprint'in her iş günü aynı saatte ve aynı yerde yapılıyor. Product Owner ya da Scrum Master Sprint Backlog'daki item'lar üzerinde aktif çalışıyorsa Developer olarak katılıyor. Developers istedikleri yapıyı ve tekniği seçebiliyor; tek şart, Daily Scrum'ın Sprint Goal'e ilerlemeye odaklanması ve ertesi iş günü için uygulanabilir bir plan üretmesi. Guide'a göre bu odak self-management'ı da güçlendiriyor.
Bookstore tablosundaki en kritik sorun bu yüzden süre değil, kime konuşulduğu. Herkes Selin'e ve Kerem'e anlatıyor; Developers birbirine değil. Toplantının sonunda kimsenin planı değişmiyor, sadece Selin'in raporu güncelleniyor. Bu, inspection'ın adaptation'a dönüşmediği, Guide'ın deyişiyle anlamsız bir inspection.
Üç Sorunun Kısa Tarihi
"Dün ne yaptım, bugün ne yapacağım, engelim var mı" soruları Scrum'la o kadar özdeşleşti ki çoğu ekip bunları Daily Scrum'ın tanımı sanıyor. Guide'ın revizyon geçmişi farklı bir hikâye anlatıyor. 2013 sürümü soruları bireyden ekibe çevirdi: "Development Team'in Sprint Goal'e ulaşmasına dün ne katkım oldu?" gibi. Aynı revizyon Daily Scrum'ın bir planlama event'i olduğunu, sık sık status event'i gibi görüldüğünü açıkça not etti. 2017 sürümü toplantının yapısını Development Team'e bıraktı ve soruları yalnızca "kullanılabilecek bir örnek" olarak verdi. 2020 sürümü ise soruları tamamen çıkardı.
Soruların kalkmasının sebebi, revizyon notlarındaki ifadeyle, Guide'ı yeniden "minimum yeterli" bir framework'e döndürmek ve kuralcı dili azaltmaktı. Üç soru yasak değil; ama sorular kişi kişi tur atmaya zorladığında Daily Scrum kolayca herkesin sırayla rapor verdiği bir ritüele dönüşüyor. Bookstore'da Ayşe'nin "dün kargo API'siyle uğraştım, bugün de uğraşacağım" cümlesi her sabah tekrarlanıyordu ve kimse item'ın beş gündür aynı kolonda beklediğini fark etmiyordu.
Board'u Sağdan Sola Yürümek
Bookstore ekibi formatı değiştirdi. Artık kişilerin üzerinden değil, board'daki item'ların üzerinden geçiyorlar ve Done'a en yakın kolondan başlıyorlar. Mantık basit: en değerli iş, bitmek üzere olan iştir; yeni bir işe başlamadan önce yarımdaki işi bitirmek, Sprint sonunda yarım kalmış beş item yerine bitmiş üç item'la çıkmayı sağlar. Bu fikir Kanban'dan geliyor; Scrum.org'un Kanban Guide for Scrum Teams belgesi Daily Scrum'da flow'a, yani işin board üzerinde nasıl aktığına bakmayı öneriyor. Sabah 09.30'daki board:
| Kolon | Item | Yaş (gün) | Not |
|---|---|---|---|
| Test | Teslim tarihi saat dilimi hatası | 2 | Deniz bugün kapatabilir |
| Code Review | İade talebi oluşturma endpoint'i | 3 | İki gündür review bekliyor |
| In Progress | İade talebi Angular formu | 2 | Endpoint'e bağlı |
| In Progress | Kargo iade etiketi entegrasyonu | 5 | Blocked: test hesabı kargo firmasından gelmedi |
| In Progress | Destek paneli liste ekranı | 1 | Emre yeni başladı |
Sağdan sola yürüyünce konuşma kendiliğinden doğru yerlere gidiyor. Saat dilimi hatası için tek soru var: bugün bitiyor mu? Evet. Endpoint iki gündür review bekliyor ve Zeynep'in formu buna bağlı; Emre destek paneline devam etmek yerine önce review'u yapmayı öneriyor. Kargo entegrasyonu beş gündür aynı yerde; Kerem test hesabı için kargo firmasındaki muhatabı bugün arayacak, Ayşe beklerken etiket isteğini taklit eden bir test stub'ı yazacak. On iki dakikada üç plan değişikliği çıktı ve hiçbiri "dün ne yaptım" sorusundan gelmedi.
Item yaşı (work item age) burada en kullanışlı sayı. Bir item'ın board'da ne kadar süredir beklediğini gösteriyor ve Sprint sonunda değil, daha üçüncü günde alarm veriyor. Yaşın, WIP'in (Work in Progress) ve diğer flow metric'lerinin nasıl hesaplandığı ve yorumlandığı Kanban serisinin "Flow Metric'leri: WIP, Throughput, Work Item Age ve Cycle Time" yazısında; aging item'larla aktif ilgilenme pratikleri ise aynı serinin "Kanban'da Aktif Yönetim ve İyileştirme: Blocker, Aging ve Flow Review" yazısında.
15 Dakika ve Sonrası
15 dakika bir hedef değil, bir üst sınır. Guide Daily Scrum'ın iletişimi iyileştirdiğini, engelleri ortaya çıkardığını, hızlı karar almayı teşvik ettiğini ve bu sayede başka toplantılara ihtiyacı ortadan kaldırdığını söylüyor. Kısa olması bu yüzden önemli: problem çözme toplantıya girdiğinde sorunla ilgisi olmayan dört kişi on dakika bekliyor.
Bookstore'un çözümü bir "sonrası" listesi. Daily Scrum'da bir konu iki dakikadan uzun sürecekse adı listeye yazılıyor ve yalnız ilgili kişiler event bittikten sonra kalıyor. Kargo API'si hatası artık Ayşe, Can ve Emre'nin 09.45'teki yirmi dakikalık konuşması. Guide da Daily Scrum'ın Developers'ın planlarını ayarlayabildiği tek an olmadığını, gün içinde Sprint'in geri kalanını yeniden planlamak için sık sık bir araya geldiklerini açıkça yazıyor.
Kimin Toplantısı?
Daily Scrum Developers'ın event'i. Scrum Master'ın accountability'si event'in yapılmasını, olumlu ve verimli geçmesini ve timebox içinde kalmasını sağlamak; onu yönetmek ya da söz dağıtmak değil. Bookstore'da Kerem ilk iki hafta toplantıyı kolaylaştırdı, sonra kolaylaştırıcılık Developers arasında haftalık rotasyona geçti ve Kerem yalnızca gözlemci olarak katılmaya başladı.
Product Owner'ın durumu Guide'da net: Sprint Backlog'daki bir item üzerinde aktif çalışıyorsa Developer olarak katılır. Selin'in "bu ne zaman biter?" sorusu ise toplantının yönünü değiştiriyordu; Developers birbirine değil ona konuşmaya başlıyordu. Selin artık Daily Scrum'a katılmıyor; board'u istediği zaman görebiliyor ve sorusu olduğunda event'ten sonra soruyor. Stakeholder'ların Daily Scrum'daki yeri Guide'da tanımlı değil; katılıyorlarsa toplantının bir rapor toplantısına dönmemesi Developers'ın ve Scrum Master'ın sorumluluğunda.
Remote ve Hibrit Ekipte Daily Scrum
Bookstore'da Can İzmir'den, Deniz haftanın iki günü evden çalışıyor. Remote ve hibrit düzende işe yarayan pratikler:
- Herkes kendi bilgisayarından bağlanır; ofistekiler tek ekranın karşısında toplanırsa uzaktakiler konuşmayı kaçırır.
- Board ekranda paylaşılır ve sağdan sola yürünür; konuşmayı kişiler değil item'lar yönlendirir.
- Saat, en geniş çakışan zaman diliminin içinde sabitlenir; Guide'ın "aynı saat, aynı yer" önerisinin remote karşılığı aynı bağlantı ve aynı saat.
- Yazılı bir ön not kullanılabilir ama yerine geçmez; Slack'e yazılan üç satırlık güncellemeler birbirine cevap vermez, dolayısıyla plan da değişmez.
- "Sonrası" konuları için ayrı bir oda açılır; herkes ilk 15 dakikanın sonunda serbest kalır.
Tamamen asenkron bir Daily Scrum, Guide'ın tarif ettiği event'in amacını, yani birlikte inspect edip planı birlikte adapt etmeyi, zorlaştırır. Farklı saat dilimlerine dağılmış ekiplerde bu bir trade-off: çakışma çok kısaysa ekip birkaç gün senkron, birkaç gün yazılı çalışabilir; ama yazılı güncellemenin "kimse bir şey değiştirmedi" diye bittiği günler artıyorsa bu bir sinyaldir.
Üretimde Dikkat
Daily Scrum'ın işe yarayıp yaramadığını ölçmek için Bookstore üç şeye bakıyor. Birincisi, event'ten sonra Sprint Backlog'da bir şey değişiyor mu? Bir hafta boyunca hiçbir plan değişikliği yoksa ya her şey mükemmel gidiyordur ya da inspection yapılmıyordur; ilki nadirdir. İkincisi, blocked item'ların yaşı: bir item'ın blocked olarak kaç gün kaldığı, engelin Daily Scrum'da ne kadar hızlı ele alındığını gösteriyor. Üçüncüsü, süre: ortalama 15 dakikayı aşıyorsa Daily Scrum'a problem çözme sızıyordur.
Ekip büyüdükçe Daily Scrum da zorlanır. On kişilik bir ekipte board'u yürümek 15 dakikaya sığmayabilir; bu genellikle ekibin bölünmesi gerektiğinin işaretidir. Birden çok ekip aynı ürün üzerinde çalışıyorsa ekipler arası bağımlılıklar için ek bir koordinasyon gerekir; Nexus bunu Nexus Daily Scrum olarak tanımlıyor.
Sık Düşülen Tuzaklar
Yöneticiye rapor. Daily Scrum'ın Developers'ın kendi planı için değil, birinin bilgi toplaması için yapılması Ron Jeffries'in "Dark Scrum" dediği şeyin ilk belirtisi: Scrum'ın event'leri, ekibin işini yönetmek yerine ekibi denetlemek için kullanılıyor. Serinin onuncu yazısı bu anti-pattern'i ayrıntılı ele alıyor.
Problem çözme tartışmasına dönmek. Bir teknik problem toplantının ortasında çözülmeye çalışıldığında hem süre aşılıyor hem de sorunla ilgisi olmayanlar bekliyor. "Sonrası" listesi bunun en ucuz çözümü.
Sprint Goal'den kopuk konuşma. Herkes kendi item'ını anlatıyor ama kimse "bu gidişle Sprint Goal tutar mı?" diye sormuyor. Haftada bir kez bu soruyu açıkça sormak, kapsamın Product Owner'la erken konuşulmasını sağlıyor.
15 dakikayı bir zorunluluk sanıp her gün tam 15 dakika konuşmak. Board'da tek bir değişiklik yoksa altı dakikalık bir Daily Scrum da gayet geçerli.
Küçük Bir Deneme
★☆☆ Bir sonraki Daily Scrum'da süreyi tut ve kaç plan değişikliği çıktığını say. Bir hafta boyunca bu iki sayıyı not et.
★★☆ Bir hafta boyunca Daily Scrum'ı kişi kişi değil, board'u sağdan sola yürüyerek yap. Haftanın sonunda blocked item'ların ortalama yaşını önceki haftayla karşılaştır.
★★★ Ekibin Daily Scrum'ında kimin kime konuştuğunu bir gün boyunca not al: her konuşmanın kime yöneldiğini çizgiyle göster. Çizgilerin çoğu bir kişide toplanıyorsa (Scrum Master, Product Owner, bir yönetici) event'in kime hizmet ettiğini ekiple Retrospective'te konuş.
Daily Scrum her gün planı inspect ediyor; peki Sprint sonunda ortaya çıkan şeyin gerçekten "bitmiş" olduğunu nereden biliyoruz? Bir sonraki yazıda Increment'e ve onun commitment'ı olan Definition of Done'a geçiyoruz ve Bookstore'un .NET ve Angular ekibi için somut bir Definition of Done'ı CI'da (Continuous Integration) nasıl otomatik kontrol ettiğini gösteriyoruz.