Görsel scrum.org tarafından sağlanan logo, font ve rozet ile Canva’da hazırlanmıştır.

Görsel scrum.org tarafından sağlanan logo, font ve rozet ile Canva’da hazırlanmıştır.

Scrum hakkında yazdığım bu yazı dizisinin dördüncü ve son yazısından merhaba. Yazı dizisindeki diğer yazılara aşağıdan ulaşabilirsin:

Kavramlara alışkanlık kazanmak için aynı yazının İngilizcesini de okuyabilirsiniz.

İş hayatındaki sekizinci şirketimdeyim. Galiba sekizdi ya. e-Devlet sigorta ekranını açıp saymaya uğraşmak istemiyorum şimdi. Büyüklü küçüklü aşağı yukarı hepsi Scrum uygulamaya çalışıyordu. Tüm pratiklerini eksiksiz ve doğru uygulayan da vardı. Scrum Poker, Velocity, Burndown Chart gibi metriklere odaklanıp Türkiye’de Scrum’ı en iyi uygulayan şirket olduğunu iddia eden de! Ancak itiraf etmek gerekirse yıllar içinde çalıştığım birçok şirkette Scrum’ı yanlış ya da eksik uyguladığımızı gördüm. İşte bu deneyimler sırasında fark ettiğim bazı hatalar:


1. Rollerin Yanlış Yorumlanması

Scrum Master, Product Owner ve Geliştirici ekibi rollerinin sınırları kimi zaman flu kimi zaman tamamen çiğnenmiş olurdu. Mesela çalıştığım beş şirkette Scrum Master rolü, geliştirici ekibindeki analist arkadaştaydı. Scrum Master sadece Jira, Azure, Trello gibi iş yönetim araçlarında işleri veya görevleri (task) açıp kişilerin üzerine atayan, toplantıları planlayan ve sprint başlatan kişi değildir. Scrum Master’ın en önemli görevi olan ekipteki engelleri dinlemek ve kaldırmak buralarda çok unutulurdu.

Analistlere bu kadar yüklenmeyin lütfen çünkü bu aslında çok zor bir iştir sevgili okurum. Ayrıntılara çok dikkat etmeleri, herkesin sorularına her an açık olmaları, cevapları da biliyor olmaları ve direk bu cevabı verebilmeleri gerekir. Sprint sonuna doğru bir geliştiricinin sorusuna “Aaa biz bunu böyle düşünmemiştik, napsak acaba?” diyemez. “Analistin nasıl olsa çok işi olmaz, Scrum Master görevini de o yapıversin.” diye düşünen yöneticiler… Çok zekisiniz, tebrikler.

Çalıştığım bir şirkette Product Owner’lar sürekli müşteri taleplerini doğrudan geliştirici ekibine iletirdi, backlog’daki önceliklendirme tamamen rafa kalkardı. 3 farklı proje, 3 PO, bir de bazı dönemler yetersiz geliştirici sayısı olunca sonuç? Kaos. 3 PO’nun farklı önceliklerle geldiği bir gün CTO’nun yanına gittim ve “Önceliğe aralarında konuşup karar verebilirler mi lütfen? Ben hangi projeye yetişeceğimi şaşırdım,” dedim.

Product Owner’ın da Scrum Master’ın da hiç olmadığı, patronun (veya yöneticimin) “Yieeyyyt, PO da benim, Scrum Master da benim, var mı bana yan bakan?” dediği şirketlerim de oldu. Bu tür yaklaşımlar Scrum’ın temel ilkelerini hiçe sayarak ekiplerin verimliliğini ve motivasyonunu düşüren en büyük sorunlardan biri. Hadi iki şapka neyse, ben de çift takılıyorum bu aralar, bundan sonra da çift takacağım gibi görünüyor ama üç mümkün değil.

Öğrendiğim Ders: Rollerin sorumluluklarını net bir şekilde belirlemek ve bu sınırları korumak şart. Scrum’daki roller yalnızca birer isimlendirmeden ibaret değildir; ekiplerin görev paylaşımını düzenleyen temel unsurlardır. Bu sınırlar net bir şekilde belirlenmediğinde ekip içinde kaos kaçınılmazdır. Ayrıca her rolün kendi görevlerini yerine getirmesi yalnızca süreçleri iyileştirmez, aynı zamanda ekip içindeki güven ve şeffaflığı da artırır.


