(De)Motivation Factors in Agile Teams from the Design
Perspective
Necmettin Ozkan
Kuveyt Türk Participation Bank, R&D Center, Kocaeli, Turkey [email protected]
Abstract. This study aims to reveal the factors that have an impact on employee (de)motivation, through the fundamental design features of agile software development in general and Scrum in particular. To determine the fundamental features of design dimension of the Agile Software Development, the Agile Manifesto and Scrum Guide are based on. In order to identify the factors, an analysis is made over the Agile Software Development Manifesto, Scrum Guide and 16 studies from a literature review within the same context. Then, the (de)motivation factors are justified and enriched with practice by performing semi-structural interviews. Thus, this study presents a comprehensive and outlined reference including the existing studies of the subject and the first attempt in the literature with its approach to handling the subject merely with its design dimension.
Keywords: Agile Software Development, Scrum, Team, Project, People, Motivation, Demotivation.
Çevik Takımlarda Tasarımsal Boyutuyla
(De)Motivasyon Faktörleri
Necmettin Özkan
Kuveyt Türk Katılım Bankası, Ar-Ge Merkezi, Kocaeli, Turkiye [email protected]
Özet. Bu çalışma, genelde çevik proje yönetimi ve özelde Scrum’ın temel tasarımsal özellikleri üzerinden, çalışan motivasyonuna etkisi olan faktörleri açığa çıkarmayı hedeflemektedir. Çalışma, temel tasarım boyutunu tanımlamak için Çevik Manifesto ve Scrum Kılavuzu’nu baz almıştır. Çevik Yazılım Geliştirme Manifestosu ve Scrum Kılavuzu üzerinden yapılan analiz sonucu ortaya çıkan ve literatür taraması sonucu ulaşılan 16 adet çalışmanın içeriklerinden tasarımsam boyut ile ilgili olduğu düşünülen faktörler, çalışan motivasyonunu etkileyen unsurlar olarak belirlenmiştir. Sonrasında, teori boyutunda belirlenen bu (de)motivasyon faktörlerinin yarı yapısal görüşmeler yapılarak pratik düzlemde doğrulaması ve zenginleştirilmesi yapılmıştır. Bu çalışma, mevcut çalışmaları derleyerek genel ve özet bir referans olma özelliği sunmaktadır. Ayrıca, konuyu sadece tasarım boyutuyla (Çevik Yazılım Geliştirme
Manifestosu ve Scrum Kılavuzu bazında), bütünleyici olarak ele alması ile literatüre bir ilk olma özelliği taşır.
Anahtar Kelimeler: Çevik, Scrum, Motivasyon, Yazılım Geliştirme, Proje
1. Giriş
Teknoloji, süreç ve insan üçlemesinde insan ayrı bir yere sahiptir. Hem potansiyelinin aralığı esnek ve geniş olabilmekte hem de teknolojiyi ve süreçleri tasarlayıp onlara şekil vermektedir. İçinde bulunduğu kurumu etkileyen önemli faktörlerdendir ve proje başarısını doğrudan etkiler [21]. Her ne kadar insanın efektif yazılım geliştirme süreçleri için önemi bilinse de [1,2,3], insan faktörü göz ardı edilmeye devam edilmekte [4, 12] ve bu ciddi bir sorun olarak kendini göstermektedir [14].
Motivasyon ise üretkenlik, kalite ve proje başarısını direkt etkileyen önemli bir insan unsurudur [18, 19]. Motivasyonu ekonomik girdiler dışında etkileyen birçok etken vardır [16] ve çevik proje yönetimi, çalışan motivasyonunu farklı yönde etkiler [11, 12, 19, 28]. İnsan faktörünün ve motivasyonun önemine rağmen, insanı odağına alan ve son zamanlarda çokça kullanılmaya başlanan çevik projesi yönetimi özelinde çalışan motivasyonunun ele alındığı çalışma sayısı göreceli olarak azdır [12, 25].
Bu çalışma, konuyu tasarım boyutunda ele almayı tercih etmekte ve çevik proje yönetiminin tasarımında (de)motivasyonu etkileyen unsurları irdelemeyi hedeflemektedir. Çalışma, temel tasarım boyutunu tanımlamak için Çevik Manifesto ve Scrum Kılavuzu’nu baz almıştır. Bu kapsamda çalışma iki yol üzerinden teorik düzlemdeki (de)motivasyon faktörlerini açığa çıkarmıştır: Çevik Yazılım Geliştirme Manifestosu [20] ve Scrum Guide [13] üzerinden yapılan analiz sonucu ortaya çıkan faktörler ve literatür taraması sonucu ulaşılan 16 adet çalışmanın içeriklerinden çevik proje yönetiminin kendi evrensel tasarım kurgusu ile ilintili olan faktörler. Bu kapsamda, yazılım geliştirme ve proje yönetimi yöntemlerinden bağımsız olan fiziksel şartlar, sektör baskı vb. ve Çevik Yazılım Geliştirme Manifestosu ve Scrum Guide’ta ifade edilene göre eksik veya kusurlu uygulamalardan kaynaklanan (Scrum Master’ın kontrol odaklı olması, günlük toplantıların hesap vermeye dönüşmesi, müşterinin sürece dahil olmaması, toplantıların eksik yapılması gibi) etkenler göz ardı edilmiştir.
Birincil kaynak olarak saha çalışmalarının seçilmemesinde saha çalışmalarının bağlamının, özellikle içinde insan parametresini barındırıyorsa, çeşitlilik ve genelleme yapamayacak kadar farklılık göstermesidir [12, 19, 28]. Ek olarak saha çalışmalarının bütünü kapsayacak kabiliyette olmaması, ilgili tüm faktörlerin belirlemesini zor kılmaktadır. Bu nedenlerden dolayı sağlıklı bir belirleme için ilk aşamada pratik düzlem yerine öncelikle, bağlamdan bağımsız olarak, teori ve tasarım üzerinden bir incelemeye gidilerek çalışmanın pratik etkilere bağlı bozulmalardan soyutlanması hedeflenmiştir. Tasarım boyutunda (de)motivasyon faktörleri belirlendikten sonra elde edilen çıktının pratik düzlemde sınanarak doğrulaması ve gerekli ise zenginleştirilmesi yapılmıştır. Bunun için, teori boyutunda belirlenen (de)motivasyon faktörleri yarı yapısal görüşmeler yapılarak pratik ile kıyaslanmış, gerekli ise faktörler kümesine eklemeler yapılmıştır.
Çalışma, odağına genel manası ile çevik yaklaşımı almakla birlikte pratikte yaygın olarak kullanılan Scrum çerçevesi özelinde değerlendirmeler yapmıştır. Bu yolla, sahadaki alan genişliğini kapsama ve pratik kullanımla somutlaştırma amacı güdülmüştür.
2. Benzer Çalışmalar
Bu çalışmanın kapsamına giren çalışmalara ulaşmak için yapılan literatür taramasında "agile motivation" anahtar kelimeleri ile 02-03/05/2019 tarihlerinde arama yapılmıştır. Dönen sonuç sayısı inceleme için makul olmadığı durumlarda aramanın yapıldığı yer üzerinden daraltma yapılmıştır. Arama yapılan kütüphane, arama kelimesi, kütüphane içinde arama yapılan içerik türü ve dönen sonuçlar Tablo -1’de paylaşılmıştır. Başlıkta arama yapıldığı zaman, arama yeri daraltıldığı için “Agile” anahtar kelimesine ek olarak “Scrum” anahtar kelimesi ile ayrı bir arama daha yapılmıştır. Konu ile ilintili olma durumunu analiz etmek için "agile satisfaction" kelimeleri ile örnek iki kütüphanede arama yapılmış, dönen sonuçların konunun içine dahil olması durumuna bakılarak bu anahtar kelimelerle daha geniş kapsamda arama yapılmasına gerek görülmemiştir.
Tablo 1. Literatür Taraması
Kütüphane Arama Kelimesi Arama
Yeri Dönen Sonuç ACM agile motivation Tüm İçerik 95 DOAJ 17 IEEE 96 Scopus 359 Google Scholar Başlık 23 Springer 3 Google Scholar
scrum motivation Başlık 2
Springer 0
DBLP agile motivation Metadata 14
WoS agile motivation Metadata 223
*WoS ve DBLP tam metin içinde aramaya imkan vermemektedir.
Arama sonuçlarından dönen toplam 832 çalışma başlık ve gerekli olması durumunda özet metinleri üzerinden incelenmiştir. Çalışmaların seçilmesinde aşağıdaki dahil etme (D) ve hariç tutma (H) kriterleri uygulanmıştır:
D1: Hakem değerlendirmesinden geçen, D2: İngilizce olan,
H1: Yazar tarafından tam metnine erişimi olmayan (3 tane çalışma yazarın tam metne erişimi olmadığı için kapsama alınmamıştır),
H2: Formal olmayan (tez, deneme vb.)
H3: Özelde Scrum dışında bir çevik yönteme (XP, FDD vb.) odaklanan çalışmalar Seçilen 35 çalışma tam metinleri üzerinden incelenmiş, bu çalışmanın bağlanımda 15 çalışma belirlenmiştir. Aynı yazarlara ait benzer 2 çalışmanın metodunda (anahtar arama
kelimelerinde) hata bulunması nedeniyle bu çalışmalar hariç tutulmuştur. Belirlenen 13 çalışma referans listesi ile birlikte incelenmiş ve ilgili olduğu tespit edilen 3 adet çalışma, [5, 6, 19], kapsama eklenmiştir. 16 adet çalışma içinden bu çalışma ile benzer şekilde çevik proje yönetimi (de)motivasyon faktörlerini kapsamlı bir şekilde inceleme hedefinde olan 7 tane çalışma, [7, 10, 12, 22, 25, 28, 30], tespit edilmiştir. Belirlenen 7 adet çalışmanın listesi ile tüm referans kaynakların içerdikleri (de)motivasyon faktör adetleri (Tablo-2) paralellik göstermekte, ilk beş sıradaki kaynağın kapsandığı görülmektedir. Böylece her iki yolla (hem içerik hem de faktör adedi bazında) benzer bir listenin oluştuğu söylenebilir.
Tablo 2. Referans Kaynakların Faktör Adetleri Referans Kaynak Faktör Adedi
12 17 25 16 22 14 30 13 7 12 9 9 8 6 28 6 19 5 29 4 27 4 6 3 10 2 24 2 5 1 23 1 Toplam 115
Çalışma [12], çevik bağlamdaki motivasyon faktörlerini 2012 yılına kadar olan sistematik literatür gözden geçirme ve üç farklı şirkette yapılan saha taraması ile ortaya koymaktadır. Çalışma [28], iki çevik takım üzerinden yapılan incelemeler ile çevik projelerde motivasyon faktörlerini incelemektedir. Çalışma [10] yazılım geliştirme test uzmanları açısından çevik ve klasik yöntemlerin motivasyonu nasıl etkilediğini nitel bir anket üzerinden incelemiştir. Çalışma [30], “İlerleme Prensibi” teorisi üzerinden çalışan motivasyonu Scrum pratiklerini nasıl etkilediğini araştırmıştır. [25], üç çevik uygulamanın (günlük stand-up, iterasyon planlama ve iterasyon retrospektifi) çevik takımların motivasyon ve de-motivasyonuna nasıl etkide bulunabileceğini araştırmıştır. Aynı yazarın [22] çalışması benzer bir kapsamı iki ülke özelindeki takımlar ile ortaya koymaktadır. Çalışma [7], çalışan motivasyonunu ve özelde yazılım geliştirici motivasyonunu etkileyen faktörleri ortaya koyduktan sonra çevik yazılım geliştirme yaklaşımının bu faktörlere ne ile ve nasıl katkı sağlayabileceğine dair kişisel görüşleri sunmuştur.
İlgili bu çalışmaların dışında kalan diğer 9 çalışmanın temel odağı çevik yöntemlerde çalışan motivasyonu olmasa da bu çalışmalar içerikleri itibariyle kısmı olarak bu çalışmaya girdi sağlar niteliktedir. 16 çalışmadan gelen bu girdiler Tablo 4’de iletilen referans listesinde aktarılmıştır.
Böylece bu çalışma mevcut çalışmaları derleyerek genel ve özet bir referans olma özelliğindedir. Ayrıca, konuyu sadece tasarım boyutuyla bütünleyici olarak ele alması ile literatürde bir ilk olma özelliği taşır. Bu özelliği ile de evrensel olarak (bağlamdan bağımsız) ve çevik yazılım geliştirme ve proje yönetiminin kendi orijinal tasarımsal kurgusunun çalışan (de)motivasyonuna etkisini ortaya koymaktadır.
3. Metot
Çalışma, (de)motivasyon faktörlerini belirlemede literatür taramasını ve yazar tarafından yapılan analizi yöntem olarak kullanmıştır. Seçilen literatür kaynakları ve kaynaklar içinden ilgili içeriklerin çıkartılması ve analiz edilen Çevik Yazılım Geliştirme Manifestosu ve Scrum Kılavuzu içinden ilgili içeriklerin belirlenmesi, belirlenen tüm bu içeriklerin sınıflandırılması yazar tarafından yapılmıştır. Ardından elde edilen listede, yapılan yarı yapısal görüşmeler üzerinden (analiz seti için) doğrulamaya ve (tüm set için) zenginleştirmeye gidilmiştir. Bu görüşmelerde olası eklemeler için, görüşülen kişi serbest bırakılarak içerik sağlaması hedeflenmiş, yazarın analiz maddelerini doğrulama için ise her madde bazında görüşülen kişiden değerlendirme yapması talep edilmiştir. Literatürün sağladığı mevcut liste için bir doğrulama yapılmamıştır. Buna karşın literatür ile aynı madde görüşülen kişi tarafından da ifade edilmişse buna Tablo-4’te yer verilmiştir.
Yapılan yarı yapısal görüşmeler özelinde çevik yöntemi yeteri zaman deneyimleyen, kurum kültürü çevik yöntem özelinde tam olarak oturmuş, çevik yöntemlerin dönüşüm zorluklarından ziyade, uzun soluklu çalışmalarıyla ve her tür projeyle çalışmış kişilerle örnek vaka çalışması yapılması sağlıklı olacaktır. Aksi durumda, örneğin küçük projelere odaklı çevik uygulamalar ile kritik ve büyük proje geliştirmesinde kullanılan yöntemlerin kıyaslaması denk bir platformda olmayacaktır. Çevik yöntemlerin yeni ve yükselişte olması [27], klasik yöntemlere nazaran son zamanlarda daha çok popüler olması ve klasik yöntemleri dışlayarak bir alternatif olarak kendini sunması çalışanların algılarını bir şekilde etkileyecek ve bu da dengeli bir değerlendirmeyi olumsuz etkileyecektir. Bu nedenle, görüşme yapılan kişilerin bu özellikleri barındırmasına özen gösterilmiştir. Bu kısıtlar gözönüne alınarak seçilen ve görüşme yapılan, Türkiye bankacılık sektöründen, 3 kişinin sektör ve Scrum ile geliştirme deneyimi ve rolleri Tablo 3’te iletilmiştir.
Tablo 3. Görüşülen Kişi Bilgileri Görüşülen
Kod
Toplam Tecrübe
Scrum Tecrübe Rol Scrum
Deneyim Firma G1 11 4 Analist A G2 14 3 Yazılımcı A G3 6 2 Yazılımcı B
4. Motivasyon Faktörleri
Çevik proje yönetiminde takım içindeki her kişinin kendi aralarındaki ve müşteri ile olan iletişim kanalları ve noktaları çokludur. Geliştirmenin şelale yöntemindeki gibi seri ve sıralı dizilmesi, geliştiricilerin de birbirine iletişim noktalarını bire-çok yerine bire-bir şeklinde
seri ve sıralı bağlanması manasına gelir. Çevik takım yapısı bu tek düzlemi, takımın her bireyini takım çatısı altında bir araya getirerek kırar ve zamanlama olarak bir sıra gözetmeyerek iletişim boyutunu arttırır.
Çevik proje takımlarında, takıma verilen yetkiler ile kişilerin kendi kendini yönetme, sorumluluk, seçme ve inisiyatif alma imkanı [8, 9, 12, 19, 22, 25, 28, 29], sık ve erken geri bildirim alma imkanı [7, 8, 9, 12, 22, 25, 29, 30, 31], birlikte çalışma [7, 9, 12, 19, 22, 24, 25, 27, 28, 30], eşitlik sağlama[12], müşterinin sürece dahil olması [12, 19], ait olma hissi [19, 25], bilgi paylaşım imkanı [9, 12, 22, 28, 30], ortak hedefe odaklanma [7, 22], takımın uçtan uca ürüne hakim olması [12, 19, 29, 30], geliştiricinin odağını koruyabilmesi [22, 30], sağlanan katkının ortaya çıkması, hissedilmesi ve başkaları tarafından görülmesi [7, 12, 22, 25, 29, 30], iletişimin kolay, açık ve hızlı olması [7, 8, 9, 10, 12, 22], yüksek standartta geliştirme imkanı [7, 8, 12], ve takımın üyelerine gelişme ve öğrenme imkanı tanınması [7, 12, 30] çalışan motivasyonunu olumlu etkiler. Takımın hem dışa hem de kendi içindeki değişiklik ihtiyacına cevap verebilme yeteneği [9] çalışanı motive eder [12], adaptasyon yeteneğini arttıran süreçler çalışanın iş-özel hayat dengesi kurmasını kolaylaştırır [12].
Çevik proje takımlarının motive olmayan ekip üyelerine karşı veya organizasyonun motive olmayan takımlara karşı yaptırımları ile ilgili dengeleyici bir yaklaşım sunulmamaktadır. Örneğin kendine konfor alanı bulan takım üyesine veya takıma karşı yaptırım gibi denge unsurları gerekli olabilir. Motive olmayan takım üyesinin olumsuz etkileri [22, 25, 28, 30] ve bu etkinin motive olma durumuna göre üç kat daha fazla etkili olma gücü [30] göz önüne alındığında, bu alanın çevik proje takımlarını ve daha genel manada çevik yöntemleri riske sokması olasıdır. Benzer durum takımın kritik yapma, olumsuz geri bildirimlerde bulunma ve çatışmadan kaçınma durumu için de geçerlidir [25].
Her ne kadar kendine yeten bir yapıda çevik takımlar kurmak bir avantaj olsa da, bu bir zaman sonra takımların kendi içinde homojen kalmasına, dış dünyadan farklılaşarak izole olmasına [7, 30] ve merkezi tasarımlardan ve yapılardan ayrılmalarına neden olacaktır.
Takım içindeki homojen yapıya bağlı olarak, idari pozisyonlardaki basamakları içeren bir hiyerarşiden ziyade düz bir organizasyon yapısı, kurumların kendi sınırları bir yana, insan yönetimi deneyimini değerli gören sektör için bir dezavantaja neden olur [25]. Ayrıca takımın içinde bireysel çabaların dışarıdan görülemeyip kariyer imkanına dönüşmeme riski de vardır [6]. Çalışma [7], tam tersi yönde çevik takımlarda bireysel çabaların dışarıdan daha net görülebildiğini ifade etmektedir. Bununla birlikte çevik yöntemler ile çalışmanın sektörde bir prestij ve buna bağlı olarak bir kariyer avantajı olduğu yönünde görüşler de vardır [28].
Çevik Manifesto içinde değil ama Scrum’da ürünün merkezi konumu belirgindir. Daha büyük perspektif sağlayan hizmet ve proje gibi olgulara bağlı tatmin in geri planda olması, ölçeklenebilir uygulamalarda çevik proje yönetiminin sınırlı kalması ve buna bağlı olarak büyük resmi çizememe/görememe durumu çalışanın göreceli olarak büyük çaplı işlere bağlı tatminlerden uzak kalmasına neden olur. G1’e göre Scrum’da biten işler daha çok iç tatmin sağlamakta ve küçük işler takım dışından bir noktadan takdir görmeyi azaltmaktadır. Klasik yöntemlerde başarılan büyük parçanın takdiri daha görünür ve fazla olmaktadır [G1].
Takım aktiviteleri de ürün odağından dolayı geliştirme aktiviteleri etrafında kümelenmiştir. Bu aynı zamanda takım içindeki yük dengesinin, homojen rollere rağmen, bir alt kırılımda salt manadaki ürün geliştirme rolleri eksenine kaymasına ve takım içi dengenin bozulmasına neden olur [9]. Bu denli ürün odağının olduğu sürekli bir akış içinde, takımların kendine alan oluşturarak insana dair değerleri yönetecek dengeyi bulması şarttır [5].
Şelale yönteminde, geliştirme çalışmalarının gerçek değere dönüştüğü noktaya uzaklık fazla iken, çevik yaklaşımda bu mesafe kısadır. Çevik yapılardaki iterasyonlar ve geçişler, işi küçük fakat net ve ulaşılabilir hedeflere dönüştürmeyi sağlar [7, 12, 25, 28, 30] ve çalışanların kendine olan ve müşterilerle aralarındaki güveni arttırır [7, 25]. İterasyonlu ilerleme, ürünün gerçek kullanıma daha sık geçmesinden dolayı değer görme hissini canlı tutar [12]. İterasyonlar, projenin ilk kaynağı olan müşteriye ve fikrin doğma zamanı ve yerine yakınlaştırır. Çevik yapılardaki toplantılar ve iterasyon, ilerleme hissini kuvvetlendirme [8, 9, 12, 25, 27, 30], iletişimi kolaylaştırma ve hızlandırma üzerinden motivasyonu olumlu etkiler [7, 8, 9, 10, 12, 22]. Toplantılar sosyalleşme ihtiyacı olan kişilerin bu ihtiyacını karşılamaları için birincil araçlardan biri olarak da iş görür [15]. G2’ye göre Scrum toplantılarının tanımlı bir mekaniklikte olması nedeniyle bu toplantıların hali hazırda sosyal olan kişilere etkisi düşük, sosyal olmayan kişiler için etkilisi ise olumludur. Diğer yandan yazılım geliştiriciler sık yapılan ve üretken olmayan toplantılara karşı isteksizdirler [22, 30]. Gelişime olan istekleri [17], zamanı efektif kullanmayı gerektirir. Katma değeri düşük toplantılar kendini geliştirmek isteyen yazılım geliştiriciler için zaman kaybı olarak görülür ve motivasyonu olumsuz yönde etkiler [22, 25]. Sadece ritüellere uymak için gerekli olmayan toplantıların yapılması bu durumu pekiştirir. Ayrıca Scrum çerçevesi ile gelen ritüel setinin gerçek hayatın birincil planda olmasının önüne geçmesi bir sorun oluşturur [G2]. Geliştirici gerçek hayattan tam manası ile soyutlanamayacak ve beklenen ritüellerin katı ve esnemeyen planına uyum sağlamakta zorluk yaşayacaktır [G2]. Örneğin gerçek ortam hatası ile ilgilenmesi gereken takımın veya geliştiricinin zamanı net bir şekilde belli olan Sprint planlama toplantısına katılma zorunluluğu, çerçeve ve gerçek ortam realitesi tercihi arasında kalan geliştiricinin çerçeveden kaynaklanarak yaşadığı bir sorundur [G2].
Günlük toplantılar, zaman açısından rutin ve bir öncekine benzeme açısından homojen olmaya yatkındır [22, 25]. Sürekli kısa sprintler koşmak (run), geliştirici açısından bir zaman sonra baskı [9, 10, 27] ve buna bağlı olarak stres üretebilmekte [9, 12, 22, 25], rutine dönme durumu olabilmekte [8] ve bu rutin çalışanı sıkabilmektedir [6].
Günlük yapılan toplantıda, bilinç altı olarak, sürekli ilerleme dayatıldığı gibi, retrospektif toplantılarında sürekli iyileştirme dayatılmaktadır [22, 25]. Geliştiricinin sürekli akan rutinin spesifik bir örneğinde ilerlememe veya kendini iyileştirmemeyi seçmesi teorik olarak mümkün olsa da pratikte bunun tercih etmesi zordur. Kendi çözümü olarak takımı yanıltma yollarına girebilir [25] ve bu da takımdaki güveni zedeler. Bu denli sık rutin içinde geliştiricinin kendine bir alan ve dinlenme zamanı bulması zordur. Sürekli sprintler koşmak (run) insan motivasyondaki inişli çıkışlı tabi dalgalanmalara imkan tanımazken, çalışanda bir zaman sonra yorgunluk üretir. Üretim sektörü, klasik yöntemleri nasıl şekillendirdi ise, Scrum da bu yaklaşımdan etkilenmiş, ağır planlama dışlansa da, ileriye dönük zamanın önden sabitlenmesi (iterasyonlarda olduğu gibi) ve etkinliklere ait maksimum sürenin sabit olması ile planlama olgusu ağır olmasa da daha keskin boyutuyla yaşamaya devam etmiştir. G2’ye göre dinamizmi yüksek genç geliştiriciler için bu denli net bir son tarihin motivasyonu arttırması mümkün iken ilerleyen yaşa bağlı olarak geliştiricilerin bu denli sert ve net bir son tarihin baskısını kabullenmesi kolay olmayacaktır. Yine de Sprint süresinin sabit olması ile oluşan son tarih parametresi, [23, 30]’e göre çalışan motivasyonunu arttırmaktadır. Bu sonuç odaklı bakış açısı, Sprint ve genel olarak geliştirme boyunca fazlalıkların elimine edilmesi sonucu ile çalışanı olumlu yönde etkiler [7, 12].
Çevik yöntemler, basit ve pratik dokümantasyon yaklaşım ile çalışanı motive eder [24]. Çevik Manifesto içinde kapsamlı dokümantasyondan ziyade çalışan yazılımın yeğlendiği
vurgulanır [20]. İnsan doğasının insan-insan yolunu iletişim kanalı olarak tercih etmesinden dolayı, yüz yüze iletişimin doküman üzerinden iletişime tercih edilmesi makuldür [G1]. Fakat dokümantasyon gereğinden fazla veya eksik yapılması ile bir de-motivasyon faktörüdür. Eksik yapılması durumunda kurumsal hafızada neden olduğu zayıflama orta vadede çalışan aleyhine olmaktadır [G1, G3].
Çevik yöntemlerde dokümantasyon konusu bu kapsamda tasarım ve iletişim bağlamında yeniden şekillendirmeye çalışırken, genel manadaki dokümantasyon için tanımsız bir alan bırakmıştır. Çalışanın destekçisi olan dokümantasyon, araç ve süreçler ve beraberinde getirdiği dijitalleşme yeteneğinin çevik yöntemlerde geri planda kalması insan tarafında genel manada yetkinlik eksikliği oluşturma riskini barındırır. Bu konuda organik denge olmalı, takımlar ve kurumlar ihtiyaç olan araç ve süreç seviyesini çerçevelere göre değil, kendilerine göre belirlemelidir [G2].
Çalışan boyutunda, yazılımı, geç aşamada da gelse değişimi, müşterinin menfaatini ön plana çıkaran çevik yöntemler, genel manada müşterinin hızlı kazancı için geliştiriciyi feda etme riski barındırır. Çevik yöntemlerdeki, dokümantasyon yaklaşımlarında olduğu gibi, kısa vadedeki kazanımlar için geliştiricinin orta ve uzun vadede olumsuz etkilenmesi ve de-motive olması riski vardır. Örneğin, geliştiriciyi koruyan tasarım doküman onayları çevik yaklaşımda tavsiye edilmemektedir [G1].
Belirlenen bu faktörler insan odağı, iterasyon ve toplantılar, süreç ve iletişim kategorileri altında ilgili referansları ile birlikte aşağıdaki gibi özetlenerek listelenmiştir. Tablonun “Motivatör/De-motivatör “olarak sınıflandırdığı maddeler, ilgili faktöre hem motivasyon hem de de-motivasyon unsuru olarak bakan farklı kaynakların veya analizin olduğunu ifade etmektedir. Yazar tarafından yapılan analiz literatürle örtüştüğü takdirde, literatür baskın olarak kabul edilmiş ve mükerrerliği önlemek için sadece ilgili literatür baz alınmıştır. Yazarın analizi sonucu ortaya atılan görüş literatürden farklı ise “Analiz” ifadesi ile ilgili maddeye ekleme yapılmıştır.
Tablo 4. (De)Motivasyon Faktörleri
Kategori # Boyut Faktör
Literatür Referans Adedi
Referans
Motivatör
1 İletişim Bilgi paylaşım imkanı 5 [9, 12, 22, 28, 30]
2 İletişim İletişimin kolay, açık ve hızlı olması 6 [7, 8, 9, 10, 12, 22], G3
3 İnsan Odağı Ait olma hissi 2 [19, 25]
4 İnsan Odağı Birlikte çalışma
10 [7, 9, 12, 19, 22,
24, 25, 27, 28, 30], G3
5 İnsan Odağı
Çalışanların kendine olan ve müşterilerle aralarındaki güvenin artması
2
[7, 25]
6 İnsan Odağı Gelişme ve öğrenme imkanı 3 [7, 12, 30]
7 İnsan Odağı Ortak hedefe odaklanma 2 [7, 22]
8 İnsan Odağı
Kendi kendini yönetme, sorumluluk, seçme ve inisiyatif alma imkanı
8
[8, 9, 12, 19, 22, 25, 28, 29], G3
10 İnsan Odağı İş-özel hayat dengesi 1 [12]
11 İnsan Odağı Eşitlik 1 [12]
12 Süreç Geliştiricinin odağını
koruyabilmesi
2
[22, 30]
13 Süreç İlerleme hissi 6 [8, 9, 12, 25, 27,
30]
14 Süreç İşi net ve ulaşılabilir hedeflere dönüşmesi 5 7, 12, 25, 28, 30]
15 Süreç Müşterinin sürece dahil olması 2 [12, 19]
16 Süreç
Sağlanan katkının ortaya çıkması, hissedilmesi ve başkaları tarafından görülmesi
6
[7, 12, 22, 25, 29, 30]
17 Süreç Sık ve erken geri bildirim alma imkanı 9 [7, 8, 9, 12, 22, 25, 27, 29, 30], G1
18 Süreç Uçtan uca ürüne hakim olma imkanı 4 [12, 19, 29, 30], G3
20 Süreç Yüksek standartta geliştirme 3 [7, 8, 12]
21 Süreç Fazlalıkların elimine edilmesi 2 [7, 12]
22 Süreç Değişiklik ihtiyacına cevap verebilme yeteneği 1 [12]
Motivatör/D e-motivatör
23 İnsan Odağı Kariyer imkanı 3 [6, 25, 28]
30 İnsan Odağı Takımın içinde bireysel çabaların dışarıdan görülmesi 2 [6, 7] 24 İterasyon ve toplantılar İleriye dönük zamanın (sprint
süresinin) önden sabitlenmesi
2 [23, 30], Analiz,
G2
25 İterasyon ve toplantılar Sık toplantılar 2 [22, 30]
19 Süreç Dokümantasyon yaklaşımı 1 [24], Analiz, G1,
G3
De-motivatör
26 İletişim
Dijitalleşmenin verimli ve etkin kullanılmasının geri planda kalması
0
Analiz, G2
27 İnsan Odağı
Kritik yapma, olumsuz geri bildirimlerde bulunma ve çatışmadan kaçınma
1
[25], G3 28 İnsan Odağı Motive olmayan takım üyesinin
olumsuz etkileri
4
[22, 25, 28, 30], G3
29 İnsan Odağı
Olumsuz durumların takım üyeleri tarafından gizlenmesi (takımı yanıltma)
1
[25], G1 31 İterasyon ve toplantılar Katma değeri düşük toplantılar 2 [22, 25], G1 32 İterasyon ve toplantılar Ritüellere uymak için gerekli olmayan toplantıların yapılması 0 Analiz, G1, G2 33 İterasyon ve toplantılar Ritüellerin rutine dönmesi ve sıkıcı olması 4 [6, 8, 22, 25], G1 34 İterasyon ve toplantılar Timeboxes (Maksimum sürenin
sabit olması)
0
35 Süreç Müşterinin kazancı için geliştiricinin feda edilmesi 0 Analiz, G1
36 Süreç
Sıkı rutin içinde çalışanın bir alan ve dinlenme zamanı bulmada zorluk yaşanması
0
Analiz, G1, G2
37 Süreç Sürekli (kısa) sprintler koşmanın (run) baskı ve stres üretmesi
6 [9, 10, 12, 22, 25,
27], G1, G2, G3 38 Süreç Sürekli ilerleme ve/veya kendini iyileştirme baskısı 2 [22, 25], G1 39 Süreç Sürekli sprintler koşmanın (run)
yorgunluk üretmesi
0
Analiz, G2, G3
40 Süreç
Takım aktivitelerinin ürün odağından dolayı geliştirme aktiviteleri etrafında kümelenmesi
1
[9]
41 Süreç
Takım aktivitelerinin ürün odağından dolayı insana dair değerleri yönetecek alan olmaması
1
[5]
42 Süreç Takım içindeki yük dengesinin homojen olmaması 1 [9]
43 Süreç
Takımların kendi içinde homojen kalması, dış dünyadan
farklılaşarak izole olması, merkezi tasarımlardan ve yapılardan ayrılması
2
[7, 30]
44 Süreç Büyük çaplı işlere bağlı tatmin eksikliği 0 Analiz, G1, G2 45 Süreç Motivasyondaki inişli çıkışlı tabi
dalgalanmalara imkan tanımaması 0
Analiz, G1, G2, G3
* G1: Görüşülen 1, G2: Görüşülen 2, * G3: Görüşülen 3
**Motivatör/De-motivatör kategorisinde altı çizili olan referans de-motivatör faktörüdür.
5. Değerlendirme
Tablo 4’te belirlenen (de)motivasyon faktörleri incelendiğinde yazar tarafından tespit edilen “Analiz” maddelerinin görüşme yapılan kişilerin değerlendirmeleri tarafından desteklendiği görülmektedir. Bazı maddeler için bu destekleme görüşülen kişilerin sadece biri tarafından sağlandığı için bu maddeler özelinde daha fazla araştırmaya ihtiyaç vardır.
Nicel olarak bakıldığında çevik yöntemlerin çalışan motivasyonu açısından klasik yöntemlerden daha avantajlı olduğu görülür [11, 25]. Kendi içinde değerlendirildiğinde bu çalışma içinde yürütülen literatür çalışmasından elde edilen verilere göre %65 oranında motive edici, %35 oranında de-motive edici faktör olduğu görülmektedir. Nihai liste üzerinden bu oran, %52 motive edici, %48 de-motive edici faktör olarak dağılmaktadır. Bu durumda göstermektedir ki mutlak manada çevik yöntemlerin çalışan motivasyonunu desteklediği yönünde bir çıkarıma gidilmemelidir. Her ne kadar mevcut literatür ağırlıkta motivasyon faktörlerine odaklansa da de-motivasyon faktörlerini içeren çalışmalar mevcuttur. Bu çalışmalar kayda değer sayıda ve özellikte de-motivasyon faktörü olduğunu göstermektedir. Buna ek olarak literatürde henüz yer bulmamış fakat çevik proje
yönetiminin tasarımsal olarak içinde bulunan de-motivasyon faktörleri olduğu bu çalışma tarafından ileri sürülmektedir. G2’ye göre Scrum kısmi olsa da tasarımsal boyutta gerçeklikten kopuk, kusurlu ve gerçekte uygulanması zor bir önerme ile gelmekte ve bu durum çalışan tarafında zorlanmaya, yıpranmaya, de-motive edici etkiler yaşamaya neden olmaktadır. Bu tip de-motivasyon faktörlerinin literatüre henüz girmemesinde mevcut literatür çalışmalarının çoğunlukla saha çalışmalarından beslenmesinin ve spesifik bir saha örneğinin tüm faktörleri kapsamasının zor olması rol oynamış olabilir. Örneğin çevik proje yönetimine yeni geçiş yapmış takımlarda ritüellere dair yorgunluğun oluşması veya büyük ölçekte proje geliştirmesi yapmayan bir takımda/kurumunda çevik proje yönetiminin konfor alanı dışından bir zorluğun yaşanması beklenemez.
Bu çalışma (de-motivasyondan ziyade) motivasyon faktörleri üzerine mevcut bir odağın bulunması ve motivasyon faktörlerinin genel manada bilinir olmasına karşın özellikle Scrum’ın tasarım olarak içinde barındırdığı motivasyonu olumsuz etkileyecek risklerin çalışanları etkileyebileceğini ileri sürmektedir. Scrum özelinde, bu bağlamda özellikle müşteri menfaatine hizmet eden agresif bir ürün odağı kurgusunda takımın, takım içinde bireyin kendine ihtiyaç olan alanı bulması gerekir.
Çevik yöntemler ile ilgili olumlu çıkarımlarda, çevik yöntemlerin yeni olmasının [27], kabul gördüğü çalışma türlerinin ve ölçeklerinin etkisi de vardır. Ölçeklenebilir projeler için yaşanan zorluklar farklılık gösterecek ve küçük ölçekte sıkıntı oluşturmayan yeni hususlar ortaya çıkacaktır [25, 26]. Ölçekleme konusu çevik yazılım geliştirme dünyasının önünde hala aktif bir sorun iken [26], çevik proje yöntemini bu faktörden bağımsız bir platformda ele almak sağlıklı olmayacaktır. Diğer bir husus ise, kullanım süreleridir. Çevik proje yöntemlerinin bu çalışma kapsamında saha tarafından sağlıklı olarak değerlendirilmesi için zaman olarak bir eşiği geçmesine ihtiyaç vardır. Ancak bundan sonra yapılacak saha çalışmaları sağlıklı sonuçlar verecektir. Bu nedenle bu çalışma, yapılan mevcut çalışmaları dikkate almakla birlikte farklı bir yol izleyerek, pratikten değil, teori boyutundan ilerlemiştir. Yapılan mevcut çalışmalar, ilgili yerlerde kullanılarak çalışmanın bir tür literatür referans kaynağı özelliği kazanması da sağlanmıştır.
6. Kısıtlar ve Gelecek Çalışmalar
Bu çalışma bazı kısıtlar içermektedir. Literatür taramasında seçilen ilgili kaynakların seçilme metodu ve seçilen kaynaklar içinden ilgili içeriklerin belirlenmesi ve sınıflandırılması üzerinden izlenen yöntem içinde kalıtsal bir sübjektiflik barınmaktadır. Benzer durum yazar tarafından çevik proje yönetimi üzerine yapılan analiz için de geçerlidir. Bu kısıtlar, elde edilen faktör setinin doğruluğuna ve tamlığına bir tehdittir. Doğrulama ve gerekli zenginleştirme için yapılan yarı yapısal görüşmelerin adedi göreceli olarak azdır. Bu görüşmelerde olası eklemeler için görüşülen kişi serbest bırakılarak içerik sağlaması hedeflenmiş olsa da doğrulama için yazarın yürüttüğü analiz sonucu oluşan faktör seti görüşülen kişiye sunulmuş, literatürün sağladığı mevcut liste için bir doğrulama yapılmamıştır. Bu yolun varsayımı literatürden elde edilen faktör setinin doğru olduğudur.
Genel olarak, bu çalışmanın elde ettiği (de)motivasyon faktörleri, etkileri ve etki dereceleri, daha kapsamlı bir saha çalışması ile sınanmak durumundadır. Seçilen örneklem kümesinin, çevik yöntemleri yeteri süre ile deneyimlemiş olması önemlidir. Genişletişmiş pratik çalışma sonrası bu çalışmada elde edilen bulgular gerekli ise revize edilmelidir. Bu ise gelecek çalışma konusudur.
Kaynakça
1. Hall, T. and Wilson, D. Views of Software Quality: A Field Report, lEE Proceedings on Software Engineering, April, 111-118 (1997).
2. Wilson, D., Hall, T. and Baddoo, N. : A Framework for Evaluation and Prediction of Software Process Improvement Success. Journal of Systems & Software 59(2), 135-142 (2001).
3. Hammock, N.: Critical Success Factors in Software Process Improvement, 4th Annual European Process Group Conference, June 6-10 (1999).
4. McDermid, A. and Bennett, K. H.: Software Engineering Research: A Critical Appraisal, lEE Proceedings on Software, 146 (4) August, 179 -186 (1999).
5. Hoda, R.: Self-organizing agile teams: A grounded theory. Victoria University of Wellington (2011). 6. Beecham, S., et al.: Does the XP environment meet the motivational needs of the software developer? An
empirical study. Agile Conference (AGILE), (2007).
7. Asproni, G.: Motivation, teamwork, and agile development. Agile Times 4(1), 8-15 (2004).
8. Šteinberga, L., and Darja Š.: Towards a contemporary understanding of motivation in distributed software projects: solution proposal. Scientific Papers, University of Latvia (2011)
9. Whitworth, E., and Biddle, R.: The social nature of agile teams. Agile conference (AGILE), (2007). 10. Deak, A.: A comparative study of testers’ motivation in traditional and agile software development.
International Conference on Product-Focused Software Process Improvement, (2014).
11. Tripp, J. F., Riemenschneider, C., & Thatcher, J. B.: Job satisfaction in agile development teams: Agile development as work redesign. Journal of the Association for Information Systems, 17(4), 267 (2016). 12. Melo, C.O., Santana, C., Kon, F.: Developers motivation in agile teams. 38th Euromicro Conference on
Software Engineering and Advanced Applications, (2012).
13. Sutherland, J., & Schwaber, K.: The Scrum guide. the definitive guide to Scrum: The rules of the game. ScrumGuides. com., (2017)
14. Sharp, H. C., Woodman, M., Hovedon, F. and Robinson, H.: The Role of 'Culture' in Successful Software Process Improvement. 25th EUROMICRO Conference, 170-176 (1999).
15. Khalil, O. E. M., Zawacki, R. A., Zawacki, P. A. and Selim, A.: What Motivates Egyptian IS Managers and Personnel: Some Preliminary Results. SIGCPR97, (1997).
16. Mayo, E.: The Human Problems of an Industrial Civilization, Macmillan (1933). 17. Herzberg, F. I.: Work and the nature of man. (1966).
18. Verner, J.M., Babar, M.A., Cerpa, N., Hall, T., Beecham, S.: Factors that motivate software engineering teams: a four country empirical study. J. Syst. Softw. 92, 115–127 (2014).
19. Beecham, S., Baddoo, N., Hall, T., Robinson, H., Sharp, H.: Motivation in software engineering: a systematic literature review. Inf. Softw. Tech. 50, 860–878, (2008)
20. Beck, K., et al.: The agile manifesto. (2001).
21. Cooke-Davies, T.: The “real” success factors on projects. International journal of project management, 20(3), 185-190 (2002)
22. McHugh, O., Conboy, K., & Lang, M.: Motivating Agile teams: A case study of teams in Ireland and Sweden. In International Research Workshop on IT Project Management, (2010).
23. Harris, M. L., Collins, R. W., & Hevner, A. R.: Agile methods: Fast-paced, but how fast?. AMCIS 2009 Proceedings, 149, (2009).
24. Altameem, E. A.: Impact of Agile methodology on software development. Computer a nd Information Science, 8(2), 9 (2015).
25. McHugh, O., Conboy, K. and Lang, M.: Using agile practices to influence motivation within it project teams. (2011).
26. Dingsøyr, T. and Moe, N. B.: Research Challenges in Large-Scale Agile Software Development, ACM Software Engineering Notes, 38-39 (2013)
27. Whitworth, E., and Biddle, R.: Motivation and cohesion in agile teams. International Conference on Extreme Programming and Agile Processes in Software Engineering. Springer, Berlin, Heidelberg (2007).
28. Albuquerque, R., et al.: Motivating Factors in Agile and Traditional Software Development Methods: A Comparative Study. Brazilian Workshop on Agile Methods. Springer, Cham (2016).
29. Tessem, B., & Maurer, F.: Job satisfaction and motivation in a large agile team. International Conference on Extreme Programming and Agile Processes in Software Engi1neering. 54-61, Springer, Berlin, Heidelberg 2007.
30. Jansson, T.: Agile Project Management: Is Motivation Theory the Missing Link?. In Modern Techniques for Successful IT Project Management, 138-167, IGI Global, 2015.
