Scrum vs Kanban

Agile metodolojiler ve framework’ler arasında Scrum ve Kanban konusunda çok fazla kafa karışıklığı mevcut. Agile ne? Scrum ne? Kanban ne? sorularını geçtikten sonra Scrum ile Kanban arasında nasıl farklar var? sorusu geliyor. Scrum vs Kanban dendiği zaman, kendi şirketinde uygulanan metodolojinin en doğrusu olduğunu düşünen ve bunu empoze etmeye çalışan, her iki taraf için de geçerli çok ciddi taraftar kitleleri mevcut. Bu yazıda kısaca her ikisinin de birbirlerine kıyasla farkları, artıları ve eksilerine değiniyor olacağız. O zaman başlayalım.

You can use this link for the English version of Scrum vs Kanban article.

Metodoloji vs Framework

Konuya başlamadan önce metodoloji ve framework arasındaki farktan bahsetmek istiyorum. Birinin scrum veya kanban hakkında konuşurken Scrum Metodolojisi veya Scrum Framework’ü şeklinde bahsettiğine rastlamışsınızdır diye düşünüyorum. Belki çok dikkat etmeden okuyup geçiyoruz ama hangisinin doğru olduğunu bilmek gerekir diye düşünüyorum.

Project Management Body of Knowledge (PMBOK) metodoloji kelimesini şu şekilde açıklıyor: “A system of practices, techniques, procedures, and rules used by those who work in a discipline.”

Framework kelimesinin açıklamasını da whatis.com üzerinden şu şekilde buldum: “In general, a framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.”

Bu açıklamalara bakarak şu şekilde düşünebiliriz, framework’lerde işleyiş değişmediği sürece farklı yöntemler ve araçlar ile desteklenip bir ürün çıkartılabilirken, metodolojilerde işin hangi teknikler, hangi araçlar ve hangi kurallar ile yapılacağı kesin belirtilmiştir. Scrum Guide’20 bize işi nasıl yapmamız gerektiğini anlatırken, hangi araçları kullanacağımızı tamamen bize bırakmıştır. Örneğin Scrum Guide içerisinde “Sprint performansını ölçmek için Burndown chart kullanılması gerekir.” gibi bir ifade yer almamaktadır. Bunu tamamen Development Team‘in tercihi olarak bırakmıştır. Hangi yöntemin ilgili sprintin performansını ölçebildiğini düşünüyorsa ekip onu tercih edecektir. Bu yüzden Scrum’ı framework olarak adlandırıyoruz. Konuya metodoloji tarafından baktığımızda da eXtreme Programming’in metodoloji olarak adlandırılabileceğini düşünüyorum. Her adım için kesin kullanılması gereken araçlar şunlardır demese de sistem dizaynı için CRC Card kullanılması gerektiğini kurallarında belirtmesi bunun için örnek gösterilebilir.

Scrum

Scrum, işleyiş olarak çok iyi tanımlanmış kurallar bütününe sahip bir Agile framework’dür. Öncelikle ekibin öğrenmesi ve uygulaması gereken çeşitli süreçler mevcut. Bu süreçler de daha önce Agile prensipler ile çalışmamış bir ekip için çok hızlı ve kolayca implemente edilebilecek bir süreç değil. Scrum’a geçmek isteyen bir ekibin, Sprint’ler halinde çalışmayı öğrenmesi, self organized ve cross-functional bir geliştirici ekip kurabilmesi, Scrum seremonileri adı verilen çeşitli etkinlikleri organize etmesi ve katılması ilk sayılabilecek örnekler arasındadır. İlk adımların atılmasının ardından da ekibin kendini sürekli geliştirip, kod kalitesini arttırması ve daha çok sorumluluk alması beklenecektir. Son cümleyi aslında hem bir zorunluluk hem de Scrum uygulanmasının ardından gelecek doğal bir sonuç olarak da düşünebiliriz.

Kanban

Kanban, süreç için önceden belirlenmiş kurallara sahip olmadığı için, Scrum kadar yapılandırılmış bir framework değildir. Waterfall dahil tüm yazılım geliştirme metodolojileri ile birlikte kullanılabilir.

Kanban’ın amacı, mevcut süreçlerimizin görselleştirilmesidir. Bu görselleştirme ve sonraki paragrafta anlatacağım Work In Progress (WIP) limitleme kuralı sonucunda süreçlerin normalden daha hızlı akmasını amaçlamaktadır. Kanban’ın mantığı, bir işin, bir board üzerinde, sürecin en başından en sonuna kadar tüm adımlarının görselleştirilmesidir. Board üzerinde, her bir işin anlık olarak alabileceği durumu işaret eden kolonlar yer alır. Bu kolonlar soldan sağa doğru yeni işlerin yer aldığı en soldaki kolondan, tamamlanan işlerin yer aldığı en sağdaki kolona doğru devam eder. Bu kolonlar takım ihtiyacına ve süreçlerine göre değişkenlik gösterecektir. Aşağıda bir takımım için JIRA üzerinde kullandığım board’un kolonlarını görebilirsiniz. Gerisi sizin hayal gücünüze kalmış.

Kanban’ın şart koştuğu tek kuralı WIP limitlemedir. Board’umuzda bulunan kolonlar için bir maksimum iş limiti koymalıyız. Örneğin In Progress kolonunda 5 iş olabilir kuralı konulması halinde, geliştirici ekibin aynı anda 6 ve üstü işle uğraşmaması gerektiği belirlenmiş oluyor. 6. iş In Progress’e giremeyeceği için, koyulan WIP limit, takmın pair programming uygulamasına veya olası gelebilecek acil bir iş için yer ayırmasına olanak sağlıyor.

Scrum vs Kanban

İkisi hakkında da biraz fikir sahibi olduğumuza göre, benim şirketim için hangisi daha uygun?

Oturmuş bir yapımız var ve işler yürüyor, fakat kimseyi ürkütmeden biraz gelişme kaydetmek ve hızlanmak istiyorsak doğru tercih Kanban olacaktır diye düşünüyorum. İşlerin yürümediği ve değişimin kaçınılmaz olduğu bir setup mevcutsa, daha büyük değişimlere açıksak, isterlerin henüz net olmadığı karmaşık bir proje ile uğraşıyorsak, Scrum doğru tercih olacaktır.

Konuyla ilgili sorular beni çok memnun eder. Detayını merak ettiğiniz bir konuyu sormaktan çekinmeyin lütfen.