2. Etkinliklerin Formaliteye Dönüşmesi

Scrum’ın etkinlikleri ekiplerin iletişimini güçlendirmek ve süreçlerini iyileştirmek için tasarlanmış olsa da bazen formaliteye dönüşebiliyor. Örneğin, Günlük Scrum toplantıları ekibin iş birliğini artırması gereken bir platform olmak yerine herkesin sırayla “ne yaptım, ne yapacağım” dediği sıkıcı bir rutin hâline gelebiliyordu. Özellikle ekip üyeleri takıldıkları noktaları dile getirmezse bu toplantılar sadece zaman kaybı olarak algılanıyordu. Eğitmenimizin kitabındaki örnek senaryoda da ekip Daily Scrum’ı bırakmak istemişti.

Benzer şekilde, Sprint Retrospective toplantıları da bazı şirketlerimde yeterince ciddiye alınmazdı. Katılımcılar Retrospective toplantılarını sadece “bir şeyleri konuşmuş olmak” için yapar ve çoğunlukla somut aksiyon maddeleri belirlenmeden toplantıyı bitirirdi. Bu durum ekiplerin süreçlerini iyileştirme fırsatlarını kaçırmasına ve aynı hataları tekrar etmesine neden olurdu. Bazı şirketlerde ise bu toplantılar gereksiz görülerek tamamen iptal edilirdi. Bu da Scrum’ın sürekli iyileştirme prensibine tamamen aykırıydı.

Bir diğer sık karşılaştığım sorun ise Sprint Review’lerin bir “sunum şovuna” dönüşmesiydi. Paydaşların gerçek geri bildirim vermediği, geliştiricilerin ise tamamlanmamış işler için bahaneler sunduğu bir ortam Scrum’ın şeffaflık ve adaptasyon ilkelerini baltalardı.

Kalabalık ekiplerde Sprint Review toplantıları gereğinden uzun süre alabilir, sıra karışabilir ekibin odağı dağılabilir. Bunu da çok gördüm. Hele birden fazla ekip aynı proje üzerinde çalışıyorsa ortak toplantılar 50-60 kişinin bir arada olduğunda daha da içinden çıkılmaz bir hâle gelebilir. Eğitimde “Bitti Tanımı”nın ortak belirleneceği söylenmişti. Biz 5-6 Scrum ekibi olarak Sprint Review toplantısını da ortak yapardık:

 — Bir saniye, ekran paylaşayıııım. Teknik bir arıza oldu arkadaşlar, yerime Alp göstersin, gibi
 — Ben başka branch’teyim şu an, şimdilik başkası göstersin, ben sonra göstereyim, gibi
 — Kod bende fazla karışık şu an, geri de dönemem, yerime Alp göstersin, gibi (Arkada toplantıyı takip etmeyip bir yandan iş yetiştirmeye çalışan son dakikacıların filtresidir bu cümleler. 😊)

Bu farklı sorunlarla uğraşmamak için Geliştiriciler, video çekmeye ve Sprint değerlendirme toplantısında bu videoları göstermeye başladılar. Daha iyi ve daha hızlı oldu aslında. Bu öneri bir Sprint Retrospective toplantısı esnasında geldi. Eh! Scrum sorun çözmek için var.

Daha önce çalıştığım bazı ekiplerde Sprint planlama toplantıları gereksiz uzun sürerdi. 4 saatlik toplantılarda herkesin enerjisi tükenir, kimse neyi planladığını hatırlamazdı. Sonunda işler eksik ya da yanlış planlanır, tüm işlerin vaktinde bitebildiği ve gelecek Sprint’e iş aktarılmayan verimli Sprintlere hasret kalırdık.

Öğrendiğim Ders: Scrum etkinlikleri birer “checklist” değil, ekip dinamiklerini iyileştirme ve sorunları çözme araçlarıdır. Günlük Scrum’da engellerin açıkça dile getirilmesi, retrospektiflerde ise somut aksiyon maddelerinin tanımlanması ve takip edilmesi ekip başarısını artırır. Ayrıca Sprint değerlendirme toplantılarının amacını doğru anlamak ve paydaşları sürece etkin bir şekilde dâhil etmek hem ürün kalitesini artırır hem de ekip motivasyonunu yükseltir.


