PSM I Sertifikasını Nasıl Kazandım #1: Scrum Nedir?

Görsel scrum.org tarafından sağlanan logo, font ve rozet ile Canva’da hazırlanmıştır.

Scrum ile ilk kez çalıştığım şirketlerden birinde tanıştım. Bu şirket, o yıllarda (2016-2017) Scrum’ı Türkiye’de en iyi uygulayan şirketlerden biri olmakla övünüyordu. Scrum Poker de dâhil olmak üzere yaptığımız bazı uygulamalar (bunlara ilerleyen yazılarda değineceğim) bana çok havada ve gereksiz geliyordu ama doğru ve yanlış etkinlikleriyle yine de Scrum’ı tam anlamıyla uygulamaya çalışıyorduk.

Scrum ile ilk kez tanıştığımda bu kadar karmaşık görünmesine şaşırmıştım. İlk Sprint Planlama toplantısında herkesin sürekli konuştuğu ama kimsenin bir çözüm bulamadığı hissine kapıldım. O gün anladım ki Scrum’ı anlamak kadar doğru uygulamak da aynı ölçüde önemli. Süreç gittikçe oturdu ve daha isabetli planlamalar yapabildik. Velocity’miz yükseldi. Yıllar içinde başka şirketlerde de Scrum uygulamalarını gördükçe bu çerçeveyi anlamanın ve öğretilerini kullanmanın ne kadar önemli olduğunu fark ettim.

ACM Agile Türkiye’nin düzenlediği ve Mehmet Yitmen’in liderliğinde katıldığım Scrum Master eğitiminin ardından PSM I (Professional Scrum Master) sınavını başarıyla geçtim ve sertifikamı aldım! 💪 Bu süreç benim için yalnızca bir sınavı geçmekten ibaret değildi; teorik bilgilerimi derinleştirirken yıllardır alışkanlık hâline getirdiğimiz bazı uygulamaların Scrum’ın özüne ne kadar ters düştüğünü görmemi de sağladı.

Bu yazı dizisinde Scrum’ın ne olduğunu, aldığım bu eğitimin ve eğitmenimizin kitaplarının bana neler kattığını, sınav sürecimde öğrendiklerimi ve geçmiş iş deneyimlerimde gözlemlediğim yanlış uygulamaları sizlerle paylaşacağım. Eğer Scrum’ı daha etkili uygulamak istiyorsanız bu kapsamlı bir Scrum rehberi niteliğindeki bu yazı dizisi tam size göre. Birbirine bağlı dört farklı yazı yazacağım ve bunların başlıkları şöyle olacak:

1. PSM I Sertifikasını Nasıl Kazandım #1: Scrum Nedir?

2. PSM I Sertifikasını Nasıl Kazandım #2: Aldığımız Eğitim ve Eğitmenimizin Kitapları

3. PSM I Sertifikasını Nasıl Kazandım #3: Sınav Süreci, Yapay Zekâ Kullanımı ve Taktikler

4. PSM I Sertifikasını Nasıl Kazandım #4: Çalıştığım Şirketlerde Scrum

Yayınlandıkça buraya linkleyeceğim tabii ki. Haydi başlayalım!

Görsel scrum.org’dan alınmıştır

Scrum ve Ağaç Dikmek

Bir grup insan düşünün: ellerinde fidanlar ve kürekler, bir orman oluşturmak için çalışıyorlar. Scrum bu süreci nasıl yönetirdi?

Önce “Bitti Tanımı” belirlenirdi: “Her ağacın kökleri tamamen toprağa gömülmüş, üstüne de 5 litre su dökülmüş olmalı.” İlk Sprint’te birkaç fidan dikilir ve bir sonraki Sprint’te bu işin nasıl daha hızlı yapılabileceği üzerine retrospective yapılırdı.

Kanban olsaydı? “Hazır olan fidanlar dikilmeye devam eder.” der ve sürekli bir akış yaratırdı.

Şelale yöntemini kullansaydık? İlk olarak tüm fidanların yerlerini tespit eder, ardından toprağı kazmak için günlerce çalışır ve belki yıllar sonra o fidanları dikerdik. Ne dersiniz, orman o zamana kadar kurur muydu? 🌱🌳

Scrum Nedir?

