Scrum bir metodoloji değil; kuralların, rollerin ve değerlerin olduğu bir çerçevedir (Framework). Bir çerçeve olarak tanımlanmasının en güzel yanı ise şirketler ve ekiplerin kendileri için en iyi olanı keşfetmelerine yardımcı olmasıdır. Scrum’ın bir framework olarak tanımlanmasında olduğu gibi her bir unsurunun bir amacı vardır. Bu yüzden Scrum’ın temel unsurlarını değiştirmek veya kaldırmak, sağladığı yararları da ortadan kaldıracaktır. Scrum’ın temel unsurlarından biri de Scrum Değerleri (Scrum Values) dir. Bu değerler Scrum’ın ahlakı ile ilgili sosyal bir bakış açısından bakmamızı sağlar. Bu değerler, işimize, davranışımıza ve eylemlerimize yön verir.

Peki nedir bu Scrum Değerleri?

• Taahhüt – Commitment
• Odak – Focus
• Açıklık – Opennes
• Cesaret – Courage
• Saygı – Respect

Bu beş değerin hatırlanması kolaydır ancak ne anlama geldiklerini anlamak zor olabilir. Bu yazı da tüm bu Scrum Değerleri ’nin nasıl uygulanacaklarını, takımlarda ve bireylerde nasıl tanımlamak gerektiğini anlatan bir derlemedir.

Scrum Değerleri – Scrum Values

Taahhüt – Commitment

Scrum Değerinden “Taahhüt”  kısaca yapmaya söz verdiklerimizdir. Bir Scrum takımı en başta Scrum değerlerine, çerçevesine taahhüt eder.

Scrum takımı her sprint planladıkları Sprint Backlog’a taahhüt eder. Bu durum bazen yanlış anlaşılabiliyor. Bunun sebebi de geleneksel yöntemlerden gelen “Tüm kapsama taahüt etmek” alışkanlığıdır. Oysaki kapsam değişkendir ve takımın bu değişime cevam vermesi gerekir. Yani bir Scrum Takımı taahhütünü kısa planlamalar üzerine yapar. Tüm kapsamı taahhüt etmez.

Peki bir Scrum takımı başka nelere taahhüt eder?

• Kaliteden ödün vermemeye, dolayısı ile Bitti Tanımına (Definition of Done) uymayı taahhüt eder, hatta DOD sürekli iyileştirilmelidir.
• Sürekli iyileşme ve gelişmeye taahhüt eder, kendine Kaizen hedefleri koyar,
• Çevik prensiplere uymayı ve Scrum çerçevesinde kalmayı taahhüt eder,
• Sprint Planning sırasında oluşan Sprint Hedefine odaklanmayı ve sprint içindeki kararları bu hedef doğrultusunda vermeyi taahhüt eder.

Odak – Focus

Scrum çerçevesi, ürünün nasıl geliştirilmesi gerektiğini söylemez. Scrum, ürünü çabuk ve israfı en aza indirmek için gerekli olan çalışma yöntemlerini keşfetmeye yönlendirir. Bir ürünü bu özellikleri sağlayarak geliştirebilmenin, aynı zamanda belirsizlik ve karmaşıklık ile baş edebilmenin en önemli koşulu ise odaklanmaktır.

Odaklanma, birden fazla sorunla karşılaşıldığında, ekibin önce neyle başa çıkacağını belirlemesine yardımcı olur. Sprint hedefine odaklanarak, çözülmesi gereken sorunlar önceliklenir.

Belirsizlik durumlarında genelde belirsizliği çözene kadar analize devam edilir. Bu daha çok geleneksel yöntemlerde yapılan bir hatadır. Odaklanma, belirsizliği takımın kabul etmesine ve geliştirmeye devam etmesine teşvik eder. Belirsizliği, deneyimleme ve geri bildirim alma yöntemleriyle çözmek, geleneksel modele göre çok daha hızlı ve güvenlidir.

Ürün vizyonuna odaklanmak, ihtiyacın dışında geliştirilecek özelliklerin önüne geçer. Böylece israf önlenmiş olur.

Scrum Guide içinde Scrum Değerlerini destekleyici bir çok pratik vardır. “Odak” değerini destekleyen Scrum pratikleri neler olabilir diye düşünürsek;

• Takım, her sprint sonunda kullanılabilir ürün parçasını (Increment) üretmek için Bitti Tanımına odaklanır. (Definition of Done)
• Takımın ne teslim edeceğine rehberlik etmek için Sprint Hedefi (Sprint Goal) tanımlanır ve ona odaklanarak sprint koşulur.
• Product Backlog önceliklendirilmiş sıralı bir listedir. Bu sayede bir sonraki yapılacak en önemli işin ne olduğuna odaklanılır.
• Scrum etkinliklerinde süre sınırlaması (Time-box) vardır. Bu kısıtlamalar bir aciliyet duygusu yaratır ve etkinliklerin amacına odaklanmayı sağlar.

Açıklık – Openness

Scrum Değerleri ‘nden “Açıklık” Scrum’daki başarı için oldukça önemlidir. Çünkü Scrum’ı destekleyen 3 temelden (Scrum Pillars) biri olan “Şeffaflık” ile doğrudan ilişkilidir. Scrum’da her şey açık ve şeffaf olmalıdır.

Scrum Pillars :

• Şeffaflık (Transparency),
• Adaptasyon (Adaptation),
• Gözlem (Inspection) 

Açıklık, ekip içerisindeki yardımlaşmaya destek olur. Ekip üyeleri açık bir şekilde çekinmeden yardım istemeli veya üyeler birbirlerine yardım sunabilmelidir. Sadece yardımlaşmaya değil, ekip üyeleri kendi perspektiflerini açık bir şekilde paylaşırsa, herkesin fikrini kapsayabilecek ortak kararlar alınabilir. Herkesin alınan kararlarda bir düşüncesi ve bir emeği olur.

