Güncellenmiş Scrum Guide’ın Satır Aralarında Neler Gizli?
18 Kasım Çarşamba günü 7. versiyonu yayınlanan Scrum Guide’a “Nihayet mükemmel oldu” denilemese de şaşırtıcı derecede yalınlaşarak daha rafine bir hal aldığını söyleyebiliriz.
Sadece 84 sayfadan oluşan ama içeriğiyle her yaştan hepimize farklı şeyler düşündüren Küçük Prens’in yazarı Antoine de Saint-Exupery şöyle söylemiş: “Mükemmelliğe, eklenecek bir şey kalmadığında değil, çıkarılacak bir şey bulunamadığında ulaşılır.” 18 Kasım Çarşamba günü 7. versiyonu yayınlanan Scrum Guide’a “Nihayet mükemmel oldu” denilemese de şaşırtıcı derecede yalınlaşarak daha rafine bir hal aldığını söyleyebiliriz. “Product Goal” ve “Self-managing” kavramlarının ilave edilip yazılım alanı dışına çıkılmasıyla; “Servant Leader” ifadesinin çıkarılmasıyla Scrum Master’ın güncellenen sorumluluklarından “Development Team” yerine “Developers” denmesine dek her biri ayrı birer yazı konusu olabilecek değişiklikleriyle Scrum Guide, satır aralarındaki nüanslarıyla uzunca bir süre tartışılacağa benziyor.
Öncelikle en fazla konuşulan özelliğiyle başlayalım: Scrum Guide’ın uzunluğu 17 sayfadan sadece 13 sayfaya indi. Ancak kelime sayılarındaki değişime bakıldığında artan yalınlık çok daha dikkat çekici. 2017 ile 2020 versiyonlarını karşılaştırıldığında toplam 6.953 kelimeden 4.079 kelimeye indiği, yani kelime sayısının %41 oranında azaldığı görülüyor. Sırf bu detay bile yeni versiyonun ne kadar daha az tarifleyici olduğunu ortaya koyuyor. Örneğin bir önceki versiyonda uzun uzun anlatılan “Monitoring Sprint Progress” ya da “Sprint Cancellation” başlıklarının yer almaması göze çarpıyor.
Fakat kelime sayısı azaldığı için değişikliklerin yalnızca mevcut kılavuzun kısaltılmasından ibaret olduğunu düşünmek yanıltıcı olabilir. Nitekim Scrum Guide’ın amacının anlatıldığı kısım 56 kelimeden 233 kelimeye çıkmış görünüyor. “Product Goal” gibi eklenen yeni başlıkların yanı sıra birçok bölümde yer alan yeni ifadeler dikkat çekiyor. Gelin bu ifadelerden bazılarına birlikte bakalım:
“Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.”
Daha en başta Scrum Guide’ın amacını anlatan kısma eklenen bu ifade Scrum’ın kullanımı yaygınlaştıkça “Scrum-but” olarak nitelenebilecek uygulamaların Scrum’ın kredibilitesine verebileceği zararı öngörerek özellikle vurgulanmış gibi duruyor.
“We follow the growing use of Scrum within an ever-growing complex world.”
Yine başlangıçta yer alan bu ifade de Scrum çerçevesinin yazılım alanının dışına çıkarak çok daha yaygın uygulanmaya başlandığının -nihayet- farkında olunduğunun altını çiziyor. Üstelik bu farkındalık dikkat çekici boyutlarda. Öyle ki yazılım geliştirme alanıyla özdeşleşmiş “releasable”, “release”, “feature”, “test”, “functionality”, “architecture” ve “requirement” kelimeleri bir önceki versiyonda toplamda 34 kere geçerken güncel versiyonda sadece “release”1 kere geçiyor, o da yazılım bağlamında değil.
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
Scrum tanımındaki değişiklik de göze çarpıyor. “Product” kelimesinin kullanılmaması ve bağlamın daha kapsayıcı hale getirilmesi Scrum’ın daha da yaygın uygulanabilmesinin önünü açıyor. “Product” demişken: Product kelimesi “Product Owner”, “Product Backlog”, “Product Goal” gibi bileşik kullanımların haricinde tek başına bir önceki versiyonda 45 kere geçerken yeni versiyonda yalnızca 14 kere geçiyor. Bu da aslında ürün odaklı bir yaklaşımdan ziyade karşılanmamış son kullanıcı ihtiyacına daha fazla odaklanmanın, yani kısaca daha müşteri odaklı olmanın öneminin altı çiziliyor denilebilir. “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.” ifadesi de neden “Product” kelimesinin daha az kullanıldığını açıklar nitelikte.
“Developers”
“Development Team” yerine “Developers” denmesi en dikkat çeken değişikliklerden. Gerçekten de bunca zaman “takım içinde takım” olarak yorumlanabilecek “Development Team” ifadesini normal karşılamış olmamıza şaşmamak mümkün değil. Yalnız “Developers” denilirken alışılageldik üzere yazılımcılar değil Scrum takımında kullanışlı herhangi bir çıktı üretmekten sorumlu üyeler kastediliyor. Artık daha güçlü bir “tek takım” vurgusu var. Takımdaki kişi sayısının 10 ile sınırlandırılması ve tüm takıma atfedilen paydaş iş birliği sorumluluğu gibi detaylar da bu tek takım vurgusunu kuvvetlendiriyor. Öte yandan Scrum takımındaki roller izah edilirken daha önce ilk olarak Product Owner’dan bahsedilirken artık orada Developers’ın yer alması bu rolün önemine vurgu olarak yorumlanabilir. Product Owner ve Scrum Master’a yönelik yaygın hiyerarşik üstünlük algısını ortadan kaldırmaya yönelik bir çaba olarak da düşünmek mümkün tabi ki.
“Product Goal”
En dikkat çeken yeniliklerden biri de “Product Goal”. Simon Sinek’in ünlü “Start With Why” başlıklı TED konuşmasından esinlenmiş gibi ilk önce amacın tariflenmesi önemli bir boşluğu dolduracak gibi. “Çıktı / Output” üretmeye odaklanmış takımları kapıldıkları girdaptan kurtararak “Sonuç / Outcome” üretmeye yönlendirmeye dönük önemli bir adım gibi değerlendirilebilir. Bununla birlikte “Product Goal” ve “Product Backlog” arasında hala “Product Strategy” gibi önemli bir boşluğun bulunduğu söylenebilir. Diğer yandan “Product Goal” ifadesi yerine “Team Purpose” kullanılmış olsaydı belki de çok daha kapsayıcı, anlamlı ve de müşteri odaklılığı vurgulayan bir derinlik kazandırılabilirdi.
“In a nutshell, Scrum requires a Scrum Master to foster an environment where…”
Bu yarım kalmış cümle daha ikinci cümlede Scrum Master’ın liderlik rolünün altının çizildiğini göstermesi adına önemli. “The Scrum Master is accountable for the Scrum Team’s effectiveness.” ifadesinin ilave edilmesi çoğu takımda bu rolün yanlış yorumlandığının gözlemlendiğini teyit eder nitelikte. Scrum Master’a takım performansıyla ilgili sorumluluk yüklerken takımı yönetme yetkisinin -doğal olarak- bulunmaması bu rolü belki de daha da zorlayıcı bir hale getiriyor. Bununla birlikte Scrum Master ile ilgili tartışmalı “Servant Leader” ifadesinin kaldırılması, onun yerine “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.” ifadesinin kullanılması da göze çarpıyor. Zaten ender bulunan ideal Scrum Master yetkinliklerinin daha da zorlayıcı bir çerçeveye oturtulmasıyla Scrum Master ve takımın geri kalanı arasında daha fazla gerilim gözlemleyeceğimizi ve bu değişikliği nasıl yorumlamamız gerektiğini çokça tartışacağımızı öngörmek mümkün.
“Scrum is built upon by the collective intelligence of the people using it.”
Kollektif kapasiteye vurgu da önemli yeniliklerden. “Collective” kelimesi bir önceki versiyonda hiç geçmezken güncellenmiş versiyonda 2 kere yer aldığını görüyoruz. Paralel şekilde “self-organized” yerine kullanılan “self-managing” kelimesi de 2 kere geçiyor. Bu değişikliklerin sahiplenme, yaratıcılık ve değişim adaptasyonunu kuvvetlendirdiğine inanılan Scrum takımının otonomisini güçlendirmenin amaçlandığı olarak yorumlamak mümkün olabilir. Bununla birlikte Product Goal’ün de ilave edildiği “artifact”lerin “commitment” olarak tanımlanması hesap verilebilirliği artırmayı amaçlıyor olabilir. Bu iki değişikliği birlikte değerlendirince neredeyse her alanda olağanüstü boyutlarda yaygınlaşan Scrum çerçevesinin, kendi kendine kontrol mekanizmasını güçlendirerek hatalı uygulamaların Scrum’a verebileceği hasarı azaltmayı amaçladığı düşünülebilir. Öte yandan kolektif akıl vurgusu yapılırken artık tüm dünyaya mal olmuş Scrum Guide’ın hala bir grup insan yerine Wikipedia gibi bir formatta tüm dünyadaki Scrum kullanıcıları tarafından açık kaynak olarak güncellenebileceği günleri ne zaman göreceğimizi de merak etmemek elde değil.
“Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.”
Scrum takımlarının daha çevik olabilmesi için otonomiyi azami düzeyde artırmanın hayati önemi bu ifadeyle de vurgulanmış. “(Scrum Teams) are also self-managing, meaning they internally decide who does what, when, and how.” ifadesinin eklenmesi de bunu doğruluyor. Bununla birlikte yukarıdaki ifadede geçen “the moment” vurgusu dikkat çekiyor. Öyle ki ilave edilen “However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.” ile “The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.“ ifadeleri takımların sprint’ten sprint’e değil, dış dünyada giderek artan değişikliğe anında tepki vermesinin önemine vurgu yapıyor.
“Facilitating stakeholder collaboration as requested or needed.”
Paydaşlarla etkileşimi yönetmek günümüze kadar genel olarak Product Owner’a atfedilirken, her ne kadar “as requested” ifadesi yer alsa da, bu cümle ile doğrudan Scrum Master’a işaret edilmesi de tartışma yaratacak değişikliklerden. Scrum Master’ın takımın etkililiğinden sorumlu tutulmasıyla birlikte paydaşlarla iletişimle doğrudan ilişkilendirilmesi Product Owner ile uyumlu çalışmayı zorlaştıran bir faktöre dönüşebilir. Bununla birlikte “The Scrum Team is responsible for all product-related activities from stakeholder collaboration…” ifadesi ise paydaş yönetiminin tüm takımın sorumluluğu olduğunu belirtmekle birlikte eşgüdümün önemli olduğu bu sorumluluğun takımdaki herkese atfedilmesi zaman zaman tansiyona neden olabilir.
“If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”
Bir önceki versiyonda biraz ağdalı ve de dolaylı bir şekilde anlatılmış DoD bu kesin ifadeyle çok daha anlaşılır hale getirilmiş. Yine yazılım dışı alanlarda giderek yaygınlaşan Scrum uygulamalarında kalitenin düşmesine yönelik endişelerin burada da su yüzüne çıktığı söylenebilir.
Özet olarak tüm bu değişiklikler Scrum’ın özüne daha fazla odaklanıldığı ve kılavuzun yazılım dışı alanları çok daha kapsayacak hale getirildiği şeklinde yorumlanabilir. Öte yandan bu yaygınlaşma yanlış uygulamaları ve düşen kaliteyi de beraberinde getirebilir. Giderek ivmelenen değişim hızı ve artan karmaşıklıkta işi sürekli zorlaşan sayısız Scrum takımının etkili çalışabilmesi için sadece 13 sayfalık Scrum Guide’ın satır aralarıyla çok iyi anlaşılması ve de ustaca hayata geçirilmesi daha da kritik önem taşıyor. Nihayetinde bazen söylenmeyenler söylenenlerden daha fazla şey ifade ediyor olabilir.
Yorumlar