Scrum Takımlarında Performans Ölçüm Yaklaşımı Necmettin Özkan, Erol Emir Erdaş

Scrum Takımlarında Performans Ölçüm Yaklaşımı
Necmettin Özkan, Erol Emir Erdaş

Türkiye Finans Katılım Bankası, İSTANBUL

[e-mail], [e-mail]

Özet: Scrum modellerinde performans ölçüm yaklaşımı geleneksel yöntemlerden farklıdır ve uygun bir şekilde yeniden tasarlanmalıdır. Müşterek hedeflerin bireysel başarının önüne geçtiği, ürün bakış açısıyla oluşturulmuş birçok Scrum metriğinin takım performans sonucu üretme durumunun değerlendirildiği ve takımların şeffaflığının ve Scrum’ ın temel değerlerinin korunduğu bir performans ölçümü yaklaşımının sunulması şarttır. Bu amaçla bu çalışmanın akışında, ilk olarak ölçüm kavramları hakkında bilgiler sunulmuş ve Scrum’ ın kendine özgü yapısı ve bu yapının ölçüm penceresinden değerlendirilmesi ele alınmıştır. Ardından genel kabul görmüş Scrum metrikleri takım performansı ölçümünde kullanım açısından incelenmiştir. Son olarak, organizasyonların ilgili metrikleri kullanımları ile ilgili yol gösterici bir yaklaşım önerilmiştir.

Anahtar Sözcükler: Scrum, Çevik, Performans, Ölçüm, Metrik.
A Performance Measurement Approach for Scrum Teams
Abstract: Performance measurement approach in Scrum models is different from traditional models and must be suitably redesigned. It is a clear need to put forward a performance measurement approach of Scrum with a consideration of that in Scrum collective goals supersede individual accomplishments and metrics in general are designed from product point of view and should be re-evaluated for personal performance assessment in particular, while maintaining the nature and transparency of the teams. Thus, the paper first presents fundamental information about measurement concepts. Then, the work introduces some ideas on the characteristic structure of Scrum from the measurement window. Furthermore, the study examines common and generally accepted Scrum metrics from the point of team performance measurement. In the last section, a guiding approach about using the corresponding metrics in organizations is suggested.
Keywords: Scrum, Agile, Performance, Measurement, Metric.

1. Giriş
Ölçüm tanım olarak nesne veya olaylara bir kurala göre sayı atamaktır [1]. Sayı atamanın kuralı her hangi bir tutarlı kural olabilir [3]. Tek istisna rastgele atamadır (rastgele atama nihayetinde kuralsızlığa eş değerdir) [2]. Diğer bir tanımlamaya göre, ölçüm, gerçek dünyanın formal ve ilişkili dünyaya eşleştirilmesidir [3].

Günümüzde her ne kadar veri madenciliği, süreç madenciliği ve yapay zeka gibi gelişmelerle teknolojik beynin bilgi seviyesine çıkması hedeflense de, DIKW piramidinde (veri, enformasyon, bilgi, bilgelik piramidinde) enformasyondan sonraki kısımlar insan ile makine arasındaki sınırı net olarak ortaya koyar. Bilgi teknolojileri tarafından saklanan veriler, sadece makinelere özgün yapısı nedeniyle makineler için manalı ve okunabilir iken, enformasyon makine ve insan için manalı ve okunabilir haldedir. Diğer yandan enformasyon herhangi bir ortamda saklanabilir iken bilgi (knowledge) sadece insan beyni tarafından saklanabilir formdadır. Artık bilgi makine için yorumlanabilir veya üretilebilir olmanın ötesine geçmiş ve insanın üretip, anlayabileceği bir niteliğe bürünmüştür. Aynı şey bilgelik için de geçerlidir.

Neticede ölçmenin bu yapıdan ve kendi doğasından kaynaklanan kalıtsal bazı sorunları vardır:

• 
  Bilgi teknolojileri günümüzde her ne kadar gelişmiş olsa da gerçek hayatı birebir modelleme yeteneğinden uzaktır. Ölçüm süreci bu kısıtla oluşan verileri kullandığından gerçeği temsilde sapma potansiyelini her daim barındırır.
  