Scrum Guide, scrum etkinliklerinin aynı yer ve zamanlarda yapılmasını önerir. Bu pratik, “Daily saat kaçta?”,  “Review hangi odada yapılacak?” gibi soruları ortadan kaldırır. Dolayısı ile etkinlik yer ve saat bilgisine bir açıklık ve kolaylık getirir.

Şeffaf bir Product Backlog, ürün için planlanan/planlanmayan işleri ve sıradaki öncelikli maddelerin neler olduğunu görselleştirir.

Sprint Retrospective etkinlikleri, takımın etkileşimlerini, süreçlerini ve araçlarını sürekli iyileştirmeye odaklar böylece ekip üyelerinin yaptığı geri bildirimler takımı açıklığa davet eder.

Sprint Review etkinliği, takımın ürettiği ürün hakkında paydaşlarından geri bildirim almasına ortam sağlar. Bu ortam, paydaşların ihtiyaçlarını daha net anlamaya yardım eder ve sonraki sprintlerde geliştirilecek özelliklere bir açıklık getirmiş olur. Sprint planlama sırasında bu geri bildirimler doğrultusunda bir planlama yapılır.

Tamam Da Ne Kadar Şeffaflık?

Cesaret – Courage

Şeffafl bir ortamın sağlanması ve takımın kendini güvende hissetmesi için “Cesaret” gereklidir.

Takıma genellikle işin hızlı çıkması için baskılar yapılır. Bu baskılar neticesinde teslim edilen çıktı kalitesiz olmaya mahkûmdur (Bu takımın suçu değildir). Oysaki her bir çıktı için kalite oldukça önemlidir ve taviz verilmemesi gereken bir konudur. Bu yüzden takım bu konuda dik durma cesaretini gösterebilmeli, “hayır” diyebilmeli ve çıktıyı taahhüt ettiği gibi kaliteli teslim etmelidir.

Bir takım yanlış bir yoldan gittiğini fark eder ama bu hatalarını kabul edecek cesareti göstermezse, deneyimlerinden ders çıkaramaz ve iyileşme sağlayamaz. Ekip kendi içinde veya yönetimle konuşmaya cesaretli değilse, istenmeyen kararların alınması ve istenmeyen sonuçların doğması kaçınılmazdır.

Sprint Retrospective etkinliğinin amacı, takımın kendini incelemesi ve iyileştirme yöntemleri aramasını sağlamaktır. Takımın birlikte nasıl çalıştığını ve varsa sorunları gündeme getirme cesaretini sağlar. Bu yüzden de takıma özel bir etkinlik olmalıdır.

Scrum deneysellik üzerine kurulmuştur. Eğer takım yeni şeyler denemeye cesaret edemezse, Scrum’ın faydasını da bir süre sonra göremeyecektir.

Saygı – Respect

Saygı, sadece Scrum için değil, işbirlikçi takım tabanlı çalışmanın herhangi bir şekli için en temel öğelerdendir.  Yalın yaklaşım (Lean) için 2 temel değerden (Lean Pillars) biridir.

Lean Pillars :

• Sürekli İyileştirme (Continuous Improvement),
• İnsana Saygı (Respect for People)

Scrum takımı birbirlerine saygı duyduğu sürece Scrum çalışacaktır. Takım içindeki üyeler birbirinden farklı kişilerdir. Herkesin aynı karakterlerde olması beklenemez. Takım bu çeşitliliğe ve farklılığa saygı duymalıdır.

Yöntemler veya kararlar üzerinde herkes hemfikir olmayabilir. Ancak Scrum Takımı ortak hedefleri olan bir ekip olduğu için alınan kararlar ve yöntemlere her bir üyenin saygı göstermesi beklenir. Bu, fayda sağlayacağına inanmadığımız bir karara saygı göstermek anlamına da gelir.

Geliştiriciler (Developers) cross-functional çalışır. Yani bir bütün olarak Bitti Tanımı’na uygun çıktıyı elde etmek için tüm becerilere sahiptir. Bir takım ancak birbirlerinin deneyim, tecrübe, fikir ve becerilerine saygı duyarsa gerçek bir takım olabilir. Tecrübeli bir takım üyesinin, henüz yeni tecrübe edinmeye başlamış bir diğer takım üyesinden öğrenecek mutlaka bir şey vardır.

Scrum’ın temel kurallarına ve uygulamalarına da saygı gösterilmeli ve bunun sınırlı bir çerçeve olduğu kabul edilmelidir. Bilerek veya kasıtlı bir şekilde Scrum çerçevesinden çıkılmamalıdır. Ancak Scrum’ı destekleyici yöntem ve uygulamalar eklenebilir. Tüm Scrum Ekibi Sprint Planning, Sprint Review ve Sprint Retrospective etkinliklerine katılmalı, geliştiriciler günlük planlamalar için Daily Scrum yapmalıdır. Bu etkinliklere katılımlar, her rol için farklı bakış açılarına saygıyı da arttıracaktır.

Product Backlog maddeleri ve önceliklendirilmesinde herkes Product Owner’ın kararlarına saygı göstermelidir. Benzer bir şekilde, Product Owner planlama sırasında geliştiricilerin Sprint Backlog oluşturmasına ve kararlarına saygı göstermelidir. Bu ilişkinin temelinde güven yatar. Güven ortamının sağlanması için yine “Saygı” değerine ihtiyacımız vardır.

Genel olarak organizasyona da saygı duyulması gerekmektedir. Diğer takımlara, yönetim ve denetim için şeffaflığın yaratılmasına saygı gösterilmelidir.

Agile Manifesto

İlkim Dilara KADAKALOĞLU

D.