Kafamda Deli Sorular: Scrum Master

Scrum Master’lar hayatımıza girdiğinden beri herkesin kafasında bu rolün ne yaptığına dair sorular dolaşıyor. Bugüne kadarki tecrübeme dayanarak Scrum Master rolünü “anlaşılması en zor rol” ilan ediyorum. Sadece anlaşılması da değil, kabullenilmesi ve içselleştirilmesi de oldukça zor oldu ve olmaya devam ediyor.

Bu yazı dizisine başlamamamın en büyük tetikleyicisi Scrum Master için bana gelen sorular oldu.

Vee karşınızda Scrum Master’ın ve bu role “maruz” kalanların kafalarındaki deli sorular.

Scrum Master Deli Soruları

Scrum Master takımdaki en tecrübeli kişi mi olmalı?

Scrum Master rolü bir terfi veya rütbe atlamak olarak görülmemelidir. Her rol için tecrübe ve deneyim önemlidir tabii ki ama bu Scrum Master’ın takımdaki en kıdemli veya tecrübeli kişi olmasına zorunluluk getirmez.  

Öncelikle gönüllü olmak esastır. Bu iş zorunluluktan veya sırf yapmış olmak için yapılmaz. Takımı Shu seviyesinden Ha seviyesine çıkarmayı hedeflemek kolay bir yolculuk değildir. Bu yüzden gönüllülük esastır. 🤗

Takımdan bir Scrum Master seçiliyorsa, iletişimi güçlü, araştırmaya hevesli, konfor alanından çıkmayı dert etmeyen (hatta gelişim adımı gören)  kişilerin seçilmesi iyi bir pratik olacaktır.

Takım Scrum’ı çok iyi öğrendi ve uyguluyor. Artık bana gerek yok!

Çok sevdiğim bir söz var: “En iyi Scrum Master, görünmez Scrum Master’dır.” Bu söz aslında sorunun cevabını veriyor ama ben biraz daha açıklamak istiyorum.

Bir Scrum Master’ın amacı, hizmet ettiği takımda ve organizasyonda çevik hareketlerin bir kültür haline gelmesini sağlamaktır. Bunun sağlandığı ortamlarda Scrum Master görünmez hale gelir. Çevik hareketler herkesçe bir refleks olmuştur.

Tamam kültür haline getirdik. Peki değişim duruyor mu? Hayır. Tam da bu sebepten görünmez de olsa her türlü dönüşüme destek olacak ve yol gösterecek gerçek liderlere yani Scrum Master’lara her zaman ihtiyaç olacaktır.

Takım Scrum’dan Kanban’a geçti. Artık bana gerek yok!

Merhaba Kanban ve beraberinde getirdiği 14523inci soru. 🤪 Yanlış anlaşılmasın Kanban’ı kötülemedim. Kanban’ı içselleştirmek Scrum Master rolünü içselleştirmekten çok daha zor demek istiyorum. Bu konuyu ayrıca bir konuşuruz.

Takım olgunlaştıkça kendi pratiklerini üretmeye başlar. Bu yaratıcılık ve üretkenlik takımın çevikliği kültür haline getirmeye başladığının sinyalleridir. Takımın bu pragmatik yaklaşımı bazı Kanban pratiklerini de içerebilir. Zira Kanban tam da bu pragmatik ortamda yaşar. ❤️

Peki takım artık Kanban uygulamaya başladığında Scrum Master rolü ne olacak? Kanban Master mı olacak? – en çok gelen soru 😉

Ben kalıplara sıkışmaktan pek hoşlanmayan biriyim. Kendi çizgilerimi kendim belirlemek isterim. Takımın ihtiyacı olan, motivasyonu yükselten/düşürmeyen neyse ona göre ilerlemek doğru bence. Örneklerle gidelim. Takım Kanban uyguladığı için Scrum Master’a artık Kanban Master diyebilir. Bunda bir problem görmüyorum. Takım Scrum Master rolünün sorumluluklarını kendi içinde paylaşabilir. Bu da çok okey. Ama unutmayın takımın her zaman bir SM veya bu rolün sorumluluklarını yerine getirecek bir oluşuma ihtiyacı olacaktır.  Takımınızda bu nasıl çalışacaksa o şekilde bir ortam yaratın.