• 
  Verinin kalitesinden bağımsız, ölçmenin sonucu nihayetinde bir sayısal değer veya skaladır ve bu insanı veya insana dair olguların çoğunu temsil etmeye yetmez. Sayısal değer enformasyon seviyesinde iken insana dair birçok ve özellikle soyut olgular (motivasyon, üretkenlik, memnuniyet vb.) en az bilgi seviyesindedir. Ve yine denk bir seviyeden, bir insan tarafından değerlendirilebilir. İnsan dolaylı olarak ölçüm sürecinin kapsamına girebilir veya insan direkt olarak ölçümün konusu olabilir. Her iki durumda da insan faktörü ölçümü, çok boyutlu ve yönetilmesi zor bir hale getirmektedir [3].
  
• 
  Tasarım aşamasında manalı ve kullanışlı metriklerin üretilmesini kolay değildir. Üretilen dijital verilerin göreceli olarak basit formüller (metrikler) üzerinden insanlara yön verecek değerlere dönüştürülmesi dikkat gerektiren bir konudur. Direkt metriklerde bu daha kolay iken endirekt metriklerin devreye girmesi metriklerin saklı tasarım hatalarının çıkmasına neden olabilir [3]. (Direkt metrik tek bir özelliği ölçerken, endirekt metrik birden çok özelliğe bağlı olan metrik çeşididir).
  
• 
  Sağlıklı bir ölçüm, olayların ve nesnelerin standart ve doğru veri üretmesini şart koşar. Bu da standart işletilen süreçler üzerinden doğru verinin üretilmesini gerektirir. Bu durum bir olgunluk seviyesidir ve düşük olgunluk seviyeleri için ölçüm zordur.
  

Tüm bu faktörler sonucunda ölçüm süreci, iki farklı olumsuz etki üretme potansiyeline sahip olur: bozukluktur (distortion) ve işlevsizliktir (dysfunctional) [4]. İlki, ölçme sisteminin ektisi ile çalışanların kurumun hedeflerine ulaşmak yerine ölçüm sonuçlarını daha iyi göstermeye gayret etmesi durumunu tarif eder [4]. İkincisi ise, ölçümün sonucunda çalışanların kuruma daha az değer üretmesi durumudur [4]. Neticede ölçüm yanlış kullanıldığında faydadan çok zarar getirebilir [3].

Bu bilgiler dikkate alındığında, ilkelerini çevik manifestodan alan Scrum’ da, genel manada ölçümün, özel manada ise takım (bu çalışma boyunca geliştirme ekibi manasında kullanılmıştır) performans ölçümünün farklı ve göreceli olarak zor olduğu görülecektir. Çevik manifestoya göre:

• 
  “Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. [6]” Bu yaklaşım bir plana göre ilerlemeyi zorlaştırır. Böylece ölçüm için gerekli hedef referanslardan biri olan plan kaybolmuş olur.
  
• 
  “Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır. [6]” Bu güven takıma takımın kendi durumlarını yansıtacak ölçüm verilerini üretme kapsamında da duyulmalıdır ve bu bir olgunluk seviyesidir.
  
• 
  İnsanı odağına alan Scrum yapısında, ölçüm seviyesi, bilgi piramidinde enformasyondan, ölçülmesi daha zor olan, insan tarafına (bilgi seviyesine) kaymıştır.
  
• 
  Scrum’ da bireyler ve aralarındaki yüz yüze iletişim, süreçler ve araçlara, çalışan yazılım dokümantasyona yeğlenir [6]. Böylece süreçlerin standart işletilmesi ile araçlar ve dokümanlar üzerinde oluşacak standart izlerden ve buna bağlı sayısal ölçüm yeteneğinden uzaklaşılmış olur.
  
• 
  Karar verme inisiyatifi Scrum’ da tamamen takımın elindedir [5]. Bu durum esneklik ve insan odaklılık avantajını getirse de insanların çeşitlilik ve öngörülemez özelliği neticede tekrar edilen süreçler üzerinden belirli bir tutarlık ve kalite seviyesine ve buna bağlı bir olgunluğa ulaşmayı engeller [5, 8].
  