Scrum, karmaşık projeleri yönetmek için kullanılan bir çerçevedir. Yazılım geliştirme dünyasında sıklıkla tercih edilse de temel prensipleri ve işleyişi sayesinde farklı sektörlerde de uygulanabilir ve bunun birçok örneği vardır. Scrum aslında katı bir yöntem değil, ekiplere yol gösteren bir çerçevedir. Bu çerçeve; adaptasyon (adaptation), deneysellik (inspection) ve şeffaflık (transparency) gibi temel prensipler üzerine kuruludur.

Scrum’ın temel amacı, hızlı değişimlere ayak uydurabilmek ve müşteriye değer sunan ürünleri mümkün olan en kısa sürede teslim etmektir. Çoğu geleneksel yöntemin aksine Scrum, esnekliği ön planda tutar ve ekiplerin sürekli öğrenerek daha verimli olmasını sağlar.

Scrum’ın Kökenleri ve Gelişimi

Scrum, 1990'ların başında Jeff Sutherland ve Ken Schwaber tarafından geliştirildi. İlk kez 1995 yılında bir konferansta tanıtılan bu yaklaşım, Hirotaka Takeuchi ve Ikujiro Nonaka’nın 1986 yılında yayımlanan The New New Product Development Game adlı makalesindeki fikirlerden ilham aldı. Bu makale, ekiplerin nasıl daha esnek, yaratıcı ve uyarlanabilir bir şekilde çalışabileceğini açıklıyordu.

Sutherland ve Schwaber, bu fikirleri yazılım geliştirme süreçlerine uyarlayarak bugün bildiğimiz Scrum çerçevesini oluşturdu. 2010 yılında yayımlanan ilk Scrum Guide ise bu çerçeveyi tanımlayarak tüm dünyaya rehberlik etmeye başladı.

Scrum’ın Üç Ana İlkesi

• Şeffaflık (Transparency): Scrum süreçleri ve ortaya çıkan işler hem işi yapanlara hem de bu işten fayda sağlayanlara açık olmalıdır. Scrum’ın temel eserleri (artifacts) olan Product Backlog, Sprint Backlog ve Increment şeffaflığı destekler. Düşük şeffaflık, yanlış kararlara yol açabilir ve riski artırabilir. Aynı zamanda şeffaflık, sağlıklı gözlemi mümkün kılan bir ön koşuldur.

• Gözlem (Inspection): Scrum eserleri ve hedeflere yönelik ilerleme düzenli olarak gözden geçirilmelidir. Bu gözlemler, istenmeyen sapmaları ve sorunları erken tespit etmeye olanak tanır. Scrum, tanımladığı beş etkinlikle (Sprint Planlama, Günlük Scrum, Sprint Review, Sprint Retrospektif ve Sprint) bu gözlemi bir ritme oturtur. Ancak gözlemin anlamlı olabilmesi için şeffaflık gerekir.

• Adaptasyon (Adaptation): Bir süreç kabul edilebilir sınırların dışına çıkarsa veya ortaya çıkan ürün beklentileri karşılamıyorsa hemen müdahale edilmelidir. Bu adaptasyon, daha fazla sapmaya yol açmadan hızlıca gerçekleştirilmelidir. Scrum ekibi, gözlem yoluyla yeni bir şey öğrendiğinde süreçlerini buna göre güncelleyebilmelidir. Kendini yöneten ekipler, adaptasyonu kolaylaştırır ve süreci verimli kılar.

Scrum’ın Temel Bileşenleri

Scrum takımı, Scrum’ın küçük bir gruptan oluşan en temel birimidir. Scrum takımı; bir Scrum Master, bir Product Owner ve Developers’dan oluşur. Scrum takımında alt takımlar veya hiyerarşiler yoktur.

Scrum Rolleri

Tüm Scrum takımı, her Sprint’te değerli ve faydalı bir Increment (tamamlanmış ürün parçası) oluşturmaktan sorumludur. Scrum, ekip içindeki sorumlulukları net bir şekilde tanımlar:

• Scrum Master: Ekibin Scrum prensiplerine bağlı kalmasını ve Scrum çerçevesi dâhilinde süreçleri iyileştirmesini sağlar; engellerin ortadan kaldırılmasına yardımcı olur.

• Product Owner: Ürünle ilgili kararların sorumluluğunu taşır, müşteri ve kullanıcı ihtiyaçlarını gözetir ve Scrum takımının çalışması sonucu oluşan ürünün değerini en üst seviyeye çıkarmaktan sorumludur.