Peki bu esnemeleri sadece Kanban’da mı yapabiliriz? Scrum koşan takımlar esneyemez mi? Scrum Guide 2020 ile bence o esnekliği verdi. Daha önceden de esnekti zaten ama artık kılavuzda daha net belirtiyor. İşi nasıl yapacağımızı bize bırakıyor.

Hem Scrum Master hem Developer olabilir miyim?

Evet olabilir. Zaten ülkemizde en çok karşılaştığımız senaryo da bu yönde. Takımdaki sosyal yönü daha belirgin ve bu işe hevesli olan bir developer’ı aynı zamanda o takımın Scrum Master ‘ı olarak seçebiliriz.

Bir kişide farklı şapkaların olması, Scrum değerlerinden “odaklık” konusuna pas atan bir konudur. Aşağıda dedike Scrum Master’ı anlatırken bu konuyu açacağım.

Hem Scrum Master hem Product Owner olabilir miyim?

Kısa ve net olacağım. Bir kişi aynı takımda hem Scrum Master, hem Product Owner olmamalı.

Product Owner’ın istekleri, takım içindeki davranışları veya kararları çeviklikten uzaklaştığında bayrak kaldıracak bir Scrum Master olmalı. Eğer aynı kişi her iki rolde olursa çevikliğin manipüle edilme riski ortaya çıkar. Bu bir risktir. Takımca bu riski almamanız gerekir.

Hangisi daha iyi? Dedike Scrum Master vs Takımın içinden Scrum Master

Öncelikle oyumu dedike Scrum Master’dan yana olarak kullanıyorum.

Peki neden etrafımıza baktığımızda oldukça az sayıda dedike SM görüyoruz?  Bunun en baştaki sebebi organizasyonların henüz böyle bir role hazır olmaması diye düşünüyorum. Henüz bu role bütçe ayırmayı düşünmüyorlar.

Bana göre dedike veya takımın içinden olmasının farklı avantaj ve dezavantajları var. Hadi birazcık karşılaştırma yapalım.

Dedike SM avantajı kesinlikle odaklı çalışabilmesidir. Bir işe ne kadar odaklı yaklaşırsan o kadar kaliteli iş çıkar. Eforunu tamamen bu rolde gösteren bir SM daha hızlı gelişim adımları gösterecek, hedefine daha kolay ulaşacaktır.

Dedike SM’ler organizasyonlarda birden fazla takıma destek verebiliyor. Bu da bazı dezavantajlar doğuruyor. Takımın içinden görülmeyip dışarıdan gelen bir denetçi olarak algılanabiliyor. Bu da takımın SM’e karşı açıklığı kaybetmesine yol açabiliyor. Bu durum bir SM için en kötü durumdur. O yüzden dedike SM avantajlarının olmasına rağmen bir anda  bombaya dönüşebilir. Aman dikkat.

Scrum’da Agile koç yok. Ben Agile koç muyum?

Çok haklı ve yerinde bir soru bence. Kafa karıştırıcı bir durum olduğunu kabul ediyorum. Hadi birlikte cevaplamaya çalışalım.

Scrum’da “Scrum Master” olarak bir rol var ve bu rol Scrum Takımı içerisinde konumlanmış. Hem takıma, hem Product Owner ve paydaşlara, hem de organizasyona karşı sorumluluklar bu rol üstünde toplanmış.

Bir organizasyonda birden fazla SM olabilir. Bu durumda hangi SM organizasyona hizmet etmekte görevli? Hepsi mi?

Her SM organizasyona hizmet etmekten sorumludur. Tabi bunu yapış şekli her organizasyona göre değişir. En çok karşılaştığımız yöntem, tüm SM’lerin oluşturduğu bir COP (Community of Practice) kurmak oluyor. Yani organizasyona hizmet etmek için bir sanal takım kurarak hem kendi yetkinliklerini geliştiriyorlar hem de organizasyona nasıl hizmet edebilirler ortak kararlar alıyorlar.