• 
  Scrum yazılım geliştirme yaşam döngüsüne ve proje döngüsüne temel değişiklikler öngörmektedir [9].
  

Tüm bunlar göstermektedir ki Scrum modellerinde performans ölçüm yaklaşımı geleneksel yöntemlerden farklıdır ve uygun bir şekilde yeniden tasarlanmalıdır [9]. Scrum modellerinin bu duruma cevabı performans ölçümü yerine performans değerlendirmesi olmuştur. Ölçümden farklı olarak değerlendirme salt bir insan eylemidir. Göreceli olarak zordur ve içinde sübjektiflik barındırabilir. Bunun için nihai performans sonucuna direkt bir etkisi olmayacaksa bile değerlendirme sürecinde bir referans olarak kullanılması için veya direkt olarak nihai performans sonucu üretmesi için nesnel ölçümün gerekliliği varlığını korur.

Çevik yapılarda müşterek hedefler bireysel başarının önüne geçer [7]. Bu da bizi Scrum’ da bireysel performans ölçümü yerine takım performansı ölçmeye götürür. Bununla birlikte birçok Scrum metriği ürün bakış açısıyla oluşturulmuştur. Bunların takım performans sonucu üretme durumu değerlendirilmelidir. Tüm bu ölçümler yapılırken, takımların şeffaflığına ve Scrum’ ın temel değerlerine zarar verilmemesi diğer bir dikkat edilmesi gereken noktadır.

Bu çalışma tüm bu hususları dikkate alarak Scrum’ da takım performansının ölçülmesi ile ilgili bir yaklaşım sunmayı hedeflemektedir. Çalışmanın akışında, genel kabul görmüş Scrum metrikleri takım performansı kullanım alanı açısından incelenecektir. Ardından, organizasyonların ilgili metrikleri kullanımları ile ilgili yol gösterici bir yaklaşım önerilerek genel bir değerlendirme ve özet ile çalışma sonlandırılacaktır.

2. Scrum Metrikleri

Literatürde Scrum ve çeviklik ile ilgili kullanılması önerilen metriklerin tümü Scrum’ a has değildir. Kimi metrik genel bir kullanım alanına sahip olup, metodoloji bağımsızdır. Aşağıda sık kullanılan ve literatürde yerini almış Scrum’ metrikleri incelenmiştir. Sayılarının değişik varyasyonlarla arttırılması mümkün olsa da liste temel olanları sağlama hedefindedir.
Kullanım İndeksi (Usage Index): Geliştirilen uygulama ve özelliklerin son kullanıcı tarafından kullanım yoğunluğunu ölçen indekstir. Bu ölçümün sağlıklı bir değer üretmesi, gerçek ortam kullanımlarının bir uygulama desteği ile izlenerek, nicel değerler oluşturması ile mümkündür. Bu şekilde atıl kalan, yaşlanan veya beklenen kullanım yoğunluğunun altında kalan uygulama alanları tespit edilir. Bu denli kritik bir ölçümün bir takım performans değerine dönüştürülmesi yine de pek doğru olmayacaktır. Çünkü uygulamanın kullanımının istenen seviyelere taşınması kurum geneline yayılan bir işbirliği ile mümkündür. Müşterinin doğru gereksinimler üretmesi, ürün sahibinin bunları takıma doğru ve doğru sırada aktarması ve takımın bekleneni, beklenen kalite ve zamanda üretmesi ile beklenir. Müşteri ve ürün sahibi daha çok uygulamanın “ne” sorusu belirlerken, takım neyin “nasıl” yapılacağı kısmında rol oynar ve bu manada bu metriğin sonucuna etkisi göreceli olarak azdır. Takım performansının ölçümünde kullanılacaksa bu ayrımın sağlanması önemlidir.
Sprint Tüketme (Sprint Burndown): Mevcut sprint boyunca ilerleme durumunu günlük izlemeye yardımcı olan bir metriktir. Geride kalan ve sprint içinde tamamlanması beklenen işlerin toplamıdır. Azalan bir trend ile sıfır noktasına sprint sonunda ulaşması beklenir. Hedefin altında kalmasının nedeni:

• 
  Yeni işlerin sprint içinde alınması ve iş planının dengeye bu doğrultuda çekilmemiş olması,
  
