Scrum Nedir? Empiricism, Lean Thinking ve Scrum'ın Çözdüğü Problem

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. 2025'te yayımlanan Scrum Guide Expansion Pack resmi Guide'ın yerine geçmez; serinin son yazısında ayrıca ele alınıyor.

Önce Tahmin Et

Bookstore ekibi yeni bir iş için toplandı: müşterilerin iade talebini destek ekibine e-posta atmadan, sitenin kendisinden açabilmesi. Ekipte beş Developer var (backend'de Ayşe ve Emre, Angular tarafında Zeynep, pipeline ve altyapıda Can, test otomasyonunda Deniz), bir Product Owner (Selin) ve bir Scrum Master (Kerem). Şirket "artık Scrum yapıyoruz" dedi ve ilk Sprint pazartesi başlıyor.

Kerem ekibe dört cümle okuyor ve hangilerinin Scrum Guide'da yazdığını soruyor: "Her Sprint'te velocity'mizi ölçeceğiz", "Daily Scrum'da herkes üç soruya cevap verecek", "Product Backlog item'ları user story olarak yazılacak", "Sprint en fazla bir ay sürer". Sence kaç tanesi Guide'da var? Cevabı yazının sonunda değil, birazdan veriyoruz; ama önce tahminini bir kenara yaz.

Scrum Bir Framework, Methodology Değil

Guide Scrum'ı tek cümleyle tanımlıyor: insanların, ekiplerin ve kurumların karmaşık problemlere uyarlanabilir çözümlerle değer üretmesine yardım eden lightweight (hafif) bir framework. Bu tanımdaki iki kelime çok iş görüyor. "Framework" kelimesi Scrum'ın sana adım adım ne yapacağını söyleyen bir methodology olmadığını anlatıyor; Guide kendini bilerek eksik bırakılmış bir yapı olarak tarif ediyor ve yalnızca Scrum teorisini uygulamak için gereken parçaları tanımlıyor. "Lightweight" ise bu parçaların az olduğunu söylüyor: üç accountability, beş event, üç artifact ve her artifact'a bağlı bir commitment. Hepsi bu.

Guide'ın kendi özeti de dört adımlık bir döngü. Scrum Master bir ortam kurar; bu ortamda Product Owner karmaşık bir problemin işini Product Backlog'da sıralar, Scrum Team bu işin bir kısmını bir Sprint boyunca değerli bir Increment'e dönüştürür, Scrum Team ve stakeholder'lar sonucu inspect edip bir sonraki Sprint için ayar yapar. Sonra tekrar.

Framework olmasının pratik sonucu şu: branch stratejisi, test yaklaşımı, estimation tekniği, board'un kolonları, toplantının formatı gibi konularda Guide susuyor. Bunları ekip seçiyor. Guide'ın kendi ifadesiyle Scrum mevcut pratiklerin etrafını sarar ya da onları gereksiz hale getirir; asıl katkısı, mevcut yönetim ve çalışma tekniklerinin ne kadar işe yaradığını görünür kılmasıdır. Yani Scrum sana iyi bir mühendislik süreci vermez; kötü bir sürecin ne kadar kötü olduğunu iki haftada bir yüzüne vurur.

Empiricism: Üç Pillar

Guide Scrum'ı iki temele oturtuyor: empiricism ve lean thinking. Empiricism, bilginin deneyimden geldiğini ve kararların gözlemlenene dayanarak verilmesi gerektiğini söyler. Karmaşık işte, yani ne yapılacağı ve nasıl yapılacağı baştan tam bilinmeyen işte, ayrıntılı bir plan yapıp ona uymak yerine kısa döngülerle ilerleyip her döngüde gerçeğe bakmak daha az risklidir. Bu yaklaşımın üç pillar'ı var:

Üçü birbirine zincirle bağlı. Guide transparency'nin inspection'ı, inspection'ın da adaptation'ı mümkün kıldığını söylüyor; transparency olmadan yapılan inspection yanıltıcıdır, adaptation'a dönüşmeyen inspection ise anlamsızdır. Sahada en sık kırılan halka ilki. Board'da "In Progress" kolonunda üç hafta bekleyen bir item, Daily Scrum'da her gün "bitmek üzere" diye anılıyorsa ekip inspection yaptığını sanıyor ama yanlış veriye bakıyor. Scrum'daki event'lerin hepsi bu üç pillar'ı işletmek için var; Guide her event'i artifact'ları inspect edip adapt etmek için resmi bir fırsat olarak tanımlıyor.

Lean Thinking ve Scrum'ın Çözdüğü Problem

2020 sürümünün Scrum teorisine eklediği ikinci temel lean thinking: israfı azaltmak ve esasa odaklanmak. Yazılım ekibi için israfın en tanıdık hâlleri şunlar: kimsenin kullanmadığı feature, yarım bırakılmış ve haftalarca bekleyen branch'ler, iki ekip arasında el değiştirirken kaybolan bilgi, "sonra test ederiz" denip biriken hatalar. Guide bunları tek tek saymıyor; lean thinking'i ilke olarak koyup Sprint'in kısa ve sabit uzunluğunu, her Sprint'in kullanılabilir bir Increment üretmesini ve Developers'ın kendi işini yönetmesini bu ilkeye bağlıyor.

Peki Scrum hangi problemi çözüyor? Guide'ın cevabı "karmaşık problemler". Bookstore'un iade akışını düşün: müşteriler iadeyi hangi sebeple istiyor, kargo firmasının API'si (Application Programming Interface) iade etiketini nasıl üretiyor, ödeme sağlayıcısında kısmi iade var mı, muhasebe hangi alanı görmek istiyor? Bunların yarısını ilk gün kimse bilmiyor. Altı aylık bir plan yapılabilir ama o plan ilk müşteri geri bildiriminde eskiyecek. Scrum burada iki şey vaat ediyor: her Sprint sonunda gerçek, çalışan bir parça görmek ve en fazla bir ay içinde rotayı değiştirebilmek. Guide bunu "öngörülebilirliği optimize etmek ve riski kontrol etmek için iteratif, incremental bir yaklaşım" diye ifade ediyor.

Basit bir işte ise Scrum gereksiz yük olabilir. Her ay aynı formatta yenilenen bir raporu üreten, sürprizi olmayan bir iş için beş event'lik bir ritim pahalıdır. Hangi iş için hangi yaşam döngüsünün uyduğunu SDLC (Software Development Life Cycle) serisinin "Doğru SDLC Modelini Seçmek: Proje, Ekip ve Risk Profiline Göre Karar" yazısı tartışıyor; sürekli ve tahmin edilemez biçimde gelen destek işi için Kanban serisinin flow yaklaşımı daha uygun olabilir.

Beş Değer: Commitment, Focus, Openness, Respect, Courage

Guide'ın 2016'da eklediği değerler bölümü, Scrum'ın başarısının insanların beş değeri yaşamada ustalaşmasına bağlı olduğunu söylüyor. Değerler soyut durduğu için Bookstore'dan birer sahne:

• Commitment: Ekip Sprint Goal'e bağlı kalır ve birbirini destekler; Emre kendi item'ı bittiğinde yeni bir item'a başlamak yerine Zeynep'in takıldığı ekrana yardım eder.
• Focus: Sprint'in işi önceliklidir; Selin Sprint ortasında gelen "küçük bir rapor" talebini Product Backlog'a yazar, ekibe doğrudan iletmez.
• Openness: Deniz, staging'de iade tutarının kuruş farkıyla hesaplandığını Daily Scrum'da saklamadan söyler, "Review'a kadar düzeltiriz" diye beklemez.
• Respect: Can'ın pipeline önerisi "DevOps'çunun işi" diye geçiştirilmez; ekip herkesi yetkin ve bağımsız profesyonel olarak görür.
• Courage: Ayşe, Sprint Goal'ün bu kapsamla tutmayacağını üçüncü günde Selin'e söyler ve kapsamı birlikte yeniden konuşurlar.

Değerler süs değil; event'lerin işleyip işlemediğini belirleyen şey bunlar. Openness yoksa Daily Scrum'da kimse sorunu söylemez, transparency çöker. Courage yoksa Sprint Planning'de herkes gerçekçi olmayan bir plana sessizce "tamam" der. Guide da değerlerin pillar'ları hayata geçirdiğini ve güven ürettiğini söylüyor.

Guide'ın Söylemedikleri

Şimdi baştaki dört cümleye dönelim. Yalnız sonuncusu Guide'da: Sprint'ler bir ay ya da daha kısa, sabit uzunlukta event'lerdir. Diğer üçü sahada o kadar yaygın ki çoğu ekip onları Scrum'ın kendisi sanıyor:

• Story point ve velocity Guide'da geçmez. Guide yalnızca Developers'ın geçmiş performansını, yaklaşan kapasitesini ve Definition of Done'ı bildikçe forecast'ine daha çok güveneceğini söyler. Estimation tekniği ilerideki Estimation ve Planning serisinin konusu.
• User story bir Product Backlog item yazım biçimidir, Scrum'ın parçası değildir; Guide item'ın açıklama, sıra ve büyüklük gibi özelliklerinin işin alanına göre değiştiğini söylemekle yetinir. Yazım tekniği ilerideki Requirements Analysis serisinde.
• "Dün ne yaptım, bugün ne yapacağım, engelim var mı" soruları 2017 Guide'ında örnek olarak vardı; 2020 sürümü onları tamamen çıkardı.
• Burndown chart 2011'den beri zorunlu değil. 2020 Guide'ı burn-down, burn-up ve cumulative flow gibi pratiklerin faydalı olduğunu ama empiricism'in yerini tutmadığını söylüyor.

Bu ayrım bir sertifika sınavı detayı değil. Ekip "Scrum'da velocity zorunlu" diye düşünürse velocity düşük çıktığında framework'ü suçlar; oysa sorun kendi seçtiği bir pratiktedir ve onu değiştirmekte serbesttir. Guide'ın sonundaki not da bunu iki yönlü söylüyor: Scrum'ın parçalarından yalnız bazılarını uygulamak mümkündür ama sonuç Scrum değildir; Scrum ise başka teknikler için iyi bir kap işlevi görür.

İlk Sprint'e Hazırlık

Bookstore ekibi pazartesiden önce Guide'ın gerçekten istediği şeyleri topluyor. Liste kısa ve bu serinin ilk yedi yazısının haritası gibi:

Listede olmayanlara dikkat: Jira kurulumu, story point eğitimi, "Sprint 0" adı verilen ve hiçbir şey teslim etmeyen bir hazırlık Sprint'i. Bunların hiçbiri Guide'ın şartı değil. Ekip ilk Sprint'ten itibaren küçük de olsa kullanılabilir bir Increment hedefliyor; ilk Sprint Goal'ü de buna göre: "Kayıtlı bir müşteri, teslim edilmiş tek kalemli bir sipariş için iade talebi oluşturabilsin ve talep destek panelinde görünsün."

Üretimde Dikkat

Scrum'ı bir organizasyona sokarken en ölçülebilir sinyal, Increment'in gerçekten kullanılabilir olup olmadığıdır. İlk üç Sprint'in sonunda "staging'de tıklanabilir, Definition of Done'ı karşılayan" bir şey yoksa sorun toplantı formatında değil, iş parçalama ya da mühendislik pratiklerindedir. Bookstore'un Kerem'i bunu basit bir soruyla izliyor: Sprint Review'da stakeholder kendi eliyle neyi denedi?

İkinci sinyal, adaptation'ın gerçekten olup olmadığı. Review'dan sonra Product Backlog'un sırası hiç değişmiyorsa, Retrospective'ten çıkan iyileştirmelerden hiçbiri bir sonraki Sprint'te uygulanmıyorsa, inspection yapılıyor ama sonuç doğmuyor demektir. Guide bunun adını açıkça koyuyor: adaptation'a dönüşmeyen inspection anlamsızdır.

Ölçek konusunda da erken bir uyarı: Guide ekibi "genellikle 10 veya daha az kişi" diye tarif ediyor. Bookstore büyüyüp iki ekibe çıktığında Guide'ın önerisi aynı ürün için tek Product Goal, tek Product Backlog ve tek Product Owner'la birden çok uyumlu Scrum Team kurmak. Bu konuya serinin son yazısında Nexus üzerinden kısaca değineceğiz.

Sık Düşülen Tuzaklar

Scrum'ı event takvimine indirgemek en yaygın tuzak. Takvimde Daily Scrum, Planning ve Review var; ama Sprint sonunda kullanılabilir bir Increment yok, stakeholder Review'a gelmiyor, Retrospective'ten aksiyon çıkmıyor. Bu, Scrum'ın biçimini yapıp teorisini atlamak demek; serinin onuncu yazısındaki Zombie Scrum tam olarak bu.

İkinci tuzak Guide'da olmayan pratikleri kural sanmak. Velocity'ye, user story şablonuna ya da üç soruya bağlılık, ekibi kendi bağlamına uymayan bir pratiğe kilitler. Tersinden de tuzak var: "Guide söylemiyor" diyerek Definition of Done gibi gerçekten zorunlu bir parçayı atlamak.

Üçüncüsü Scrum'ı her işe uygulamak. Büyük kısmı plansız gelen production destek işi, iki haftalık bir Sprint Goal etrafında toplanmaya direnir. Böyle bir ekip ya Sprint Goal'ü sürekli bozar ya da sahte bir hedef yazar. Agile Mindset serisinin "Agile Hakkında Yanlış Bilinenler: Dokümansızlık, Plansızlık ve 'Agile = Scrum'" yazısındaki "Agile = Scrum" yanılgısı da buradan doğuyor.

Küçük Bir Deneme

★☆☆ Ekibinin bugünkü pratiklerinden beşini yaz (örneğin story point, Daily Scrum'da üç soru, Definition of Done, Sprint 0, Retrospective). Her birinin yanına "Guide'da var" ya da "ekibin seçtiği pratik" yaz. Kaç tanesini yanlış sınıflandırdığını Guide'ın web sürümünü açıp kontrol et.

★★☆ Son bitirdiğin bir iş için üç pillar'ı tek tek sorgula: iş ne kadar görünürdü, ne zaman inspect edildi ve inspection sonucu ne değişti? En zayıf halkayı bul ve tek bir somut iyileştirme öner.

★★★ Bookstore'un iade akışı yerine kendi ürününden karmaşık bir problem seç. Bilmediğin üç şeyi yaz ve her biri için "hangi Sprint sonunda, hangi Increment'le öğrenebilirim?" sorusunu cevapla. Cevaplayamıyorsan problem belki karmaşık değil, sadece büyüktür; o zaman farklı bir yaşam döngüsü daha uygun olabilir.

Bir sonraki yazıda Bookstore ekibindeki yedi kişinin Scrum'daki yerine bakıyoruz: 2020'de "role" kelimesinin yerini neden "accountability" aldı, Product Owner neden tek kişidir ve Scrum Master'ın toplantı sekreterinden farkı nedir?