• Developers: Ürünü geliştiren kişilerdir. Scrum takımında her Sprint’te kullanılabilir Increment’in herhangi bir kısmını oluşturmayı taahhüt etmiş kişilerdir.

Scrum Etkinlikleri

Scrum’daki her etkinlik, Scrum eserleri üzerinde gözlem ve adaptasyon yapmak için bir fırsattır. Bu etkinlikler, gerekli şeffaflığı mümkün kılmak için özel olarak tasarlanmıştır. Bu etkinliklerden herhangi birini bile gerçekleştirmemek, gözlem ve adaptasyon fırsatlarının kaybedilmesine neden olur. İdeal olarak tüm etkinlikler, karmaşıklığı azaltmak için aynı yer ve zamanda düzenlenir. Kısacası Sprint’in kendisi ve Sprint içinde gerçekleştirilen diğer etkinlikler, Scrum’ın düzenli ritmini oluşturur:

• Sprint: Fikirlerin değere dönüştürüldüğü, Scrum’ın kalp atışı olan etkinliktir. Tutarlılık yaratmak üzere Sprintler sabit sürelidir; bu süre bir ay ya da daha az olabilir. Önceki Sprint biter bitmez yeni Sprint başlar.

• Sprint Planlama: Product Owner, ürünün değeri ve kullanılabilirliğinin bu Sprint’te nasıl artırılabileceğine ilişkin önerilerini sunar. Geliştiriciler (Developers), Product Owner ile görüşerek Sprint’e dâhil edebilecekleri maddeleri seçer. Bitti Tanımı’na (Definition of Done) uygun bir tamamlanmış ürün parçası (Increment) yaratabilmek için, seçilen her bir Product Backlog maddesi için yapılması gereken işi planlar. Bunu yaparken Product Backlog maddeleri çoğu zaman bir gün veya daha kısa sürecek parçalara bölünür. Kısaca Sprint’in hedefi belirlenir ve Sprint boyunca yapılacak işler planlanır.

• Günlük Scrum: Günlük Scrum’ın amacı, Sprint hedefine doğru ilerlemeyi gözden geçirmek ve planlanmış işleri gereken şekilde düzenleyerek Sprint Backlog’da adaptasyon yapmaktır.

• Sprint Review: Sprint sonunda tamamlanan işlerin gözden geçirildiği toplantıdır. Bu etkinlik sırasında takım ve paydaşlar bu Sprint’te yapılanları ve ortamlarında nelerin değiştiğini gözden geçirir. Bu bilgiye dayanarak katılımcılar, sonraki adımda ne yapılacağı üzerinde birlikte çalışırlar. Takım, bunu bir sunuma indirgemekten kaçınmalıdır.

• Sprint Retrospektif: Ekibin kendi süreçlerini değerlendirdiği ve geliştirme yolları bulduğu toplantıdır.

Eserler (Artifacts)

Scrum’ın eserleri, yapılan işi ya da üretilen değeri temsil eder. Kilit bilgilerin şeffaflığını en üst seviyeye çıkaracak şekilde tasarlanmıştır. Bu sayede onları gözden geçiren herkes, adaptasyon yapabilmek için aynı temele sahip olur.

• Product Backlog: Ürünü geliştirmek için nelere ihtiyaç duyulduğunun sıralı ve yaşayan bir listesidir. Scrum takımı tarafından üstlenilen işlerin tek kaynağıdır.

• Sprint Backlog: Geliştiriciler tarafından, geliştiriciler için hazırlanan bir plandır. Sprint Hedefi’ne ulaşmak için geliştiricilerin Sprint sırasında başarmayı planladıkları işin son derece görünür, gerçek zamanlı bir resmidir.

• Increment: Product Hedefi’ne doğru atılan somut bir adımdır. Her Increment, önceki Incrementlerin üzerine eklenir ve tüm Incrementlerin birlikte çalışmalarını temin edecek şekilde tamamen doğrulanır. Değer sağlamak için Increment kullanılabilir olmalıdır.

Scrum, yapısı itibarıyla basit görünse de uygulamada disiplin ve özveri gerektirir. Her ekip için özelleştirilebilen bir çerçeve olması, Scrum’ı bu kadar popüler ve etkili kılan unsurlardan biridir. Tabii ki pek çok ekibin ve insanın kullandığı bu çerçeve, bu kadar kısa bir anlatımla bütünüyle açıklanamaz; uygulaması da göründüğü kadar kolay değildir.