• 
  İş süresi ile ilgili tahminlemenin hatalı yapılış olması,
  
• 
  Takımın ilerlemesine engel durumların oluşması,
  
• 
  Takımın performansının beklenenin altında olması olabilir.
  

Bununla birlikte günlük kırılımda takımın bitirmesi beklenen işlerin tahminlemesini yapmak çok sağlıklı olmayabilir. Bu duruma karşın teorik olarak lineer bir çizgide işlerin tüketileceğini varsayılır fakat bu da pratik ile örtüşmeyecektir. Bu nedenle günlük hedef yerine sprint sonunda asıl hedef olan sıfır çizgisine gelinmesi en reel hedeftir. Takımın kendi içindeki işleri yönetmek için bu atomiklikte ve frekansta kullandığı bir metrik müşteriye pek manalı değildir. Bu nedenle bu metrik yerine takım bu manadaki performansını “teslimat oranı” üzerinden ölçmek tercih edilebilir.
Hız (Velocity): Takımın hızını ölçer. Bir sprint’ te tamamlanan iş miktarıdır ve üretkenliğin göreceli ölçüsüdür. Bu ölçü takımdan takıma, takımın kapasitesine ve hatta takım içindeki bireylerin yeteneklerine göre değişir. Bu nedenle takımın değişmeyen üyeler ile devam etmesi durumunda manalı sonuçlar üretir. Manalı sonuç elde edilse bile, bitirilen işin miktarı başka bir takımın iş miktarı ile kıyaslanamaz. Ölçü birimini takım belirler ve değer takımın dışında bir dünyada manasız kalır. Takımın zaman içindeki hızının seyrinin olgun takımlarda tutarlı olması beklenir. Yine de hedef vermek zordur ve en iyi ihtimalle bir zaman sonra baz alınacak geçmiş değerlere ihtiyaç duyar. Hızın belirli bir değerin üstünde olması bir performans ölçüsü olabilir fakat “teslimat oranı” benzer sonucu müşteri açısından daha manalı bir formda verir. Hedef vermenin zorluğu, hız ölçüsünün sağlık derecesinin takımın üyelerinin aynı kalmasına bağlı olması ve değerlerin takımlar arası kıyaslanabilir olmaması bu tercihi pekiştiren etkenlerdendir.
Teslimat Oranı (Delivered/Committed):

Sprinte alınan her bir iş müşteriye bir taahhüttür. Sprint sonunda tamamlanması gerekir. SBI’ ların sprint sonunda tamamlanma oranıdır. Takım kendisi ve kapasitesini hakkında bilgisinin olmasını gerektirir. Bu zaman gerektiren bir süreç olabilir. Yeni kurulan takımlarda sapmaların yaşanması olası bir durumdur. Zaman içinde yüksek orana gitmesi beklenir. Bu zaman boyunca ve sonunda oranın düşük olmasının aşağıdaki nedenleri olabilir:

• 
  Takımın iş tahmin etme pratikleri ile ilgili sorunları olabilir
  
• 
  PO, DT’ ye iş kalemi ile ilgili yeterli bilgiyi aktarmamış olabilir
  
• 
  Net olmayan kapsamdan dolayı iş beklenenden fazla zaman almış olabilir
  
• 
  Takımın iş üretme kapasitesinde düşüş olabilir.
  

