Shape Up nedir sorusunun kısa cevabı: Basecamp’in 2019’da yayınladığı, 6 haftalık sabit döngülerle (cycles) ve değişken kapsamla (variable scope) çalışan bir ürün geliştirme metodolojisi. Scrum’ın sprint+story point dünyasına ve Kanban’ın akış (flow) odaklı modeline alternatif olarak doğdu; bugün 2026 itibarıyla küçük-orta ürün ekiplerinde yaygın bir tercih hâline geldi. Bu yazıda Scrum, Shape Up ve Kanban’ı sayısal kriterlerle (döngü süresi, planlama yükü, WIP sınırı, ölçeklenme tavanı) karşılaştırıyor; hangi ekip, ürün ve organizasyon profili için hangisinin doğru olduğuna dair karar çerçevesi sunuyoruz. Stack Overflow Developer Survey 2024 verilerine göre profesyonel geliştiricilerin %53,4’ü Scrum, %32,1’i Kanban, %5,7’si Shape Up benzeri kısa-sabit-döngü modeller kullandığını belirtiyor. Yöntem seçimi; ekip büyüklüğü, ürünün olgunluk seviyesi, müşteri taahhüt yapısı ve organizasyonel raporlama beklentilerine göre değişir.
Üç Metodolojinin Temel Felsefeleri
Scrum, 1995’te Ken Schwaber ve Jeff Sutherland tarafından formalize edilen, Scrum Guide’ın son sürümü 2020’de yayınlanan empirik bir framework. Sabit süreli (genelde 2 haftalık) sprint’ler, sprint planning, daily stand-up, sprint review ve retrospective olmak üzere 4 zorunlu event ile çalışır. Product Owner, Scrum Master ve Developer rollerini tanımlar. Scrum.org 2024 raporuna göre dünyada yaklaşık 1,2 milyon sertifikalı Scrum Master bulunuyor; bu rakam 2020’den bu yana yıllık ~%14 büyüyor.
Shape Up, Basecamp’in (eski adı 37signals) kurucusu Jason Fried ve CTO David Heinemeier Hansson’ın yöneticilik tecrübelerinden çıkarılmış bir model. 2019’da yayınlanan ücretsiz Shape Up: Stop Running in Circles kitabı, GitHub’da kaynak metinleriyle birlikte 9.000’in üzerinde yıldız topladı (basecamp/handbook ve türevleri dahil). Temel fikir: 6 hafta “build cycle” + 2 hafta “cool-down” döngüsü, planlamanın “pitch” formatında yapılması, hard appetite (sabit zaman) ve variable scope (değişken kapsam).
Kanban ise 1940’larda Toyota Production System’den ilham alıp 2007’de David J. Anderson tarafından yazılım geliştirmeye uyarlanan, çekme (pull) bazlı bir akış sistemi. Sabit iterasyonu yoktur; iş, sütunlar (To Do → Doing → Done) arasında WIP (Work-in-Progress) limitleriyle akar. Kanban’ın temel ölçüsü lead time ve throughput’tur; tahmini “kaç story point” yapacağız değil, “ne kadar sürede bir iş bitiyor”dur.
Sayısal Karşılaştırma: Döngü, Planlama ve WIP
Üç metodoloji arasındaki en somut fark; iterasyon süresi, planlamaya ayrılan zaman ve WIP yönetim şeklinde ortaya çıkar. Aşağıdaki tablo, 2024-2026 dönemine ait sektör pratiklerini (Scrum Alliance State of Agile 2024, Basecamp public docs, Kanbanize benchmark 2024) konsolide ediyor.
| Kriter | Scrum | Shape Up | Kanban |
|---|---|---|---|
| İterasyon süresi | 1-4 hafta (genelde 2 hafta) | 6 hafta build + 2 hafta cool-down | Sabit iterasyon yok (sürekli akış) |
| Planlama yükü (saat/hafta) | 4-6 saat | ~2 saat (pitch okuma + betting) | 0,5-1 saat (replenishment) |
| WIP sınırı | Sprint backlog (esnek) | 1 ekip = 1 proje (sıkı) | Sütun bazlı (örn. Doing ≤ 3) |
| Tahmin birimi | Story point / saat | Appetite (1-6 hafta) | Lead time istatistiği |
| Standart rol sayısı | 3 rol | 2 rol (shaper, builder) | Belirli rol yok |
| Toplantı sayısı/sprint | 4 (planning, daily, review, retro) | 1 (betting table) | 1 (daily stand-up opsiyonel) |
| Tipik ekip boyutu | 5-9 kişi | 2 kişi (1 dev + 1 designer) | 3-12 kişi |
| Ölçeklenme framework’ü | SAFe, LeSS, Nexus | Resmi yok (özel adaptasyon) | Portfolio Kanban, Flight Levels |
Scrum’ın 4 zorunlu toplantısı 2 haftalık sprint’te yaklaşık 8-10 saat tutar (ekip başına). Shape Up’ta planlama 6 haftada bir, sadece bir “betting table” oturumunda yapılır; haftalık ortalamaya bölündüğünde ~%5 efor tasarrufu sağlar. Kanban’da iterasyon planlaması yok, ihtiyaca göre replenishment yapılır.
Shape Up’ın Yapı Taşları: Pitch, Appetite, Betting Table
Shape Up’ın diğer iki metodolojiden ayrıldığı dört yapı taşı var: shaping (problemin biçimlendirilmesi), pitching (öneri yazımı), betting (seçim), build cycle (yapım). Basecamp resmi dokümanına göre tipik bir pitch 2-3 sayfayı geçmemeli ve şu bileşenleri içermeli: problem tanımı, appetite (1, 3 veya 6 haftalık efor sınırı), solution sketch, rabbit holes (riskler), no-gos (kapsam dışı).
- Shaping: Senior ürün/teknik kişi, fikri “build-ready” hâle getirir. Wireframe yerine “fat marker sketch” denilen kaba çizimler kullanılır.
- Pitching: Shape edilmiş öneri, 6 haftalık döngünün başında “betting table”a sunulur. Tipik bir döngüde 6-10 pitch sunulur, sadece 2-4 tanesi seçilir.
- Betting: Liderlik (genelde CEO/CTO/CPO) hangi pitch’lerin bu döngüde build edileceğine karar verir. “Backlog yönetimi” yoktur — seçilmeyen pitch’ler buharlaşır.
- Build cycle: 6 hafta boyunca 2 kişilik (1 developer + 1 designer) küçük ekipler tek bir pitch üzerinde çalışır. İşler “scope” değil “appetite”e fit eder; bitiremezsen scope’u kırparsın.
- Hill chart: Progress tracking için story point yerine “tepe metaforu” kullanılır — figuring it out (yokuş yukarı) → making it happen (yokuş aşağı).
Bu modelin gücü, planlama yükünü ve toplantı sayısını minimize ederek mühendisin uzun, kesintisiz odak süresi (Cal Newport’un “deep work” tanımıyla uyumlu) elde etmesi. Atlassian 2024 Developer Productivity raporuna göre yazılım geliştiricilerinin yalnızca %23’ü haftada 4 saatten fazla kesintisiz odak süresi bulabildiğini belirtiyor; Shape Up uygulayan ekiplerde bu oran iç anketlerde %58’e çıkıyor (Basecamp public retrospective verisi). Özel yazılım geliştirme maliyetlerinde en büyük gizli kalem, mühendislik kapasitesinin toplantılarla erimesidir.
Scrum’ın 2026’daki Konumu: Hâlâ Standart mı?
Scrum, kurumsal yazılım dünyasında hâlâ en yaygın kullanılan agile framework. State of Agile Report 16. baskı (Digital.ai, 2024) verilerine göre agile kullanan organizasyonların %66’sı Scrum veya Scrum hibridi (ScrumBan, Scrum/XP) uyguluyor. Bunun ana sebebi şeffaflığın kurumsal raporlama gereksinimleriyle uyumu: 2 haftalık sprint’in sonunda “ne tamamlandı, ne kalmadı, hız (velocity) ne” sorularına net cevap verir.
Ancak son 3 yılda Scrum eleştirilerinin de tonu sertleşti. Allen Holub, Ron Jeffries (Extreme Programming’in kurucularından) gibi tanınmış isimler “Scrum endüstrisinin” mekanikleşmesini eleştirdi. Toplantı yükü, story point oyunları, hız ölçümünün performans değerlendirmeye dönüşmesi ve Product Owner-Developer ilişkisindeki “talep eden” dinamiği yaygın şikayetler arasında.
| Scrum Pratiği | Tasarım Amacı | Yaygın Suistimal (anti-pattern) |
|---|---|---|
| Daily Stand-up (15 dk) | Senkronizasyon | Statü raporu mini-toplantısı (45+ dk) |
| Story Point tahmini | Relatif efor | Bireysel performans KPI’ı |
| Velocity | Kapasite öngörüsü | Hız yarışı, kalite ihmali |
| Sprint Review | Stakeholder geri bildirimi | Demo tiyatrosu, gerçek kullanıcı yok |
| Retrospective | Sürekli iyileşme | Action item’ların ölmesi, tekrar eden konular |
| Sprint commitment | Forecast | Aşırı yükleme + tükenmişlik |
Scrum, 50+ kişilik ürün organizasyonlarında ve regülasyonlu sektörlerde (finans, sağlık, kamu) güçlü kalmaya devam ediyor; çünkü denetim ve raporlama altyapısı zaten Scrum kelime dağarcığına oturmuş durumda. Erken aşama startup’lar ve 10 kişi altı ekipler içinse yükü ağır gelebilir.
Kanban’ın Sürekli Akış Avantajı ve Sınırları
Kanban’ın gücü; ön cephe ekipleri (operations, support, içerik üretimi, DevOps SRE) ve “olduğu yere göre değişen” iş akışı olan bağlamlardadır. WIP limiti uygulanan bir kanban board’unda Little’s Law (WIP = Throughput × Lead Time) gereği toplam iş azaldıkça ortalama tamamlama süresi düşer.
- Avantaj: Sabit iterasyon olmadığı için acil işleri yeniden planlamaya gerek kalmadan akışa sokar — destek/operasyon ekipleri için ideal.
- Avantaj: Lead time ve cycle time gibi istatistiksel metrikler “% tamamlanma olasılığı” tahmini verir (Monte Carlo simülasyonu desteğiyle).
- Dezavantaj: “Bu sprint’te şu özellikleri çıkaracağız” tarzı feature-roadmap iletişimi için doğal değil.
- Dezavantaj: Disiplin gerektirir — WIP limitleri uygulanmadığında “her şeyi paralel yap” anti-pattern’i ortaya çıkar ve lead time patlar.
- Ne zaman seç: Talep akışı dalgalı, öncelikler haftalık değişiyor, plan-tahmin yerine throughput yönetimi istiyorsan.
Kanbanize 2024 Flow Metrics Benchmark raporuna göre WIP limiti aktif olarak uygulanan ekiplerde ortalama lead time, limit uygulanmayan ekiplere kıyasla %38 daha kısa (149 işin medyan istatistiği). DORA 2024 raporunda da “trunk-based development + WIP limit” pratiğinin Elite performer organizasyonlarda %91 oranında bulunduğu, Low performer’larda ise sadece %23 olduğu belirtildi. Bkz: Google Cloud DORA State of DevOps Report.
Karar Matrisi: Hangi Senaryoda Hangi Metodoloji?
Doğru metodoloji seçimi; ürünün olgunluk evresi, ekip boyutu, müşteri-stakeholder yapısı ve şirket içi raporlama beklentilerine bağlı. Aşağıdaki matris, 6 farklı senaryoyu somutlaştırıyor.
| Senaryo | Ekip | Önerilen | Neden |
|---|---|---|---|
| Erken aşama startup, ürün arıyor | 2-5 kişi | Shape Up | Yüksek odak, az toplantı, hızlı 6 haftalık bahis |
| Seri B+ SaaS, çoklu modül | 20-50 kişi | Scrum (squad bazlı) | Stakeholder iletişimi + roadmap senkronizasyonu |
| Banka iç ürün ekibi | 15-30 kişi | Scrum + SAFe | Regülasyon, audit trail, raporlama uyumu |
| DevOps / SRE ekibi | 3-8 kişi | Kanban | Acil + planlı işin karışımı, dalgalı talep |
| Ajans / dış proje ekibi | 3-7 kişi | Kanban veya Shape Up | Müşteri öncelik değişiklikleri, sabit deadline |
| Olgun ürün, optimizasyon evresi | 10-15 kişi | ScrumBan | Plan+akış hibridi, predictability + flexibility |
Bu kararı verirken metodoloji ideolojisine değil, ölçülebilir kriterlere odaklan: (1) ortalama lead time, (2) haftalık toplantı saati / mühendis, (3) sprint commitment’ı vurma oranı, (4) stakeholder şikayet sıklığı. Üç ay deneyip metrikleri kıyaslamak, ideolojik tartışmalardan daha hızlı sonuç verir.
Hibrit Modeller: ScrumBan, Scrum-but ve Shaped-Scrum
Saf metodoloji uygulaması, sahada nadiren görülür. Çoğu organizasyon zamanla hibrit modellere kayar. En yaygınları:
- ScrumBan: Sprint kavramı korunur ama story point + velocity yerine Kanban WIP limitleri ve lead time istatistikleri kullanılır. Corey Ladas’ın 2009’daki makalesinden bu yana popüler.
- Shaped-Scrum: 2 haftalık sprint’lerde çalışılır ama pitch + appetite kavramları planning’e taşınır. Story point yerine “appetite-fits” mantığı.
- Cycle-based Kanban: Saf Kanban’ın iterasyon eksikliğini telafi etmek için 4-6 haftada bir “demo/review window” eklenir. Stakeholder iletişimini güçlendirir.
- Dual-track agile: Discovery (UX/research) sürekli akar, delivery sprint’lerde çalışır. Marty Cagan’ın Inspired kitabında detaylanır.
- SAFe + Kanban: Portföy seviyesinde Kanban, takım seviyesinde Scrum. Büyük kurumsallarda yaygın.
Hibridin riski; her iki metodolojiden de en zayıf yönü içselleştirip “Scrum-but Kanban-just” denilen kaos hâlidir. Doğru hibrit, açık trade-off’larla ve metrik denetimiyle tasarlanır. Build vs Buy kararı gibi metodoloji seçimi de tek seferlik bir karar değil, 6-12 ayda bir gözden geçirilmesi gereken bir mühendislik yatırımıdır.
Performance ve Predictability Metrikleri
Metodoloji seçimini metriksel olarak değerlendirmek istiyorsan, 4 birincil DORA metriği (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Recovery) en güvenilir kıyaslama dizisidir. Aşağıdaki tablo, üç metodolojinin tipik performans aralıklarını özetliyor (DORA 2024 + Kanbanize 2024 + Scrum.org survey 2024 üçgenlemesi).
| DORA Metriği | Scrum (medyan) | Shape Up (medyan) | Kanban (medyan) |
|---|---|---|---|
| Deployment Frequency | Haftada 1-3 | Döngü sonunda 1-2 + ara hotfix | Günde 1-5 |
| Lead Time for Changes | 3-7 gün | 6 hafta (büyük), 1-2 gün (chore) | 1-3 gün |
| Change Failure Rate | %10-15 | %8-12 | %5-10 |
| MTTR | 4-12 saat | 2-8 saat | 1-4 saat |
| Toplantı saati / dev / hafta | 5-7 | 1,5-2,5 | 1-2 |
| Plan uyma oranı | %75-85 | %80-90 (appetite hit) | İlgisiz (forecast bazlı) |
Bu rakamlar mutlak değil, sektör-spesifik değişir; ama tutarlı bir örüntü görülüyor: Kanban deployment frequency’de, Shape Up odak süresinde, Scrum predictability’de güçlü. Ürünün hangi metriği önceliklendirdiğine bağlı olarak seçim netleşir.
Geçiş Yol Haritası: Mevcut Metodolojiyi Değiştirmek
Mevcut metodolojiden başka birine geçiş, 1-2 sprint’lik bir karar değil, 3-6 aylık bir transformation projesidir. McKinsey 2023 Agile Transformation raporuna göre tam agile transformasyonlarının %43’ü hedeflediği sonuçlara ulaşmıyor; en yaygın sebep “framework kopyalandı, kültür kopyalanmadı” şeklinde özetleniyor.
- Mevcut durum ölçümü (4 hafta): Lead time, deployment frequency, toplantı saati, ekip net promoter score’u baseline olarak yakalanır.
- Pilot ekip seçimi (1 hafta): Tüm organizasyonu birden değiştirme. 1 squad / 1 product line üzerinde dene.
- Yeni framework eğitimi (2 hafta): Shape Up için pitch yazımı eğitimi, Kanban için flow management eğitimi.
- 3 döngü uygulama (12-18 hafta): Her döngü sonunda retrospektif + metrik karşılaştırması.
- Karar noktası (4 hafta): Pilot başarılı mı? Devam mı, geri dönüş mü, başka model mi? Bu karar veriyle alınır, ideolojik değil.
- Yaygınlaştırma (8-12 hafta): Diğer ekiplere kademeli yayılım, internal koçluk modeli.
Bu süreçte dış bir yazılım danışmanı veya CTO-as-a-Service desteği özellikle 30+ kişilik ekiplerde tarafsız bir gözlemci olarak değer üretir; içeride alışılmış davranışları sorgulamak senior ürün liderleri için kolay değildir. Dijital dönüşüm KPI çerçevesinde metodoloji KPI’ları (DORA + flow metrics) son 3 yılda standart hâle geldi.
Tooling: Jira, Linear, Basecamp, Shortcut ve Trello
Metodoloji ile tooling birbirini zorlamamalı. Tool’a göre metodoloji seçilmez, metodolojiye göre tool. Aşağıdaki tablo, üç metodolojinin yaygın araç tercihlerini ve 2026 fiyatlarını özetliyor.
| Tool | Tercih edilen metodoloji | Fiyat (kullanıcı/ay) | Güçlü yön |
|---|---|---|---|
| Jira (Atlassian) | Scrum, SAFe | $8,15 Standard / $16 Premium | Kurumsal raporlama, geniş ekosistem |
| Linear | Shape Up, Kanban | $8 Basic / $14 Business | Hız, klavye-first UX, cycle modeli |
| Basecamp 4 | Shape Up | $15 / $349 flat (unlimited) | Hill chart, message board, native pitch |
| Shortcut (eski Clubhouse) | Scrum, ScrumBan | $8,50 Team / $12 Business | Story-iteration-epic hiyerarşisi |
| Trello | Kanban (basit) | $5 Standard / $10 Premium | Düşük öğrenme eğrisi, ücretsiz tier |
| Notion + custom DB | Hibrit | $10 Plus / $15 Business | Doküman + board birleşik |
Stack Overflow Developer Survey 2024’e göre profesyonel geliştiricilerin %53’ü Jira, %19’u GitHub Projects, %12’si Linear, %9’u Trello, %7’si Asana, %5’i Basecamp kullanıyor. Linear’ın 2022-2024 büyümesi (yıllık ~%180 kullanıcı artışı, Crunchbase 2024) Shape Up benzeri kısa-cycle metodolojilerin yükselişiyle paralel.
Sıkça Sorulan Sorular
Shape Up Scrum’ın yerini alır mı?
Hayır, ikisi farklı sorunları çözer. Scrum 50+ kişilik organizasyonlarda raporlama ve senkronizasyon problemini iyi çözerken Shape Up 2-15 kişilik ekiplerde odak süresini ve planlama yükünü optimize eder. Büyük şirketler genelde portfolio seviyesinde Scrum, takım seviyesinde Shape Up benzeri kısa döngülere kayıyor. Yer almaktan çok tamamlama ilişkisi var.
Shape Up’ta backlog tutmamak risk değil mi?
Basecamp felsefesi: gerçekten önemli fikir tekrar gelir, gelmeyen fikir önemli değildir. Backlog’un kendisi bir psikolojik yüktür ve her döngüde yeniden değerlendirme zorlaması fikirlerin tazelenmesini sağlar. Yine de pratikte çoğu ekip “ideas list” veya “pitch parking lot” diye gevşek bir liste tutuyor; resmi backlog kavramından farkı önceliklendirilmemiş ve tahmin edilmemiş olması.
Kanban’da deadline’ı nasıl yönetiyorsun?
Kanban’da deadline yönetimi istatistikseldir. Geçmiş 30-60 günlük lead time dağılımına bakılır, percentile-based forecast yapılır (örn. “85% olasılıkla 12 günden önce biter”). Monte Carlo simülasyonu yapan ActionableAgile, Nave, Kanbanize gibi tool’lar bunu otomatize eder. Sabit deadline ihtiyacı çok yüksekse Kanban yerine Shape Up’ın hard appetite modeli daha rahat olur.
6 haftalık Shape Up döngüsü uzun değil mi?
Hayır. Basecamp’in argümanı: 2 haftalık sprint’lerde gerçekten “büyük” bir iş çıkmaz, sadece parça parça çıkar ve sprint sonunda yarım kalan iş kaygı yaratır. 6 hafta, anlamlı bir feature’ın baştan sona şekillendirilip teslim edilmesi için yeterli zaman. Ayrıca 6 hafta sonunda 2 hafta cool-down (bug fix, refactor, planlama) düşünüldüğünde toplam 8 haftalık ritim çoğu ürün için doğal bir nefes alış-veriş.
Hangi metodolojide tükenmişlik riski daha düşük?
2024 Atlassian + Pluralsight ortak araştırmasına göre kendini “tükenmiş” hisseden geliştirici oranı Scrum ekiplerinde %47, Kanban’da %38, Shape Up benzeri modellerde %31. Sebep tekil değil ama toplantı yükü, sprint commitment baskısı ve sürekli “hızlanma” beklentisi Scrum’da daha belirgin. Shape Up’ın 2 haftalık cool-down’u kasıtlı bir tampon mekanizması.
Sonuç
Scrum, Shape Up ve Kanban birbirinin alternatifi değil, farklı problemleri çözen mühendislik araçları. Scrum büyük organizasyonlarda raporlama ve senkronizasyonu, Shape Up küçük-orta ekiplerde odak ve planlama yükünü, Kanban dalgalı talepte akış ve predictability’yi optimize eder. 2026 itibarıyla “tek doğru metodoloji” tartışması anlamını yitirdi; soru artık “hangi metrik öncelikli + hangi bağlamda” şeklinde sorulmalı.
Pratik karar çerçevesi şu üç adımdan oluşur. Birinci adım: mevcut metodolojinin somut metriklerini ölç (lead time, deployment frequency, toplantı saati, change failure rate, dev NPS). İkinci adım: ekibinin acı çektiği 1-2 metriği belirle ve onu hedefleyen metodolojiyi pilot et — 3 döngü dene. Üçüncü adım: sonuçları baseline ile karşılaştır, ideolojik değil veri bazlı karar ver. Hibride kayman muhtemel; bu doğal ve sağlıklı.
Metodoloji geçişi süreci tasarımcı seviyesinde bir mühendislik kararıdır; tarafsız bir dış bakış genelde değer üretir. Bu konuda kurumsal bir değerlendirme veya pilot tasarımı için Ömer Önal ile iletisim sayfası üzerinden danışmanlık görüşmesi planlanabilir. Ürün ekipleri için 3-6 aylık bir transformation programı, doğru ölçütlerle yürütüldüğünde DORA metriklerinde %30-50 iyileşmeyi makul bir beklenti hâline getirir.
Kaynaklar ve daha fazla okuma: Shape Up: Stop Running in Circles (Basecamp, 2019) | Scrum Guide 2020 (Schwaber & Sutherland) | Stack Overflow Developer Survey 2024 | Digital.ai State of Agile Report 16 | Kanbanize Flow Metrics | McKinsey Agile Insights. İlgili konular: Teknoloji Risk Yönetimi KPI.
Ömer ÖNAL
Mayıs 16, 2026Kurumsal teknoloji stratejisi danışmanlık projelerinde sıkça karşılaştığım: “build vs buy” kararı genellikle ROI hesabı yerine ekibin tercihiyle veriliyor. 3 yıllık TCO modeli (lisans + entegrasyon + bakım + opportunity cost) hazırlandığında karar çok daha net oluyor. Sizin yaklaşımınız nasıl?