Özetle, Scrum rehberindeki on bir temel unsur üç başlık altında toplanabilir:

1. Roller: Scrum Master, Product Owner, Developers (Geliştiriciler)

2. Etkinlikler: Sprint Planlama, Günlük Scrum, Sprint Review, Sprint Retrospektif, Sprint

3. Eserler: Product Backlog, Sprint Backlog, Increment

Kısaca Scrum bu şekilde. Daha ayrıntılı bilgi için Scrum rehberine bakabilirsiniz:

Peki başka proje yönetim teknikleri yok mu? Çevik (Agile) çatısı altında bile birçok proje yönetim yaklaşımı mevcut. Yazımın bu kısmında Kanban ve Extreme Programming gibi birkaç çevik proje yönetimi modelinden, bunların Scrum’dan farklarından ve Scrum’la benzerliklerinden biraz bahsetmek istiyorum. Bir de, âdettendir, en sonda Şelale (Waterfall) yöntemini aşağılayıp hep birlikte nefret edelim. 😠

Scrum vs Extreme Programming

Extreme Programming (XP)

Benzerlikler: Her ikisi de müşteriye hızlı bir şekilde değer sunmayı ve değişen gereksinimlere uyum sağlamayı amaçlar. Kısa döngülerle (XP’de iteration, Scrum’da sprint) çalışmayı teşvik ederler ve sürekli iyileştirmeyi hedeflerler.

Farklar:

• Odak Noktası: Scrum, ekip içindeki süreçlerin yönetimine ve ekip dinamiklerine odaklanırken XP daha çok mühendislik pratiklerine odaklanır. Örneğin XP’de Test-Driven Development (TDD), Pair Programming ve sürekli entegrasyon gibi teknik uygulamalar öne çıkar.

• Değişiklik Yönetimi: Scrum’da Sprint Hedefi sabit kalırken Sprint kapsamı, ihtiyaç hâlinde Product Owner ile yeniden müzakere edilebilir. XP’de ise iteration sırasında değişikliklere daha esnek bir şekilde uyum sağlanabilir.

• Roller: XP’de Scrum’daki gibi belirgin şekilde tanımlanmış roller yoktur. Ekip üyeleri arasında katı bir görev dağılımı yerine rollerin esnekliği benimsenir.

Örnek: XP’nin TDD yaklaşımı tam anlamıyla “Yumurta mı tavuktan, tavuk mu yumurtadan?” sorusunu çözer. Geliştiriciler önce yumurtayı (testi) yazar, sonra da tavuğu (kodu) oluştururlar. Örneğin, bir web uygulaması yapıyorsunuz. Diyelim ki kullanıcı giriş formundaki şifrenin en az 8 karakter olması gerekiyor. Önce testinizi yazıyorsunuz: “8 karakterden kısa bir şifre girilirse hata vermeli.” Daha sonra bu testi geçmek için kod yazıyorsunuz. Bu yöntemle ortaya sadece çalışan değil, aynı zamanda sağlam bir tavuk çıkıyor! 🐓

Scrum vs Kanban

Benzerlikler: Scrum ve Kanban, işlerin ve süreçlerin görünür hâle getirilmesini teşvik eder ve ekiplerin üretkenliğini artırmayı hedefler. Her iki yaklaşım da iş birliğini ve sürekli iyileştirmeyi ön planda tutar.

Farklar:

• Zaman Yönetimi: Scrum, sabit zaman kutuları olan Sprintlere dayanırken Kanban sürekli akışa odaklanır. Kanban’da belirli bir süre içinde yapılacak işlerin planlanması yerine, iş akışı süreç boyunca yönetilir.

• Planlama: Scrum’da her Sprint’in başında Sprint Planlama gerçekleştirilir. Kanban’da ise Scrum’daki gibi zorunlu ve belirli aralıklarla gerçekleştirilen bir planlama etkinliği yoktur; kapasite oluştukça yeni işler akışa alınabilir.

• WIP (Work in Progress) Limitleri: Kanban, belirli bir anda kaç iş üzerinde çalışılabileceğini sınırlayan WIP limitleriyle öne çıkar. Bu limitler, işlerin birikmesini azaltmaya ve darboğazları görünür hâle getirerek akışı iyileştirmeye yardımcı olur. Scrum’da ise WIP limitleri zorunlu değildir. Bir bakıma, aynı anda üzerinde çalışılan iş sayısı sınırlandığı için geliştiricilerin kafası da biraz daha rahat olur.