Yukarıda listelenen sebeplerin bir kısmının takımın iradesinin dışındaki bir alanda olduğu görülmektedir. Bu metriğin bir performans kriteri olarak kullanılmasında bu boyutlara ve kısıtlara dikkat edilmesi önem arz eder. Bununla birlikte takım kendine bir konfor alanı oluşturarak kapasitesinin altında taahhüt vermiş olabilir. Performans ölçütü olarak bu metriğin kullanılması bu sorunu pekiştirebilir. Bu potansiyel durumu keşfetmek için takımın hız (velocity) bilgisinin incelenmesi faydalı olacaktır. Takımın fonksiyonel olarak bekleneni sağlaması, teknik borçlanarak da yapılmış olabilir. Çıktılarda fonksiyonel sıkıntı oluşturmayıp, bakım, esneklik, yeniden kullanılabilirlik gibi fonksiyonel olmayan kalite indekslerin yakından, bir dengeleyici unsur olarak izlenmesi, kısa dönem kazanımların yanında, orta ve uzun vadede de kayıpların olmasının önüne geçmede katkı saplayacaktır.
Teknik Borç (Technical Debt): Teknik borç, kalitesiz yazılım geliştirme sonucu oluşan maliyettir. Fonksiyonel olarak bekleneni veren bir uygulama karmaşık veya hatalı tasarımlar nedeniyle bir zaman sonra yönetilemez hale gelebilir. Bu nedenle bu kavram hataya neden olmayan, fakat hataya neden olabilecek potansiyel sorunları da içerir. İsteyerek teknik borçlanma olabileceği gibi kalitesiz tasarlanmış ve/veya işletilmiş süreçlerin sonucunda da oluşur. Bu kalite unsuru, somut olarak yazılan koda, üretilen dokümana ve sunulan ürün veya hizmete yansır. Bu manada, üretilen hata sayısı, kod kalite puanı ve yapılan acil geçiş oranı teknik borcun ölçüm noktaları olabilir. Teknik borcu arttıran nedenlerin başta gelenleri aşağıda listelenmiştir:

• 
  Gereksinimlerin yönetilmesi ve analiz edilmesindeki eksiklikler,
  
• 
  “Definition of Done” tasarımında ve bu alana dair pratiklerdeki eksiklikler,
  
• 
  Kalitesiz tasarım veya kodlama
  
• 
  Yönetim veya zaman baskısından dolayı kaliteden verilen tavizler,
  
• 
  Sprint içinde takımın, takım dışından veya eş zamanlı işler ile bölünmesi,
  

Yukarıda listelenenler arasında takımın etki alanı dışında kalan veya takımı edilgen kılan maddelerin olması bu metriğin mutlak manada takım performansı ölçümünde kullanılmasının sakıncasını gösterir. Ölçümün bu parametreler kapsamında yapılması durumunda takımın iş kalitesini ölçen önemli bir metriktir.
Yenilik Oranı (Innovation Rate): Uygulamaya yeni fonksiyon veya yeni yetenek kazandırmak için harcanan eforun uygulamanın bakımına harcanan efor dahil toplam geliştirmeye oranıdır (yeni özellik / (bakım + yeni özellik)). Hedef verilirken ürün bazlı bakmak gerekir. Ürünün yaşam döngüsündeki yeri, çıkan hata sayısı değişecektir. Diğer önemli bir husus takımların kurgusudur. Daha çok bakım için adreslenmiş bir takım ile sadece yeni ürün geliştiren takımlarında bu oranının aynı olması beklenmez. Bu durumda bu metriğe takımdan daha geniş bir perspektifte ürün alanları bazında bakılabilir. Buna paralel olarak ölçüm çemberi bu ürün alanlarına denk gelen takımlar ölçüsünde genişletilmelidir.
Hizmet Seviye Anlaşmalarına Uyum Oranı: Sprint’ e alınan her bir özellik sprint sonunda müşteriye teslim edilme taahhüdü ile alınmış olsa da bu daha çok ürün geliştirme tarafında ürün bazlı bir kurgudur. Bununla birlikte hayatına devam eden servislerin performansını ve çalışabilirliğini etkileyen ve müşteriye direkt dokunan alanlar için müşteriler ile hizmet seviyesi anlaşmaları imzalanabilir. Scrum her ne kadar bir çevik model olsa da bir ürün geliştirme modelidir ve bu modelin teslimat sıklığı hizmetin canlılığının gerektirdiği destek çevikliğini sağlamaz. Örneğin sprint ortasında gerçek ortama dair kritik bir kesintinin düzeltici aksiyonuna dair teslimatın sprint sonundaki süreyi beklemesi veya bu akışın standart Scrum süreçlerini izlemesi tabi olarak beklenmez. Bu durumlara karşın sunulan bilgi sistemleri servislerine dair hizmet seviye anlaşmalarına uyum, bir takım performans metriği olabilir.
Müşteri Memnuniyeti: Teslim edilen ürünün müşterinin beklentilerini karşılama niteliğidir. Sprint bazlı sağlanan otomasyon çözüm fonksiyonlardan kullanıcının memnuniyet oranı, sprint değerlendirme toplantılarında müşteri geri dönüşlerinin alınması esnasında yapılacak bir puanlandırma ile ölçülebilir. Sprint bazında ölçülmesi, sprint’ in hali hazırda tanımlı bir hedefinin, belirlenmiş bir çıktısının, belirli paydaşlarının ve bu manadaki ölçüme uygun akışının olmasındandır. Sonucu yorumlamada aşağıdaki durumlar puanı etkileyen unsurlar olarak göz önünde bulundurulmalıdır:

• 
  Müşteri isteğini tam olarak aktaramamış,
  
• 
  Ürün sahibi müşterinin isteğini tam olarak aktaramamış,
  
• 
  Müşteri sürece gerektiği kadar dahil olmamış,
  
• 
  Müşteri kabul kriterlerini tam olarak aktaramamış,
  
• 
  Geliştirilen uygulama bekleneni karşılayamamış olabilir.
  

Görüldüğü üzere müşterinin memnuniyet oranında müşterinin kendisinin göz ardı edilemez etkileri vardır. Bu manada, bu metriğin sonucu salt geliştirme takımının etkisinde değildir ve anket sorularının geliştirme takımının performansını ölçmeye yönelik tasarlanması önem kazanır.
Takım Değerlendirmesi: Takımın, müşterinin ve ürün sahibinin birbirlerini anket aracılığıyla değerlendirmesi Scrum’ da tavsiye edilen bir pratiktir. Klasik organizasyonlarda bu tür değerlendirmeyi yapan kaynak yöneticilerinin Scrum yapılarında olmaması bu değerlendirmenin önemini pekiştirmektedir. Bu kapsamda takımın bireyleri kendilerini, ürün sahibi ve müşteri takımı değerlendirerek bir puan üretilir. Müşterinin ürün odaklı değerlendirmesinden farklı olarak burada takım, takımın yürüttüğü süreçler ve takıma dair olgular hakkında genel bir kanı elde edilmiş olur. Ölçüm kriterleri arasında takımın ve bireylerinin Scrum değerlerine, pratiklerine, kurallarına, çeviklik ruhuna, işlettikleri sürece bağlılıkları, iletişim olgunlukları, şeffaflık derecesi, sürekli iyileştirmeye açıklık gibi çeviklik indeksine de konu olan ve başarıyı etkileyen birçok madde bulunabilir. Dikkat edilmesi gereken önemli bir husus kültür etkenidir. Ölçümde kültürler arası farklar gözetilerek, metriğin bireylerin takım ruhuna zarar vermeyecek şekilde ölçülmesine özen gösterilmelidir.
3. Sonuç ve Öneriler

Tablo-1’ de metriklerin takım performansı ölçümü için kullanılması önerisi renklerle belirtilmiştir (yeşil: uygun, sarı: şarta bağlı uygun, kırmızı: tercih edilmemeli). Buna ek olarak metriklerin Scrum’ a has olanları E (evet) ve H (hayır) ayıracı ile işaretlenmiştir. Bu ayrım, dönüşüm geçirerek Scrum’ ı kullanan kurumların dönüşüm öncesi ve sonrası aynı metrik üzerinden durumlarını kıyaslaması için kullanılabilir. Bunun için dönüşüm öncesi ve sonrasını kapsayan Scrum’dan bağımsız metriklerin kullanılması önerilir.