3. Sprintlerin Mini Şelaleye (Waterfall) Dönüşmesi

Çalıştığım 2 şirkette Scrum uyguladığımızı düşünürdük ama Sprintler fark etmeden mini şelale süreçlerine dönüşürdü. İlk hafta analiz, ikinci hafta geliştirme, son hafta test yapılırdı. Sprint sonunda teslimata yetişemeyen işler ya sonraki Sprintlere taşınır ya da “ekstra Sprint” icat edilirdi. Bu yaklaşım Scrum’ın her sprintte potansiyel olarak dağıtılabilir bir ürün sunma hedefine tamamen aykırıydı. Üstelik, işler test edilmeden “Bitti Tanımı”na uyup uymadığına bakılmadan “tamamlandı” kabul edildiğinde teknik borçlar birikerek projeyi daha da karmaşık hâle getirirdi.

Bu sorun genellikle eski çalışma alışkanlıklarından, yanlış yönetim beklentilerinden, bağımlı olduğumuz başka ekiplerin süreçlerinden, araya alınan işlerden ve ekibin “Bitti Tanımı” gibi temel uygulamaları tam olarak benimsememesinden kaynaklanabiliyordu. Paralel süreçler yerine ardışık süreçler izlemek Sprintlerin gerçek anlamını yitirip bir teslim tarihine odaklanan proje yönetim modeline dönüşmesine yol açardı.

Öğrendiğim Dersler

  1. İlk yazıdan beri söylüyorum, dolayısıyla Scrum söylüyor: Sprint sonunda mutlaka tamamlanmış ve test edilmiş bir ürün sunmaya odaklanalım.

  2. Test, geliştirmenin bir parçasıdır; sonraya bırakılmamalıdır.

  3. Analiz, geliştirme ve test süreçlerini aynı anda yürütmek, Sprint hedeflerine ulaşmayı kolaylaştırabilir.

  4. Şelale eğilimlerini fark edip engellemek Scrum Master’ın sorumluluğudur.

  5. Bu eğilimlerin sebeplerini retrospektif toplantılarında ele alın ve iyileştirme yollarını birlikte belirleyin.


4. Definition of Done (Bitti Tanımı) Eksikliği

Çalıştığım pek çok şirkette “Bitti Tanımı” ya tamamen göz ardı edilir ya da öyle detaylı hazırlanırdı ki uygulanması neredeyse imkânsız hâle gelirdi. Bu durum, tamamlanmış gibi görünen işlerin aslında “tamamlanmamış” olmasına yol açardı. Örneğin, kod yazılır ama testleri yapılmazdı. Dokümantasyon ya hiç oluşturulmaz ya da müşteriye iletilecek seviyede olmazdı. Daha kötüsü, Sprint sonunda bir işin ne zaman gerçekten “bitti” kabul edileceği konusunda ekip içinde uzlaşmazlık yaşanırdı.

Bu eksiklik sadece ürün kalitesini değil, aynı zamanda ekip içi güveni de etkilerdi. Bir takım üyesi işini tamamladığını düşünürken bir diğeri aynı işi eksik olarak değerlendirirdi. Bu tür anlaşmazlıklar Sprint hedeflerine ulaşmayı zorlaştırır ve ekip motivasyonunu düşürürdü. Ayrıca test süreçlerinin ayrı bir aşamaya bırakılması teknik borçların birikmesine ve ürün kalitesinin düşmesine sebep olurdu.

Detaylı Bitti Tanımları ise başka bir tuzaktı. Çok fazla kriter belirlenmesi Geliştiricileri gereksiz bir yük altına sokar ve asıl işlere odaklanmayı zorlaştırırdı. Örneğin, bir modülün tamamlanması için gereken tüm test senaryolarının yazılması, her olası kullanıcı durumunun düşünülmesi istenirdi. Bu da Sprint hedeflerinin aşırı iddialı hâle gelmesine ve sürekli olarak tamamlanamamasına yol açardı.