• Roller ve Kurallar: Kanban, Scrum’daki gibi belirgin roller ve etkinlikler tanımlamaz. Bu durum, Kanban’ı mevcut süreçlerini iyileştirmek isteyen ekipler için daha esnek bir seçenek hâline getirir.

Örnek: Kanban’ın sürekli akış sistemini anlamak için en iyi örneklerden biri bir fast food restoranıdır. Mutfak çalışanları sırayla hamburger hazırlarken kasadaki çalışan sipariş almaya devam eder. Mutfağın üretim hızını dengelemek için aynı anda yalnızca 5 hamburgerin hazırlanmasına izin verildiğini düşünün (WIP limiti). Mutfak bu kapasiteye ulaştığında yeni işler, yer açılana kadar üretim aşamasına alınmaz. İşte Kanban’ın mantığı kabaca budur: Sürekli akış, net limitler ve kontrollü iş akışı. Acıktım… 🍔

Scrum vs Şelale (Waterfall)

Benzerlikler: Scrum ve Şelale o kadar farklıdır ki tek ortak yanları, her ikisinin de birer proje yönetim modeli olmasıdır. Şelale tabii ki Çevik çatısı altında değildir çünkü çevik değildir.

Farklar:

• Yaklaşım: Waterfall, doğrusal ve ardışık bir süreçtir; bir aşama tamamlanmadan diğerine geçilmez. Scrum ise iteratif ve çeviktir; her Sprint’te kullanılabilir bir Increment oluşturulur.

• Değişiklik Yönetimi: Waterfall, gereksinimlerin baştan büyük ölçüde belirlendiği ve değişikliklerin minimum düzeyde tutulduğu bir modeldir. Scrum ise değişikliklere açıktır ve değişiklikleri sürecin bir parçası olarak benimser.

• Müşteri Katılımı: Waterfall’da müşteri genellikle belirli aşamalarda devreye girerken Scrum’da paydaşlardan her Sprint sonunda düzenli olarak geri bildirim alınır ve bu geri bildirimler sürecin bir parçası olur.

• Hız ve Esneklik: Waterfall belirli ve sıralı bir süreç izlerken Scrum, sürekli iyileştirme ve değişime uyum sağlama olanağı sunar.

Örnek: Şelale yöntemini bir bina inşa etmeye benzetebiliriz. Binanın tüm tasarımı, kullanılan malzemeler ve maliyetler inşaata başlamadan önce büyük ölçüde belirlenir. İnşaat sırasında müşteri gelip “Şu balkonu biraz genişletelim mi?” diye sorarsa bu değişikliği yapmak artık çok daha zor ve maliyetli olabilir. Projenin ilgili kısımlarını yeniden ele almanız gerekebilir. Bu durum yazılım projelerinde ise tam bir kabusa dönüşebilir. Scrum’ın farkı burada devreye girer: Balkonun boyutunu her Sprint’te yeniden değerlendirebilirsiniz. 🏗️

Çok daha absürt bir örnek veresim geldi: Tren rayı döşerken tabii ki Şelale yöntemini kullanırsınız. Çalışmayan bir trenin yolcu için hiçbir anlamı yoktur. Yolcu, rayların nasıl döşendiğiyle değil, trenin çalışıp onu gideceği yere ulaştırmasıyla ilgilenir. Ray döşerken potansiyel yolcuların çağrılıp onlara “Bak, iyi döşüyor muyuz?” diye sorulduğu hiç görülmemiştir. Belki Émile Zola, La Bête humaine (Hayvanlaşan İnsan) kitabını; Ayn Rand da Atlas Shrugged (Atlas Silkindi) kitabını yazarken ilham almak için ray döşeme çalışmalarını izlemişlerdir. Bu, tren raylarının döşendiği esnada Scrum uygulandığı anlamına gelmez. Of, iyice abarttım; susuyorum ve yazıyı bitiriyorum.

Siz Scrum’ı nasıl öğrendiniz?

Scrum etkinlikleri sırasında yaşadığınız zorluklar nelerdi?

Günlük toplantılar sizde de rapora dönüştü mü?

Bu yazıda Scrum’ın temel yapı taşlarına odaklandım. Bir sonraki yazımda ACM Agile Türkiye eğitiminin bana kattıklarını ve Mehmet Yitmen’in kitaplarından öğrendiğim pratik bilgileri paylaşacağım. Takipte kalın!