Peki COP nasıl çalışır? COP öncelikle çok etkin bir paylaşım ortamıdır. Organizasyondaki SM’ler belli bir düzende bir araya gelirler. Birbirlerine takımlarda uyguladıkları pratikleri anlatırlar. Takımlarda çözemedikleri sorunları buraya taşırlar ve birlikte çözüm bulmaya çalışırlar. Böylece organizasyondaki takımlara hizmet eden tüm SM’ler hem kendilerini hem de takımlarını çok daha hızlı olgunlaştırırlar. Bu da dolaylı da olsa organizasyona hizmettir. Sadece bu değil tabii ki. Hayal gücünüzü geniş tutun. Eğitimler hazırlayabilirler, organizasyon çapında etkinlikler düzenleyebilirler (Çevik konseptli), farklı pratikleri araştırıp birbirlerine anlatabilirler, medium blog tutabilirler, kitap okuma challege’ları yapabilirler. Ve daha neler neler.

Benim de içinde bulunduğum SM-COP’nin yaptığı birkaç etkinliği de buradan sizlerle paylaşmak isterim. Dedim ya hayal gücünüzü geniş tutun.

Medium.com adresinde görüntüleyin

COP’de dikkat edilmesi gereken bir durum var, o da “Gizlilik”. Bu görüşmelerde konuşulanlar, dedikodu amaçlı değil, çözüm bulma amaçlı olmalı ve orada konuşulan orada kalmalıdır. Mümkün olduğunca olayı anonimleştirmeli, yaşanılan sıkıntılar kişiselleştirilmeden paylaşılmalıdır. Yoksa COP kurulma amacından sapar. Takımların kendi SM’lerine olan güveni sarsılır. Aman Allah korusun.

Scrum Guide, bir Scrum takımı maksimum 10 kişi olmalı diyor. Ama benim takımım 12 kişi.

Scrum, takımdaki iletişimin güçlü kalabilmesi için kişi sınırlaması koyar. Bu sınırı aştığımızda iletişim kanalları artacağından, reflekslerde yavaşlama meydana gelebilir. Bu takımın çevik kalabilmesinde bir risktir ve Scrum riskleri hiç sevmez.

Scrum, “Bu çerçevenin dışına çıkarsan Scrum’ın yararlarını azaltır, faydasından uzaklaşırsın.” der. Peki 12 kişilik takımı sırf Scrum dedi diye de 10 kişiye düşürmek mi gerekir? 🧐 Hani demiştim ya kendi üstünüze uyan pratikleri giyin diye, yine aynı şeyi diyeceğim. Esneme payı bırakın kendinize. Ama şunu da unutmayın kişi sayınız arttıkça iletişim gücünüzün de o kadar azalma olasılığı var. Bunun farkında olun, önemler alın, kontrol mekanizmaları oluşturun.

Takımdaki bir kişi çok uyumsuz. Bu bir impediment midir? Remove etmeli miyim?

Bana en çok sorulan sorulardan biri de şaşırtıcı olacaktır belki ama bu soru oluyor. O yüzden buradan da bir açıklama getirmek istedim.

Öncelikle hepimiz birer insanız. Bu yüzden de takım arkadaşımızı bir “impediment” olarak görmek doğru olmayacaktır. 😉

“Ama ama ama çok uyumsuz bir vaka ile karşı karışayım!”
“Takımın motivasyonu düşüyor.”
“Herkes aynı şekilde o kişinin uyumsuz olduğunu düşünüyor.”

Bir Scrum Master olarak bayrak kaldırmak bizim işimiz. Öncelikle durumu takımca konuşabileceğiniz güvenli bir ortam yaratmanız oldukça kritik. Karşılıklı yapıcı geri bildirimlerle ufak ufak ilerleme katedersiniz. Bu ortamlarda birbirinizi anlamaya çalışmalısınız.

Bir diğer önerim de David Rock’ın SCARF Modeli’ne göre takım üyelerinin motivasyon kaynakalarını keşfetmeye çalışmanız. Özellikle uyumsuz olarak tanımladığınız kişilerin nelerden motive olduğunu öğrenebilirseniz ona göre yaklaşır, ortak bir noktada buluşmaya zemin hazırlarsınız.

Yani sorunun cevabı “remove” etmeyin, “kazanmaya” çalışın. 👍

İlkim Dilara KADAKALOĞLU
d.