Öğrendiğim Dersler:

  1. Net ve Gerçekçi Tanımlar Yapın: Definition of Done, ekibin uyabileceği kadar basit ve uygulanabilir olmalıdır.

  2. Test ve Dokümantasyonu Dâhil Edin: Testler ve gerekli dokümantasyon, tanımın olmazsa olmazlarıdır.

  3. Ekip Uzlaşısı Sağlayın: Tüm ekip üyeleri, bir işin “bitti” kabul edilmesi için gereken kriterlerde hemfikir olmalıdır.

  4. İyileştirme İçin Kullanın: Bitti Tanımı yalnızca bir kontrol listesi değil, ekip dinamiklerini iyileştirmek için bir araçtır.

  5. Retrospective Toplantılarına Dâhil Edin: Tanımın ne kadar işe yaradığını düzenli olarak değerlendirin ve gerekirse güncelleyin.


5. Paydaşların Süreçten Dışlanması

Çalıştığım pek çok şirkette Sprint Review toplantıları yalnızca ekip üyeleriyle sınırlı kalır, paydaşlar ise sürecin dışında bırakılırdı. Halbuki bu toplantılar, ürünün gelişim sürecini paylaşmak ve paydaşlardan geri bildirim almak için kritik bir fırsattır. Genellikle formalite gereği yapılan ya da paydaş katılımı sağlanamayan bu toplantılar, ürünün işlevselliğiyle ilgili önemli geri bildirimlerin alınmasını engellerdi. Sorunlar ancak ürün kullanıma alındıktan sonra fark edilir ve bu durum, işin geri alınarak düzeltilmesi veya baştan yapılması gibi zaman alıcı süreçlere yol açardı.

Lebib Yalkın Yayımları’nda yöneticimin teşvikiyle, geliştirdiğimiz şirket içi bir uygulamayı her Sprint Review toplantısında kullanıcılarımıza gösterip onların geri bildirimlerini topladık. Bu geri bildirimler sayesinde:

  • Ürünümüzü daha kullanıcı dostu ve taleplere uygun bir hâle getirdik.

  • Ekip içinde motivasyon arttı ve Geliştiriciler ürün üzerinde daha fazla sorumluluk hissetti.

  • Kullanıcılarla kurulan bağlar güçlendi, ürün geliştirme sürecinde onların sesini duymamızı sağladı.

  • Kullanıcının kullanım alışkanlıklarının değişim yönünü kullanıcıya önden göstermiş, test ettirmiş, hatta öğretmiş olduk.

  • Doğru ürünü geliştirdik ve gereksiz özelliklerden kaçındık.

  • Sonraki Sprintlerde işlerin önceliklendirilmesini daha doğru bir şekilde yaptık.

  • Kullanıcıların uygulamayla ilgili olası memnuniyetsizliklerini erkenden görüp hızlı aksiyon alma şansı yakaladık.

  • Paydaşların sürece düzenli katılımının ürün geliştirme sürecine ne kadar olumlu etkisi olduğunu bu proje ve Sprint Review toplantıları sayesinde daha net bir şekilde gördük.

Yazılım geliştirmede validation ve verification süreçlerinden validation, paydaşların doğrudan dâhil olduğu kritik bir aşamadır. Doğru ürünü üretip üretmediğimiz sorusu yazılımda çok ama çok kritiktir ve bu soruyu cevaplayabilecek olan kişiler paydaşlardır. Onların süreçten dışlanması, bu doğrulama adımını etkisiz hâle getirir ve ürünün kullanıcının beklentilerini karşılayamamasına neden olabilir. Üstelik geri bildirim eksikliği nedeniyle süreç uzar, kaynaklar boşa harcanır ve ekipte motivasyon kaybı yaşanabilir. Paydaşlarla düzenli etkileşim sağlamak bu sorunların önüne geçmek ve ürünün başarısını artırmak için olmazsa olmazdır.

Öğrendiğim Ders: Paydaşları Sprint Review gibi etkinliklere düzenli olarak dâhil etmek sadece ürün kalitesini artırmakla kalmaz, aynı zamanda sürecin her aşamasında güven inşa eder ve ekip motivasyonunu yükseltir. Paydaşların geribildirimlerini dikkate almak hem validation sürecini sağlamlaştırır hem de ekip çalışmasının gerçek değerini ortaya koyar.


6. İletişim Eksikliği ve Ego Sorunları

