Scrum'ın Evrimi: 1986 HBR Makalesinden Scrum Guide 2020'ye ve 2025 Expansion Pack'e
Scrum'ın resmi tanımı Kasım 2026 itibarıyla hâlâ Scrum Guide 2020; 2025'te Sutherland, Jocham ve Coleman'ın yayımladığı Expansion Pack (son sürüm v2026.1) Schwaber'ın imzasını taşımayan, resmi Guide'ın yerine geçmeyen bir ek. Yazı 1986 HBR makalesindeki rugby yaklaşımından 1995 OOPSLA sunumuna, 2010–2017 revizyonlarına ve 2020'nin Product Goal, commitment ve self-managing değişikliklerine uzanan yolu anlatıyor.
Sürüm notu: Bu yazı Scrum Guide 2020'yi (Kasım 2020, Ken Schwaber ve Jeff Sutherland) esas alır. 8 Kasım 2026'da scrumguides.org ve revizyon geçmişi sayfası yeniden kontrol edildi: güncel resmi sürüm hâlâ 2020; Scrum Guide Expansion Pack'in son sürümü v2026.1 (18 Ocak 2026) ve resmi Guide'ın yerine geçmiyor.
Önce Tahmin Et
Bookstore'a yeni katılan bir Developer, Kerem'e üç soru soruyor. Birincisi: "Scrum kelimesi nereden geliyor, yazılımla mı doğdu?" İkincisi: "Scrum Guide 2010'dan beri kaç kez değişti ve en büyük değişiklik hangisiydi?" Üçüncüsü: "2025'te yeni bir Scrum Guide çıktı diye duydum, artık onu mu kullanacağız?"
Her birine cevabını yaz. Üçüncü sorunun cevabı özellikle önemli; sahada bu konuda ciddi bir kafa karışıklığı var ve yazının sonunda netleşecek.
1986: Rugby ve Bayrak Yarışı
Scrum kelimesi yazılım dünyasına bir işletme makalesiyle girdi. Hirotaka Takeuchi ve Ikujiro Nonaka, Harvard Business Review'ün (HBR) Ocak 1986 sayısında "The New New Product Development Game" başlıklı makalelerinde Japon ve Amerikan şirketlerinin yeni ürün geliştirme biçimlerini incelediler. Fuji-Xerox, Canon, Honda ve NEC (Nippon Electric Company) gibi şirketlerin örneklerinden yola çıkarak iki yaklaşımı karşılaştırdılar. Birincisi bayrak yarışı: her uzman grup kendi fazını bitirip işi bir sonrakine devrediyor. İkincisi rugby: ekip, sahada topu birbirine paslayarak birlikte ilerliyor.
Makale rugby yaklaşımının altı özelliğini sıralıyor: ekibe bilinçli olarak belirsiz ve iddialı bir hedef verilmesi (built-in instability), kendi kendini organize eden proje ekipleri, birbirinin üzerine binen geliştirme fazları, çok yönlü öğrenme (multilearning), ekibe hissettirmeden yapılan yönlendirme (subtle control) ve öğrenilenin kuruma aktarılması. Bugünkü Scrum'ın neredeyse her fikri bu listede bir tohum olarak var: cross-functional ve self-managing ekip, fazların Sprint içinde iç içe geçmesi, Retrospective'in öğrenme döngüsü.
Makale bir yazılım süreci önermiyordu; üretim ve donanım ürünleri üzerine bir gözlemdi. Ama "scrum" kelimesini bir ekip çalışma biçimi için ilk kullanan metin bu.
1993–2001: Easel, OOPSLA ve Manifesto
Jeff Sutherland, makaledeki fikirleri 1993'te Easel Corporation'da bir yazılım ekibinde uyguladı. Ken Schwaber ise kendi şirketinde benzer bir yaklaşım üzerinde çalışıyordu. İkili Scrum'ı ilk kez 1995'teki OOPSLA (Object-Oriented Programming, Systems, Languages and Applications) konferansında birlikte sundu. Guide'ın kendi tarih notu bu sunumu, önceki birkaç yılda öğrendiklerini belgeleyen ve Scrum'ın ilk resmi tanımını kamuya açan an olarak anıyor ve Scrum'ın ilk denendiği yerler olarak Individual Inc., Newspage, Fidelity Investments ve IDX'i (bugün General Electric bünyesinde) sayıyor.
2001'de Schwaber ve Sutherland, Snowbird'de Agile Manifesto'yu imzalayan 17 kişi arasındaydı. Manifesto'nun hikâyesi ve dört değeri Agile Mindset serisinin "Agile Manifesto: 2001'de Snowbird'de Ne Oldu, 4 Değer Gerçekte Ne Diyor?" yazısında. Scrum o tarihten sonra Agile'ın en yaygın framework'ü oldu; ama on yıl boyunca tek bir resmi tanımı yoktu. Kitaplar, eğitimler ve kurumlar Scrum'ı kendilerine göre tarif ediyordu.
2010–2017: Scrum Guide'ın Revizyonları
Schwaber ve Sutherland ilk Scrum Guide'ı 2010'da yayımladı. O günden beri Guide, scrumguides.org'daki revizyon geçmişine göre küçük ve işlevsel güncellemelerle değişti. 2020'ye kadarki revizyonların en çok konuşulan değişiklikleri:
| Sürüm | Öne çıkan değişiklikler |
|---|---|
| 2011 | "Commit" yerine forecast; burndown zorunluluğu kalktı; Product Backlog "prioritized" değil "ordered"; Sprint Backlog seçilen item'lar artı bir plan; chickens and pigs metaforu ve undone work referansı çıkarıldı |
| 2013 | Artifact transparency bölümü; Sprint Planning tek event, Sprint Goal resmen eklendi; grooming yerine refinement ve "Ready" kavramı; bütün event'ler timebox'lı; Daily Scrum'ın planlama event'i olduğu vurgulandı |
| 2016 | Beş Scrum değeri: commitment, courage, focus, openness, respect |
| 2017 | Scrum'ın kullanım alanları bölümü; Scrum Master için servant-leader ifadesi netleşti; Daily Scrum'ın yapısı ekibe bırakıldı, üç soru yalnız örnek; timebox'ların üst sınır olduğu; Sprint Backlog'da Retrospective'ten en az bir iyileştirme |
Bu tablo serinin önceki yazılarındaki birçok "neden"in cevabı. Product Backlog'un neden sıralı olduğu (03), commit'in neden forecast'e döndüğü (04), Daily Scrum'daki üç sorunun nereden gelip nereye gittiği (05) ve undone work'ün neden ortadan kalktığı (06), hep bu revizyonların izi.
2020: Daha Az Kural, Daha Geniş Kitle
Kasım 2020 sürümü, revizyonların en kapsamlısı. Revizyon notlarına göre ana yönü, yıllar içinde fazla kuralcı hâle gelen Guide'ı yeniden "minimum yeterli" bir framework'e döndürmek. 2017 ile karşılaştırınca:
| Konu | 2017 | 2020 |
|---|---|---|
| Ekip yapısı | Scrum Team içinde ayrı bir Development Team | Tek Scrum Team; Product Owner, Scrum Master ve Developers accountability'leri |
| Hedef | Sprint Goal ve Definition of Done artifact'lara gevşekçe bağlı | Her artifact'ın bir commitment'ı: Product Goal, Sprint Goal, Definition of Done |
| Yeni kavram | Yok | Product Goal: ekibin uzun vadeli hedefi |
| Özerklik | Self-organizing: kim ve nasıl | Self-managing: kim, nasıl ve ne üzerinde |
| Sprint Planning | What ve how | Why, what ve how |
| Daily Scrum | Üç soru örnek olarak var | Sorular yok; yalnız amaç ve 15 dakika |
| Dil | Test, sistem, tasarım, requirement gibi IT (Information Technology) terimleri | IT'ye özgü terimler çıkarıldı; 13 sayfanın altında |
Son satır en az fark edilen ama en stratejik değişiklik. 2017 sürümü Scrum'ın yazılım dışındaki kullanımlarını anlatan bir bölüm eklemişti; 2020 sürümü bir adım ileri gidip metinden IT çağrışımlarını temizledi. Guide'ın girişinde "developers" kelimesini dışlamak için değil sadeleştirmek için kullandıklarını söylemeleri de bunun parçası. Scrum artık pazarlama ekibinin, araştırma grubunun ya da bir okulun da okuyabileceği bir metin.
2025: Scrum Guide Expansion Pack
Haziran 2025'te Jeff Sutherland, Ralph Jocham ve John Coleman, scrumexpansion.org'da Scrum Guide Expansion Pack'i yayımladı. Sitede listelenen sürümler v2025.6 ve Kasım 2026 itibarıyla en son sürüm olan 18 Ocak 2026 tarihli v2026.1. Metin Creative Commons BY-SA 4.0 lisanslı ve kendini 2020 Scrum Guide'ının bir eki (companion) olarak tanımlıyor. Ken Schwaber yazarlar arasında değil.
Expansion Pack'in içeriği 2020 Guide'ının bilerek dışarıda bıraktığı alanlara uzanıyor. Öne çıkanlar:
- Karmaşıklık teorisi, emergence, OODA (Observe, Orient, Decide, Act) döngüsü, product thinking, systems thinking ve leadership gibi destekleyici teori bölümleri.
- Dört "Scrum role": Product Owner, Product Developer, Scrum Master ve Stakeholder; ayrıca Supporter adlı bir stakeholder türü. 2020 Guide'ının "role" yerine "accountability" demesinden bilinçli bir sapma.
- Yapay zekâ (AI, Artificial Intelligence) bölümü: AI'ın refinement'tan karar desteğine kadar ekibe katkısı, ama her sonuç için insan accountability'sinin korunması (human in the loop).
- Product'ın bir artifact olarak tanımlanması ve iki yeni commitment: değerin gerçekleştiğini kanıtlayan Definition of Outcome Done ve Increment'in kalite standardı olan Definition of Output Done.
Metin 2020 Guide'ından ayrıldığı yerleri kendisi işaretliyor ve bunu açıkça bir "departure" olarak adlandırıyor. Scrum.org tarafında da Expansion Pack, Ağustos 2025'teki bir forum cevabında, Nexus gibi Scrum'ın üzerine kurulan ve Scrum'ı değiştirmeyen opsiyonel bir ek olarak değerlendirildi; aynı başlıkta Outcome ve Output Done ayrımını ve AI bölümünü eleştiren uygulayıcılar da var.
Neden "Yeni Scrum Guide" Değil?
Baştaki üçüncü sorunun cevabı: hayır, Bookstore Scrum Guide 2020'yi kullanmaya devam ediyor. Sebepler somut. Scrum'ın resmi tanımı scrumguides.org'da ve Guide'ın kendisinin söylediği gibi Schwaber ve Sutherland'ün birlikte arkasında durduğu metin; 8 Kasım 2026'da revizyon geçmişi sayfasındaki en son sürüm hâlâ 2020. Expansion Pack ise iki kurucudan yalnızca birinin imzasını taşıyor, kendini bir ek olarak tanımlıyor ve 2020 Guide'ından bilerek ayrıldığı yerleri işaretliyor.
Bu, Expansion Pack'in değersiz olduğu anlamına gelmiyor. Product Goal'ü outcome'la ilişkilendirmesi, stakeholder'ları ayrıntılı tarif etmesi ve AI'ın ekip içindeki yerine dair soruları, Bookstore'un da konuştuğu konular. Ama onu okurken iki şey akılda tutulmalı: içeriğinin büyük kısmı serinin önceki yazılarında "Guide'ın söylemedikleri" olarak gördüğümüz alanlara giriyor ve oradaki önerileri seçmek ekibin kararı; Scrum'ın tanımı değişmiş değil.
Ölçeklendirme Üzerine Tek Paragraf: Nexus
Guide ekibi "genellikle 10 veya daha az kişi" diye tarif ediyor ve büyüyen ekiplere aynı ürün için aynı Product Goal'ü, Product Backlog'u ve Product Owner'ı paylaşan birden çok Scrum Team önermekle yetiniyor. Bunun nasıl yapılacağını Ken Schwaber ve Scrum.org'un Nexus Guide'ı (son sürüm Ocak 2021) tanımlıyor: yaklaşık üç ila dokuz Scrum Team'den oluşan bir Nexus, her Sprint entegre bir Increment üretmekten accountable bir Nexus Integration Team ve Nexus Sprint Planning, Nexus Daily Scrum gibi ek event'ler. Nexus da Expansion Pack gibi Scrum'ın üzerine kurulan bir ek; Agile Mindset serisinin "Agile'ın Evrimi: Manifesto'dan Modern Agile'a ve Ölçeklendirme Tartışmasına" yazısı ölçeklendirme framework'lerini daha geniş bir çerçevede tartışıyor.
Üretimde Dikkat
Bir ekibin hangi Scrum'ı uyguladığı, eğitim materyallerinden ve şirket içi dokümanlardan anlaşılıyor. Bookstore'da bir iç wiki sayfası hâlâ 2017'nin "Development Team" ifadesini ve Daily Scrum'ın üç sorusunu "Scrum kuralları" olarak listeliyordu; yeni katılanlar Scrum'ı oradan öğreniyordu. Kerem sayfayı Guide 2020'ye göre güncelledi ve en üste kaynağı ve tarihi yazdı. Basit bir kural: şirket içi her Scrum dokümanı hangi Guide sürümüne dayandığını söylesin.
Guide'ın değişme sıklığı da bir veri: 2010'dan 2020'ye altı sürüm, 2020'den Kasım 2026'ya hiç. Bir sonraki resmi revizyon geldiğinde Bookstore'un yapacağı şey belli: revizyon notlarını okumak, kendi Definition of Done'ı, çalışma anlaşmaları ve iç dokümanlarıyla karşılaştırmak ve farkları bir Retrospective'te konuşmak.
Sık Düşülen Tuzaklar
Expansion Pack'i yeni Scrum Guide sanmak. Sertifika sınavına, ekip içi tartışmaya ya da bir kurumsal standarda "2025 Scrum Guide" diye girdiğinde, Scrum'ın tanımı yerine bir ekin önerileri esas alınmış olur.
Eski Guide sürümlerinin kurallarını taşımak. "Development Team", "üç soru", "commit" ve "Sprint Backlog'da en az bir Retrospective aksiyonu" zorunluluğu hâlâ birçok eğitim materyalinde 2020'nin kuralı gibi anlatılıyor.
Tarihi bir gerekçe yerine bir otorite olarak kullanmak. "1986 makalesinde böyle yazıyor" bir pratiği haklı çıkarmaz; makale bugünkü Scrum'ın kaynağı ama tanımı değil.
Küçük Bir Deneme
★☆☆ Ekibinin Scrum eğitim materyallerini ya da iç wiki sayfasını aç ve 2020'de değişen üç şeyi ara: "Development Team", Daily Scrum'daki üç soru ve Product Goal. Hangisi eski, hangisi güncel?
★★☆ scrumguides.org'daki revizyon geçmişi sayfasını oku ve ekibinin bugünkü pratiklerinden birinin hangi revizyonla Guide'a girdiğini ya da Guide'dan çıktığını bul. Örneğin velocity takibiniz, Guide'ın 2011'de burndown zorunluluğunu kaldırmasıyla nasıl ilişkili?
★★★ Expansion Pack'in Definition of Outcome Done bölümünü oku ve kendi Product Goal'ünüz için bir outcome ölçüsü yaz. Sonra bunun 2020 Guide'ında nereye oturduğunu düşün: Product Goal'ün parçası mı, Sprint Review'da konuşulan bir veri mi, yoksa Guide'ın dışında bir pratik mi?
Seri burada bitiyor. Scrum Guide 2020'nin bütün parçalarını, sahadaki uygulamasını, metriklerini, mühendislik pratiklerini ve anti-pattern'lerini gördük. Sıradaki adım ekibinin kendi Scrum'ına bu gözle bakmak: hangi parça amacına hizmet ediyor, hangisi yalnız biçim olarak duruyor? Flow tarafını derinleştirmek istersen Kanban serisinin "Scrumban ve Kanban Guide for Scrum Teams: Scrum'a Flow Eklemek" yazısı bu serinin doğal devamı.