Bununla birlikte Scrum klasik proje yönetimine temel değişiklikler getirmektedir. Proje tanımı ve proje üçgenini oluşturan özellikler (zaman, bütçe, kapsam) esnek ve elastiki bir yapı kazanmıştır. Klasik proje yönetiminde kullanılan birçok metrik bu manada kullanım dışı kalmıştır. İncelenen metrikler projenin bu özellikleri penceresinde de sınıflandırılarak, organizasyonlara metrik seti hazırlamalarında yol göstermeyi de amaçlamaktadır. Bu manada aşağıdaki tabloda, aynı boyuta hizmet eden birden çok metrikten biri seçilebilir. Tablonun diğer bir kullanımı tüm boyutları kapsayan bir sete ulaşmak hedeflendiğinde kendini gösterir. Bu tür bir seçimde dikkat edilmesi gereken husus, Scrum’ da kapsam esnektir. Bu boyuta tekabül eden metrikler Sprint bazlı kapsam yönetimine yöneliktir. Bütçe yönetimi geri plandadır. Çevik yaklaşımların kaliteli yazılımı müşteriye en kısa zamanda ulaştırma vaadi kendini aşağıdaki boyut sınıflandırmasında metriklerin kalite ve zaman boyutlarındaki sayıca fazlalığında ektisini göstermektedir.

Tablo 1. Metriklerin Özellikleri

Tüm bunlardan bağımsız, Scrum takımlarında performans ölçümü için ilgili süreçlerin belirli bir olgunluk seviyesine ulaşması gerekir. Benzer bir olgunluk Scrum’ ın uyarlamasında ve işletiminde de beklenir. Dışa bağımlı, dış etkilere ve baskılara açık, çeviklik kültüründen uzak, temel değerlerinde sıkıntı yaşayan kurumların mevcut durumlarının üzerine performans ölçüm süreçlerinin inşa edilmesi faydadan çok zarar getirecektir. İşin yapılmasından ziyade işin yapıldığının gösterilmesi, Scrum takımlarının elindeki özgürlüğü kurum değil bireyler lehine kullanılması, nihai performans değerlendirmesi yapan mercilerin hiyerarşik ayrıcılıklarının oluşması, güven ve şeffaflık ortamının yara alması gibi birçok yan etkinin görülmesi olasıdır.

Bununla birlikte performans ölçüm süreci performans değeri çıktısının yanında diğer süreçlere potansiyel bir iyileştirme girdisi de sağlar. Kurumların ölçüm sonuçlarını bu aşamada takımdan kişi özeline indirgeyerek, bir iyileştirme süreci işletmeleri ölçüm süreçlerinden beklenen faydayı arttıracaktır. Diğer yandan ölçümün hassasiyetinin takımdan kişiye geçişte artması, Scrum özelinde uygulaması gereken dikkat ve özenin daha da pekişmesi manasına gelir.

Tüm bunlar ölçme ve özelde performans ölçümüne bir ongunluk seviyesi olarak bakmayı ve doğru zamanda doğru yaklaşımlarla ölçüm süreçlerine başlanmayı gerektirir. Göreceli olarak yeni olan ve klasik yöntemlerden farklı olan Scrum performans ölçümü bu manada daha fazla dikkat ve özeni hak eder.

5. Kaynaklar

[1] Stevens, S. S., "On the Theory of Scales of Measurement", Science, 103: 677-680 (1946).

[2] Stevens, S. S., “Psychophysics: Introduction to its Perceptual, Neural, and Social Prospects”, John Wiley & Sons, New York, (1975).

[3] Kaner, C. ve Bond, W. P., “Software Engineering Metrics: What Do They Measure and How Do We Know?”, 10th International Software Metrics Symposium, (2004).

[4] Austin, R. D., “Measuring and Managing Performance in Organizations” Dorset House Publishing, New York, (1996).

[5] Khan, A. I., Qureshi, M. R. J., ve Khan, U. A., “A Comprehensive Study of Commonly Practiced Heavy & Light Weight Software Methodologies,” International Journal of Computer Science and Issues, Vol. 8, no. 4: 441-450 (2011).

[6] http://www.agilemanifesto.org/iso/tr/principles.html, (Erişim Tarihi: Ekim 2015).

[7] Vinekar, V., Slinkman, C. ve Nerur, S., “Can Agile and Traditional Systems Development Approaches Coexist? An Ambidextrous View”, Information Systems Management, Vol. 23, no. 3: 31-42 (2006).

[8] Zhiying, Z., 'CMM in uncertain environments', Commun. ACM, Vol. 46, no. 8: 115-119 (2003).

[9] Nerur, S., Mahapatra, R. ve Mangalaraj, G., 'Challenges of migrating to agile methodologies', Commun. ACM, Vol. 48, no. 5:72-78 (2005).