Agile Startup Ortamında: Scrum mu, Kanban mı?

Scrum vs Kanban vs Shape Up

Scrum, 5 ila 9 kişilik ekipler için optimize edilmiş, iki haftalık sprint döngüleriyle çalışan bir çerçevedir. Her sprint içinde daily standup, sprint review ve retrospective seremonleri yer alır; bu yapı taahhüdü ve şeffaflığı zorunlu kılar. Scrum'ın güçlü yönü ritmin ekibe öngörü sağlamasıdır; ne zaman ne teslim edileceği belli olduğunda paydaş yönetimi kolaylaşır.

Kanban ise sprint taahhüdü yerine akışı optimize eder. WIP (Work in Progress) limiti belirleyerek her anda kaç işin aktif olduğunu kısıtlar; bu sınır darboğazları görünür hale getirir ve ekibi yeni işe başlamak yerine mevcut işi bitirmeye yönlendirir. 1 ila 3 kişilik küçük ekiplerde Scrum'ın seremoni yükü Kanban'dan çok daha yüksektir ve bu oran somut olarak hesaplanabilir. Shape Up ise Basecamp'ın geliştirdiği bir metodolojidir: 6 haftalık cycle'lar, "betting table" ile neyin yapılacağına karar verme ve cycle aralarında "cooldown" haftası içerir; uzun vadeli ürün yatırımlarını kısa sprint reaktifliğinden koruyan bir yapıdır.

Erken Stage İçin Sprint Uzunluğu

İki kişilik bir kurucu ekipte iki haftalık Scrum sprintleri, seremonlerin anlamlı toplantıya dönüşmek için yeterli içerik üretmediği bir ritim yaratır. Bu ölçekte Kanban, başlangıç noktası olarak çok daha az overhead ile aynı disiplini sağlar; bir Trello veya Linear board, WIP limiti ve haftalık bir gözden geçirme toplantısı yeterlidir. Ekip 4 veya daha fazla kişiye ulaştığında sprint yapısına geçmek, iş bölümünü ve önceliklendirmeyi netleştirir.

Eğer Scrum kullanmak istiyorsanız erken stage için iki hafta yerine bir haftalık sprint önerilir. İki haftalık döngü, gerçekte ne kadar hızlı değiştiğinizi gizler; bir haftada bir review yapmak planlama hatalarını çok daha erken görmenizi sağlar. Startup'ın erken aşamasında öğrenme döngüsünü sıklaştırmak, taahhüt döngüsünü uzatmaktan çok daha değerlidir. İlk altı ayın sonunda hızlanıp hızlanmadığınızı ölçmek için her sprint'te tamamlanan story point ortalamasını kayıt altına tutun.

Retrospektif Pratiği

Retrospektif, ekibin çalışma biçimini sürekli iyileştirmesini sağlayan en değerli Agile seremonisinin başında gelir; ancak sıkıcı bir rutin haline geldiğinde etkinliğini yitirir. En yaygın ve sade format "Start / Stop / Continue" üçlüsüdür: hangi davranışa başlamak istiyoruz, hangisini durdurmak istiyoruz ve hangi pratik işe yaradığı için devam etmeliyiz? Her döngünün sonunda bu üç başlık altında en az birer madde belirleyin.

Retrospektifin değer üretmesi için belirlenen her aksiyon maddesinin sahibi ve tamamlanma tarihi net olmalıdır. "İletişimi iyileştireceğiz" gibi belirsiz kararlar değil, "her sabah 09:15'te 10 dakika async check-in mesajı atacağız" gibi operasyonel adımlar kayıt altına alınır. Bir önceki retrospektifin aksiyon maddelerini bir sonrakinin başında gözden geçirmek, ekibin kararlarına olan bağlılığını pekiştirir ve retrospektifin ritüel değil araç olarak kalmasını sağlar.

Agile Seremonilerin Maliyeti

Agile seremonleri üretkenliği artırmak için tasarlanmıştır; ancak koordinasyon maliyetinin hesaplanmaması toplantı yükünün fark edilmeden büyümesine yol açar. Onlarca kişilik bir ekipte günde 15 dakika standup, yıllık 37,5 mühendis-günlük çalışma zamanına eşdeğerdir. Bu rakam sadece standup içindir; sprint planlama, review, grooming ve retrospektif eklendiğinde toplam koordinasyon maliyeti sprint kapasitesinin %15 ila %20'sine ulaşabilir.

Bu maliyet gereksiz değildir; düzgün yürütülen Agile, koordinasyon maliyetini iletişim hataları, yanlış geliştirmeler ve yeniden yazım maliyetlerinden çok daha düşük tutar. Sorun, seremonlerin zamanla şekil alıp formalite haline gelmesidir. Günde 15 dakikalık standupun 40 dakikaya sürünmesi veya sprint review'in sorunları gizleyen bir ilerleme gösterisine dönüşmesi, maliyet/fayda dengesini ters çevirir. Her seremoni dönemsel olarak "bu toplantıdan gerçekten değer alıyor muyuz?" sorusuyla değerlendirilmelidir.

Sık Sorulan Sorular

Kanban'da sprint olmadan nasıl ilerleme ölçülür? Cycle time (bir işin başlangıçtan tamamlanmaya kadar geçen süre) ve throughput (belirli bir haftada tamamlanan iş sayısı) Kanban'ın iki temel metriğidir; sprint velocity'nin yerini bu iki ölçüm alır.

Shape Up'ı küçük ekipte uygulamak mümkün mü? Mümkün ama "betting table" ve "appetite" kavramları için en az iki karar alıcıya ihtiyaç vardır; tek kişilik ekipte bu yapı anlamsız kısıtlar ekler.

Retrospektif kaç kişiyle yapılmalı? Tüm sprint ekibiyle yapılır; 8 kişiyi geçen ekiplerde alt gruplar halinde yapmak daha derin tartışmaya imkân tanır.

Daily standup'ı kaldırmak sorun yaratır mı? Async güncellemeler (Slack mesajı veya Linear yorum) standup'ı ikame edebilir; asıl soru senkron koordinasyona gerçekten ihtiyaç olup olmadığıdır. Uzak çalışan ekiplerde async standup'ın daha verimli olduğunu gösteren örnekler yaygınlaşıyor.

Scrum'dan Kanban'a geçiş nasıl yapılır? Sprint sınırlarını kaldırın ve bir WIP limiti belirleyin (başlangıç için her aşamada maksimum 3 iş); sprint review yerine haftalık akış gözden geçirmesi yapın. Geçiş bir hafta içinde tamamlanabilir.