Scrum Team ve Accountability'ler: Product Owner, Scrum Master ve Developers
Scrum Guide 2020'de ekip tek bir Scrum Team'dir; içinde üç accountability vardır: değeri maksimize eden tek kişilik Product Owner, ekibin etkinliğinden accountable Scrum Master ve tester, DevOps ve tasarımcı dahil Increment'i yaratan Developers. Yazı role'den accountability'ye ve Development Team'den Developers'a geçişi, Product Owner komitesi, proxy, ayrı QA ekibi ve sekretere dönüşen Scrum Master tuzaklarını Bookstore ekibiyle anlatıyor.
Sürüm notu: Bu yazı Scrum Guide 2020'yi (Kasım 2020, Ken Schwaber ve Jeff Sutherland) esas alır; Kasım 2026 itibarıyla scrumguides.org'daki güncel resmi sürüm hâlâ budur. Önceki sürümlerle karşılaştırmalar scrumguides.org'daki revizyon geçmişine dayanır.
Önce Tahmin Et
Bookstore'da Scrum'a geçişin ikinci haftası. Yönetim dört öneriyle geliyor: iade projesinin Product Owner'ı satış, muhasebe ve müşteri hizmetleri müdürlerinden oluşan üç kişilik bir kurul olsun; Scrum Master Kerem toplantı notlarını tutsun ve Jira'daki ticket'ları güncellesin; test işleri ayrı QA (Quality Assurance) ekibinde kalsın, Deniz oradan "destek" versin; Angular geliştiricisi Zeynep haftanın iki günü başka bir projeye baksın.
Bu dört önerinin kaç tanesi Scrum Guide 2020 ile doğrudan çelişir? Hangisi çelişmez ama yine de ekibi yavaşlatır? Cevabı yazının ortasındaki tabloda bulacaksın.
Bir Scrum Team, Üç Accountability
Guide'a göre Scrum'ın temel birimi küçük bir ekip: bir Scrum Master, bir Product Owner ve Developers. Ekibin içinde alt ekip ve hiyerarşi yok; herkes aynı anda tek bir hedefe, Product Goal'e odaklanmış bir profesyoneller birliği. Ekip cross-functional, yani her Sprint değer üretmek için gereken bütün beceriler ekibin içinde. Ekip self-managing, yani kimin neyi, ne zaman ve nasıl yapacağına içeride karar veriyor.
2020 sürümünün buradaki iki değişikliği küçük görünüp büyük sonuç doğuruyor. Birincisi "Development Team" ifadesinin kaldırılması. 2017'ye kadar Scrum Team'in içinde ayrıca bir Development Team tanımlıydı; revizyon notları bu "ekip içinde ekip" yapısının Product Owner ile geliştiriciler arasında "biz ve onlar" davranışına ve proxy'lere yol açtığını söylüyor. Artık tek bir Scrum Team ve üç farklı accountability var: Product Owner, Scrum Master ve Developers.
İkincisi "self-organizing" yerine "self-managing". Eski Guide'da geliştiriciler işi kimin ve nasıl yapacağını seçiyordu; 2020'de bütün Scrum Team neyin üzerinde çalışılacağına da karar veren, kendi işini yöneten bir birim olarak tanımlanıyor. Bu, Product Owner'ın sıralama yetkisini ortadan kaldırmıyor; "ne" kararının ekip dışından dikte edilmediğini söylüyor.
Ekip büyüklüğü için 2017 Guide'ı 3 ile 9 Developer arası bir aralık veriyordu. 2020 sürümü sayıyı yumuşattı: Scrum Team çevik kalacak kadar küçük, bir Sprint'te anlamlı iş bitirecek kadar büyük, "genellikle 10 veya daha az kişi". Bookstore'un yedi kişilik ekibi bu tanımın tam ortasında.
Role Değil Accountability
Guide 2020 "role" kelimesini kullanmıyor; ekipte "üç özel accountability" olduğunu söylüyor. Fark şu: role bir unvan ya da pozisyon gibi okunuyor, accountability ise bir sonucun hesabını vermek demek. Product Owner değerin maksimize edilmesinden, Scrum Master ekibin etkinliğinden, Developers kullanılabilir Increment'i yaratmaktan accountable. Bunun yanında bütün Scrum Team her Sprint değerli ve kullanışlı bir Increment üretmekten ortaklaşa accountable.
Accountability'nin pratik anlamı delegasyonda görünüyor. Guide Product Owner'ın Product Backlog işlerini başkasına devredebileceğini ama yine de accountable kalacağını açıkça yazıyor. Selin bir item'ın açıklamasını Ayşe'ye yazdırabilir; o item'ın neden o sırada olduğunun hesabını yine Selin verir. Unvanla accountability'nin karıştırıldığı yerde ise tersi olur: "Product Owner" unvanı taşıyan ama hiçbir sıralama kararı veremeyen biri, ya da "Scrum Master" diye işe alınıp ekibin etkinliğiyle hiç ilgilenmeyen biri.
Developers: Tester, Designer ve DevOps Dahil
Guide Developers'ı Increment'in herhangi bir yönünü yaratmaya commit olmuş kişiler olarak tanımlıyor. Unvanlar burada önemsiz. Bookstore'da Can'ın unvanı "DevOps Engineer", Deniz'inki "Test Automation Engineer"; ikisi de Scrum'da Developer. Bir UX (User Experience) tasarımcısı Increment'in bir parçasını üretiyorsa o da Developer. Guide bu kelimeyi dışlamak için değil sadeleştirmek için kullandığını özellikle not ediyor.
Developers'ın gerekli becerileri işin alanına göre değişir ama Guide dört şeyden her zaman accountable olduklarını söyler: Sprint için bir plan yaratmak (Sprint Backlog), Definition of Done'a uyarak kaliteyi işin içine yerleştirmek, planlarını her gün Sprint Goal'e göre uyarlamak ve birbirlerini profesyonel olarak sorumlu tutmak. Dördüncü madde en az konuşulanı: code review'da "sonra bakarız" diye geçiştirilen bir test eksiği, ekibin kendi standardını kendi uygulamadığı anlamına gelir; bunu düzeltmek Scrum Master'ın değil, Developers'ın işi.
Sprint Planning'deki "how" kararı da tamamen Developers'ın. Guide, Product Backlog item'larının nasıl Increment'e dönüşeceğini başka hiç kimsenin söyleyemeyeceğini yazıyor. Bookstore'da mimari kararı Developers verir; bir Software Architect'in görüşü değerli bir girdi olabilir ama ekibe nasıl yapacağını dikte edemez.
Product Owner: Tek Kişi, Komite Değil
Product Owner, Scrum Team'in işinden çıkan ürünün değerini maksimize etmekten accountable. Bunu nasıl yapacağı kurumdan kuruma değişir; Guide yalnızca Product Backlog yönetiminin dört parçasını sayar: Product Goal'ü geliştirip açıkça iletmek, Product Backlog item'larını yaratıp net iletmek, item'ları sıralamak ve Product Backlog'un şeffaf, görünür ve anlaşılır olmasını sağlamak.
Guide'ın bu bölümdeki en sert cümlesi şu: Product Owner bir kişidir, komite değildir. Product Owner birçok stakeholder'ın ihtiyacını Product Backlog'da temsil edebilir; Product Backlog'u değiştirmek isteyen kişi bunu Product Owner'ı ikna ederek yapar. Bookstore'daki üç müdürlük kurul önerisi tam burada çelişir. Üç kişi aynı anda sıralama yaparsa sıralama yoktur; ekip her Sprint Planning'de kimin önceliğinin geçerli olduğunu tahmin etmeye çalışır.
Guide'ın Product Owner için koyduğu ikinci şart kurumla ilgili: Product Owner'ın başarılı olması için bütün kurumun onun kararlarına saygı göstermesi gerekir. Bu kararlar Product Backlog'un içeriğinde ve sırasında, Sprint Review'da inspect edilebilen Increment'te görünür. Selin'in sıraladığı backlog'u bir direktör koridorda "şunu araya alın" diyerek bozuyorsa, Selin'in unvanı Product Owner olsa da accountability'si başkasındadır. Product Owner ile Product Manager arasındaki fark ve product discovery işi Product Management'a Giriş serisinin "Product Management Nedir? Product Manager, Product Owner ve Project Manager Farkı" yazısında.
Scrum Master: Hizmet Eden Gerçek Lider
Scrum Master iki şeyden accountable: Scrum'ın Guide'daki gibi kurulmasından ve Scrum Team'in etkinliğinden. 2017'de "servant-leader" olan ifade 2020'de "Scrum Team'e ve kuruma hizmet eden gerçek liderler" oldu. Vurgu değişikliği bilinçli: Scrum Master pasif bir kolaylaştırıcı değil, ekibin pratiklerini iyileştirmesini sağlayan biri.
Guide Scrum Master'ın üç tarafa hizmetini sayıyor. Ekibe: self-management ve cross-functionality konusunda koçluk, Definition of Done'ı karşılayan değerli Increment'lere odaklanmaya yardım, engellerin kaldırılmasını sağlamak ve event'lerin yapılıp olumlu, verimli ve timebox içinde geçmesini sağlamak. Product Owner'a: Product Goal tanımı ve Product Backlog yönetimi için teknik bulmak, ekibin net ve kısa item ihtiyacını anlamasına yardım, karmaşık ortam için empirical ürün planlaması kurmak, stakeholder iş birliğini kolaylaştırmak. Kuruma: Scrum benimsemesinde liderlik, eğitim ve koçluk, Scrum uygulamalarını planlamak, çalışanların ve stakeholder'ların empirical yaklaşımı anlamasına yardım ve stakeholder'lar ile ekipler arasındaki engelleri kaldırmak.
Dikkat edersen listede "toplantı notu tutmak", "Jira ticket'larını güncellemek" ya da "durum raporu hazırlamak" yok. Engel kaldırmakla ilgili ifade de "engellerin kaldırılmasına sebep olmak" şeklinde: Kerem staging ortamının sürekli düşmesini kendisi düzeltmek zorunda değil; Can'ın ve altyapı ekibinin bu sorunu çözmesini sağlayacak konuşmayı başlatmak zorunda.
Bookstore Önerilerinin Karnesi
Baştaki dört öneriyi Guide'a göre değerlendirelim:
| Öneri | Guide ile ilişkisi | Daha iyi seçenek |
|---|---|---|
| Üç müdürden oluşan Product Owner kurulu | Doğrudan çelişir: Product Owner bir kişidir, komite değildir | Selin Product Owner; müdürler stakeholder olarak Review'a gelir ve Selin'i ikna eder |
| Scrum Master not tutar ve ticket günceller | Yasak değil ama accountability'si boşta kalır; ekibin etkinliğiyle uğraşacak kimse olmaz | Board'u Developers günceller; Kerem ekibin neden yavaşladığına bakar |
| Test ayrı QA ekibinde | Çelişir: ekip cross-functional olmalı ve içinde alt ekip olmaz; Increment Sprint içinde doğrulanmış olmalı | Deniz Scrum Team'in Developer'ı; test Definition of Done'ın parçası |
| Zeynep haftada iki gün başka projede | Guide yasaklamıyor; ama focus değerini ve ekibin kapasite tahminini zayıflatır | Paylaşım kaçınılmazsa Sprint Planning'de kapasite açıkça buna göre konuşulur |
İki öneri Guide'la doğrudan çelişiyor, iki öneri çelişmiyor ama ekibi yavaşlatıyor. Bu ayrım önemli: Guide'a uygun olmak her kararı iyi yapmaz, Guide'la çelişmek ise her zaman bir bedel doğurur.
Üretimde Dikkat
Accountability'lerin kâğıt üzerinde kalıp kalmadığını ölçmenin basit yolları var. Product Owner için: Sprint içinde Developers'ın bir item hakkında sorduğu soruya cevap kaç saatte geliyor? Bookstore'da Selin'in cevap süresi iki günü geçtiğinde ekip tahmine dayalı kod yazmaya başladı ve Review'da iki item geri döndü. Scrum Master için: kaç ekibe hizmet ediyor ve son üç Retrospective'ten çıkan aksiyonların kaçı uygulandı? Developers için: Sprint'te tamamlanan item'ların kaçı ekip dışından birinin işini (ayrı bir test ekibi, ayrı bir deploy ekibi) bekledi?
Ölçek tarafında Guide'ın önerisi net: ekip fazla büyürse aynı ürüne odaklanan birden çok uyumlu Scrum Team'e ayrılmayı düşünmeli ve bu ekipler aynı Product Goal'ü, aynı Product Backlog'u ve aynı Product Owner'ı paylaşmalı. Ekip bölündüğünde her ekibe ayrı bir "Product Owner" atamak, Guide'ın tam tersini yapmak demek.
Sık Düşülen Tuzaklar
Scrum Master'ın toplantı sekreterine dönüşmesi. Event takvimini ayarlayan, Jira'yı güncelleyen, Daily Scrum'da sırayla söz veren biri ekibin etkinliğinden accountable değildir; sadece idari yükü taşır. Bu durumda ekip Retrospective'te iyileştirme önermeyi de bırakır, çünkü onu takip edecek kimse yoktur.
Product Owner proxy'si. Gerçek karar verici (genellikle bir direktör) ekiple hiç konuşmaz; "Product Owner" unvanlı bir analist onun isteklerini taşır ve her soruyu "bir sorayım" diye yukarı iletir. Revizyon notlarının 2020'de ortadan kaldırmak istediği "biz ve onlar" davranışı tam olarak bu.
Yarı zamanlı Developer. Üç ekibe bölünmüş bir geliştirici hiçbir ekibin Sprint Goal'ünü sahiplenemez; her ekibin Daily Scrum'ına katılıp hiçbirinde gerçekten çalışmaz. Guide bunu yasaklamaz ama focus değerini doğrudan zayıflatır.
"QA ekibi" ve "deploy ekibi" gibi ayrı yapılar. Increment Sprint bitmeden doğrulanmış ve kullanılabilir olmalıysa, doğrulamayı yapan kişi ekibin içinde olmalıdır. Aksi hâlde her Sprint'in işi bir sonraki Sprint'te başka bir ekibin kuyruğunda bekler ve mini-waterfall başlar; bu anti-pattern'i serinin onuncu yazısında ayrıntılı ele alıyoruz.
Küçük Bir Deneme
★☆☆ Ekibindeki herkesin adını yaz ve yanına Guide'daki accountability'sini ekle. Unvanı ile accountability'si farklı olan kişileri işaretle (örneğin unvanı "Tech Lead" olan ama Scrum'da Developer olan biri).
★★☆ Son Sprint'te Product Owner'ın verdiği üç sıralama kararını hatırla. Her birinde kararı gerçekte kim verdi? Kararı veren kişi Product Owner değilse, Guide'daki "kurum Product Owner'ın kararlarına saygı göstermeli" cümlesi sizde nerede kırılıyor?
★★★ Scrum Master'ın ekibe, Product Owner'a ve kuruma hizmetlerini gösteren üç sütunlu bir liste yap ve son bir ayda her sütunda yapılan somut işi yaz. Kurum sütunu boşsa, ekibin engellerinin neden tekrar tekrar geldiğini o boşluk açıklıyor olabilir.
Ekip artık belli. Bir sonraki yazıda Selin'in asıl aracına geçiyoruz: Product Backlog neden "öncelikli" değil "sıralı" bir liste, 2020'de eklenen Product Goal ne işe yarıyor ve Guide'da olmayan Definition of Ready ne zaman faydalı, ne zaman kapı bekçisi oluyor?