Çalıştığım bazı ekiplerde bireyler iş birliğinden çok bireysel başarıya odaklanırdı. Herkes kendi işini tamamlamakla meşgul olur ancak ekip içinde iletişim eksikliği nedeniyle işler bir bütün olarak tamamlanamazdı. Daha kötüsü, ekip üyeleri arasında yaşanan ego çatışmaları fikirlerin paylaşılmasını ve sorunların çözülmesini engellerdi. Bu durum hem ekip performansını düşürür hem de projelerin beklenen sürede tamamlanmasını zorlaştırırdı.

Ego sorunları genellikle ekip içinde liderlik eksikliği ya da yanlış yönlendirmelerle ortaya çıkardı. Bazı ekip üyeleri sorunlarını gizler ya da işin tamamlandığını varsayıp eksiklerini paylaşmazdı. Bu gizlilik kültürü hem süreçte hem de ekip üyeleri arasında güvensizlik yaratırdı. Bir Scrum ekibi ancak birbirine güvenerek ve açık iletişim kurarak başarılı olabilirken bu tür bir atmosferde ekip başarısızlığa, sorunlu ve gergin bir çalışma ortamına mahkûm olurdu.

İletişim eksikliği yalnızca ekibin performansını değil, aynı zamanda ürün kalitesini de etkilerdi. Sorunların erken tespit edilememesi hataların büyüyerek projeyi çıkmaza sürüklemesine yol açardı. Bu tür sorunlar yalnızca iletişimi artırarak ve ekip içi güveni inşa ederek çözülebilir.

Öğrendiğim Ders:

  1. Açık İletişimi Teşvik Edin: Herkesin fikirlerini özgürce paylaşabileceği bir ortam yaratın.

  2. Sorunları Gizlemeyin: Ekip üyeleri, yaşadıkları sorunları saklamadan paylaşabilmelidir.

  3. Ego Çatışmalarını Yönetin: Ego savaşlarını önlemek için ekip dinamiklerini sürekli izleyin ve gerektiğinde müdahale edin.

  4. Güven ve İş Birliği Kültürü: Ekip içinde güven ve iş birliğine dayalı bir kültür oluşturun çünkü başarılı bir Scrum Ekibinin temeli budur.


7. Gerçekçi Sprint Hedeflerinin Belirlenmemesi

Çalıştığım neredeyse tüm şirketlerde Sprint planlama toplantısında yapılan çok hata gördüm. Bunlardan bazılarını sıralayayım:

  • Sprint içinde alınacak izinler sorulmadan planlamaya başlanırsa bazı işlerin yarım kalması kaçınılmazdır. Önceden ekibe planladığı bir izin olup olmadığı mutlaka sorulmalıdır. Ani ihtiyaçlar, sağlık problemleri olduysa yıkılsın iş de şirket de Scrum da. İzninizi haber verin ve işinizi yapın.

  • İnsanların kapasitesi göz önünde bulundurulmadan aşırı iddialı hedefler belirlenirdi. Bu durum Sprint sonunda tamamlanmayan, bir sonraki Sprint’e aktarılan işler ve düşük ekip motivasyonu olarak geri dönerdi.

  • Özellikle sektörde yeni (junior) Geliştiricilerin işleri tam anlamadan süre tahmini yapması yüzünden işlerin yarım kalması ve tahmin edilenden çok daha uzun sürmesi, defalarca karşılaştığım, bizzat da yaptığım bir şeydir.

  • Sprint hedefleri belirlenirken diğer ekiplerden gelen bağımlılıklar veya üçüncü taraflarla olan entegrasyon süreçleri hesaba katılmazsa işler gecikebilir. Planlama sırasında bu tür bağımlılıklar mutlaka dikkate alınmalı ve buna göre bir iş akışı oluşturulmalıdır.

  • Bazı ekiplerde işler adil bir şekilde dağıtılmaz ve birkaç kişi aşırı yük altına girerken diğerleri daha az iş üstlenir. Bu durum hem ekip içindeki dengeyi bozar hem de bireysel performansları etkiler. İş yükü, ekip üyelerinin yetkinlikleri ve kapasiteleri göz önünde bulundurularak dengeli bir şekilde dağıtılmalıdır.


8. Teknik Borçların Göz Ardı Edilmesi

Çalıştığım birkaç şirkette teknik borçlar genellikle kısa vadeli hedeflerin ve teslim tarihleri baskısının gölgesinde bırakılırdı. Bu durum ilerleyen aşamalarda kodun karmaşıklaşmasına, projelerin daha zor yönetilmesine ve hataların artmasına neden olurdu. Teknik borçlar birikince yeni özelliklerin geliştirilmesi daha yavaş ve maliyetli hâle gelirdi. Üstelik bu durum ekip içinde motivasyon kaybına ve sık sık “yama yapma” kültürüne yol açardı.

Teknik borçları görmezden gelmek uzun vadede ürünün kalitesini ve ekibin verimliliğini düşürür. Bu borçları Sprint planlama ve retrospektif toplantılarında gündeme alarak düzenli olarak yavaş yavaş da olsa temizlemek hem ekip motivasyonunu artırır hem de projeyi sürdürülebilir kılar.

Öğrendiğim Dersler:

  • Teknik borçları düzenli olarak Sprint hedeflerine dâhil edin. Bu, borçların birikmesini önler ve uzun vadede projeyi sağlıklı tutar.

  • Teknik borçların kökenine inmek için retrospektiflerde bu konuyu gündeme getirin. Örneğin, sık tekrar eden bir hata varsa temel sebebi bulup çözüm üretmek için aksiyon alın.

  • Kod incelemeleri ve otomatik test süreçleriyle teknik borçları erken fark edin. Kodlama standartları belirleyerek ekip içi uyumu artırın.

  • Yeni özellikler eklerken sadece kısa vadeli kazanımları değil, kodun sürdürülebilirliğini de göz önünde bulundurun.

  • Borçların takip edileceği bir araç veya liste oluşturun. Bu listeyi düzenli olarak gözden geçirip kritik olanları önceliklendirin.


Sonuç: Gelecek Sprintler İçin Derslerle Doluyuz

Bu yazı dizisiyle, PSM I sertifikası yolculuğumda edindiğim deneyimleri, öğrendiğim dersleri ve karşılaştığım zorlukları paylaşmaya çalıştım. Scrum’ın temel prensipleri kadar pratik uygulamalarında yapılan hataların ve bu hatalardan çıkarılan derslerin de ne kadar kıymetli olduğunu gördüm.

Scrum sadece bir yöntem değil, ekip dinamiklerini iyileştiren, iletişimi artıran ve değer odaklı bir çalışma kültürü yaratan bir çerçeve. Ancak bu çerçeveyi doğru anlamak ve uygulamak uzun vadeli başarı için kritik. Yazılar boyunca sıkça vurguladığım gibi:

  • Rollerin sınırlarını net çizmek kaosu önler ve ekiplerin güvenini artırır.

  • Etkinliklerin formaliteye dönüşmesini engelleyip sürekli iyileştirme kültürünü desteklemek verimliliği artırır.

  • Sprint hedeflerini gerçekçi belirlemek ekibin sürdürülebilir bir hızda çalışmasını sağlar.

  • Teknik borçları göz ardı etmeyip düzenli olarak temizlemek hem ekip motivasyonunu hem de ürün kalitesini korur.

  • Paydaşları sürece dâhil etmek doğru ürün geliştirme yolunda önemli bir adımdır.

Her zorluk, yeni bir ders ve gelişim fırsatı anlamına gelir. Scrum uygulamalarında karşılaştığınız zorluklara çözüm üretmek ekip kültürünüzü zenginleştirecek ve iş süreçlerinizi daha verimli hâle getirecektir.

Bu arada, noldu? Bu yazıda şirket ismi verip gömmemi bekliyordunuz değil mi? Tabii ki yapmayacağım! 😄 İş dünyasında her şirketin kendine özgü dinamikleri ve zorlukları var. Bu yazının amacı, isimlerden çok süreçleri ve alınabilecek dersleri ön plana çıkarmak. Hatalardan ders alarak ilerlemek hem ekipler hem de bireysel kariyer için gerçek başarıyı getirir.

Her Sprintte bir önceki Sprintten öğrendiğimiz derslerle daha iyiye gitmek dileğiyle.

Teşekkürler ve iyi Sprintler! 🚀