PSM I Sertifikasını Nasıl Kazandım #2: Aldığımız Eğitim ve Eğitmenimizin Kitapları

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 ikinci yazısından merhaba. Beklemediğim şekilde eğlenceli olan ilk yazıya ve diğer Scrum yazılarıma aşağıdan ulaşabilirsiniz.

Scrum Eğitiminden Alınan Dersler: Teoriden Pratiğe

Katıldığım 15 saatlik bu eğitim, ACM Agile tarafından hazırlanmıştı ve teorik bilgilerle pratiği harmanlayan keyifli bir eğitimdi. Scrum’a dair birçok temel konu ele alındı; ancak bunlar sadece yüzeysel bir bilgi aktarımından ibaret değildi. Eğitim, gerçek hayatta karşılaşılabilecek problemlerle başa çıkabilmek için gereken araçları ve yöntemleri öğretmeye odaklanmıştı.

Şirketim Lebib Yalkın Yayımlarından benimle birlikte toplam dört kişi, başka bir şirketten de iki kişi olmak üzere toplam altı katılımcıydık. Üçer kişilik iki gruba ayrıldık ve iki gün boyunca eğitmenimizin istediği örnek bir proje üzerinde yirmişer dakikalık sprintlerle çalışarak Scrum’ı canlı canlı deneyimledik. Eğitmenimiz, bu örnek çalışma ve sprint sonlarındaki geri bildirimleriyle Scrum’ı daha da içselleştirmemizi sağladı. Ayrıca cama yapışkanlı kağıtlarla oluşturduğu bir Scrum tahtasında (Scrum Board) eğitim sürecini sürekli ilerletti. Eğitimin başında tüm kâğıtlar TODO listesindeyken sonunda hepsi DONE kolonu altına yapışmıştı. Eh, uygulamalı eğitimden daha güzeli var mı?

İlk Gün: Scrum’ın Felsefesi ve Tilki Macerası

Eğitimin ilk günü, Scrum’ın felsefesine ve ekip içindeki rollere dair bir farkındalık yaratmakla başladı. Scrum’ın ne olduğunu, Agile şemsiyesi altında nasıl konumlandığını ve azıcık da tarihini öğrendik. Özellikle Scrum Master’ın liderlik rolü üzerinde uzun uzun duruldu. Geleneksel bir proje yöneticisi gibi davranmanın neden yanlış olduğu, Scrum Master’ın asıl sorumluluklarının ekip içindeki iletişim ve süreçleri iyileştirmek olduğu anlatıldı.

Product Owner’ın müşteri ihtiyaçlarını anlamadaki kritik önemi beni oldukça etkiledi. Özellikle Product Backlog yönetiminin nasıl yapılması gerektiğini ve önceliklendirme hatalarının projelere nasıl zarar verebileceğini daha iyi anladım. Aklımda ise büyük şirketlerde birden fazla Scrum takımının aynı proje üzerinde çalışmasıyla alakalı sorular dolaşıp duruyordu. Örneğin birden fazla Product Owner’ın aynı Product Backlog’u yönettiği durumlarla karşılaşmıştım. Bu süreçlerin nasıl daha doğru yönetilebileceğine dair sorularım vardı.

İlk gün, ayrıldığımız gruplarla yaptığımız 20 dakikalık uygulamalı bir sprintte bir senaryo üzerinde çalıştık. Gruplara yaklaşık on beşer kâğıt verildi. Her bir kâğıtta bir PBI ve kabul kriterleri (acceptance criteria) vardı. Çocukların hayvanları tanımaları için birer web sitesi hazırlayacaktık. Grubumuz tilkiyi, diğer grup ise garip bir tür kediyi seçmişti. Hemen kâğıtları alıp harıl harıl çalışmaya başladık. Ekibimizin başarılı yıldız yazılımcısı Barış, hemen sitemizi geliştirmeye başladı. Birkaç dakika içerisinde ana sayfa, resim galerisi ve hakkında sayfalarının bir kısmı hazırdı bile…

Ancak bir hata yapmıştık. Scrum’da müşteriyle iletişimin ne kadar önemli olduğunu göz ardı etmiştik. Ne diğer grup ne de biz müşteriye bir şey sormuştuk. Bu da yaptığımız işlerin neden “tamamlanmamış” kaldığını açıkça ortaya koydu. İletişimin süreçteki belirleyici rolünü de böylece daha iyi kavradık. Kullanıcı ya da müşteriyle süreçler hakkında şeffaf olmak ve ekip içinde doğru bir görev paylaşımı yapmak gerekiyordu. Biz ise doğrudan işe dalarak bunları ihmal etmiştik.

Bu hatamız sayesinde üç farklı işe birden başlayıp hiçbirini tamamen bitirememenin gerçek bir başarı olmadığını, her sprintte “bitti” diyebileceğimiz yüzde yüz tamamlanmış işlerin yer alması gerektiğini bizzat deneyimleyerek öğrendik. Scrum sadece üretmek değil, doğru önceliklendirme ve tamamlama üzerine kuruludur.

İkinci Gün: Everest Tırmanışı ve Gerçekçi “Bitti" Tanımları

İkinci gün özellikle Sprint Planlama, Günlük Scrum ve Sprint Retrospective gibi etkinliklerin doğru bir şekilde nasıl yürütüleceğine dair interaktif çalışmalar yaptık. Daha önce Retrospective toplantılarının formaliteye dönüşmesine, hatta “unutulmasına” şahit olmuştum. Ancak eğitmenimiz, bu toplantıların sadece bir “neyi iyi yaptık, neyi kötü yaptık” toplantısı olmadığını, ekibin kendi çalışma biçimini geliştirmek için bir araç olduğunu sık sık vurguladı.

Önceki gün oluşturduğumuz gruplarla, bahsettiğim senaryo üzerinden “Bitti Tanımı” (Definition of Done) üzerinde çalıştık. Bu süreçte yine bir hata yaptık. Bitti Tanımı’nı oluştururken listeye her şeyi ekleyip yapılacakları Everest Dağı’na çevirmiştik. Eğitmenimizin şu cümlesi hâlâ aklımda:

Scrum, ekipleri Everest’e tırmandırmaz. Amacımız, küçük ama sağlam adımlarla siste önümüzü gördükçe sürekli ilerlemek ve yanlış yöne gittiğimizi anlayınca yön değiştirmek.

Uzun lafın kısası, Bitti Tanımı’na çok fazla madde eklemek, geliştiricileri gereksiz yere zorlayabilir ve Increment’i ya da Sprint Hedefi’ni riske atabilir. Ancak çok az madde belirlemek de yazılımda açıklar bırakabilir ve testlerde daha fazla olumsuz geri dönüşle karşılaşmamıza neden olabilir. Bu dengeyi bulmak için ekip olarak tartıştık ve gerçekçi, uygulanabilir bir “Bitti Tanımı” oluşturmayı öğrendik.

Bitti Tanımı hem geliştiricileri çok fazla zorlamamalı hem de ürünün kalitesini garanti altına almalıdır.

Günlük Scrum’ın bir durum raporu toplantısı olmadığını; ekibin ilerleyişini gözden geçirmeyi, takıldığı noktaları görünür kılmayı ve çözüm için koordinasyon sağlamayı amaçladığını öğrendik. Bu toplantıların asıl amacı, ekip üyelerinin yalnızca ilerleme durumlarını paylaşması değil, Sprint Hedefi doğrultusunda iş birliğini artırarak engellerin çözümünü hızlandırmaktır. Eğitim sırasında, her ekip üyesinin sadece kendi görevini anlatmak yerine ekip hedefleri doğrultusunda ortak bir iletişim zemini oluşturması gerektiğini daha iyi kavradım. Bu farkındalık, Günlük Scrum toplantılarını daha verimli hale getirmenin yollarını anlamamı sağladı.

Eğitimin son kısmında eğitmenimiz, oldukça samimi bir şekilde, Scrum çerçevesinin dışında kalan ama ekipler arasında sıkça kullanılan bazı pratiklerden ağzında çamur varmış gibi bahsetti. Story Point, Velocity ve Scrum Poker gibi uygulamaların Scrum Guide’da yer almadığını ancak ekipler tarafından efor tahmini veya iş takibi için yaygın bir şekilde kullanıldığını açıkladı. Bu araçların mümkünse kullanılmaması gerektiğini; metriklere ve tahminlere aşırı odaklanıldığında ekiplerin asıl amacı olan değer üretiminden uzaklaşabileceğini, ille bir ölçüt gerekiyorsa işlere (PBI, Task) sadece zaman tahmini verilebileceğini vurguladı.

Ayrıca Sprint Planlama toplantılarının Scrum Kılavuzu’nda belirtilen süre sınırını aşmasının üretkenliği ve ekip motivasyonunu olumsuz etkileyebileceğini vurguladı. Bu tür toplantıların tüm detayları belirlemek yerine Sprint Hedefi’ni netleştirmek için kullanılmasının önemini anlattı. Eğitmenimiz, Scrum’ın yalnızca araçlardan ibaret olmadığını, ekiplerin esnekliklerini ve iletişimlerini güçlendirmesi gerektiğini bir kez daha hatırlattı.

Bununla birlikte, bazı ekiplerde Scrum’ın temel bileşenlerinden olan etkinliklerin, eserlerin ya da rollerin “Bizim şirkete uymaz.” denilerek iptal edilmesinin ya da değiştirilmesinin büyük bir hata olduğunu da vurguladı. Örneğin, retrospektif toplantıların zaman kaybı olarak görülüp yapılmamasının ekibin süreçlerini geliştirme şansını tamamen ortadan kaldırdığını söyledi.

Aynı şekilde, Product Backlog’un net bir şekilde tanımlanmamasının ya da Sprint Hedeflerinin belirsiz bırakılmasının, Scrum’ın sağladığı değer üretim döngüsünü ciddi şekilde sekteye uğratacağını da belirtti.

Bu açıklamalar, bizlere Scrum’ın temel kurallarına bağlı kalmanın neden bu kadar kritik olduğunu ve asıl başarının bu kuralları doğru bir şekilde uygulamakla geldiğini açıkça gösterdi.

Eğitimde Dikkatimi Çeken Noktalar

• İş Birliğinin Önemi: Scrum çerçevesini yalnızca bir araç olarak görmek bir yanılgıdır. İş birliği Scrum’ın kalbindedir; şeffaflık ve iletişim, ekiplerin başarıya ulaşmasında kritik bir rol oynar.

• Yanlış Anlaşılan Kavramlar: Scrum’ın sıklıkla yanlış anlaşılan yönlerine de değinildi. Örneğin, sprintlerin küçük birer Şelale modeli uygulamasınadönüştürülmesi veya Günlük Scrum toplantılarının raporlama seanslarına dönüşmesi gibi hatalar üzerinde duruldu.

• Gerçek Hayat Senaryoları: Eğitmen, isim vermeden geçmiş deneyimlerinden örnekler sunarak Scrum’ın pratikte nasıl doğru uygulanabileceğini daha net bir şekilde anlattı.

• Scrum’ın Esnekliği ve Uygulama Çeşitliliği: Eğitim, Scrum’ın her ekibe ve projeye göre esnetilebilir bir çerçeve sunduğunu açıkça gösterdi. Ancak bu esnekliğin, kuralları tamamen yok saymak anlamına gelmediği de belirtildi. Scrum Kılavuzu’nda yer alan bileşenlerin ve ilkelerin dikkatlice uygulanması gerektiği vurgulandı.

• Takım Dinamiklerinin Önemi: Eğitim sırasında takım içindeki dinamiklerin, özellikle güven ve açık iletişim kültürünün, bir projenin başarısı üzerindeki etkisini daha iyi anladım. Örneğin, retrospektif toplantılarda herkesin eşit bir şekilde konuşmasına olanak tanıyan bir ortam oluşturmanın ekip performansını artırabileceği üzerinde duruldu.

• Araçların Amacı: Story Point, Velocity ve Burndown Chart gibi popüler araçların yalnızca birer yardımcı olduğunu, temel odak noktasının iş birliği ve değer yaratma olduğunu öğrendim. Eğitim, araçların yanlış kullanımının ekibi hedeflerinden uzaklaştırabileceğini net bir şekilde ortaya koydu.

• Scrum’ın Psikolojik Boyutu: Eğitimde, Scrum’ın sadece süreçlere değil, ekiplerin psikolojik olarak daha iyi hissetmesine de katkı sağladığını fark ettim. Özellikle, ekiplerin kendi işlerini yönetme özgürlüğüne sahip olmalarının ve yaptıkları işten gurur duymalarının performansı artıran önemli unsurlar olduğu belirtildi. %100 tamamlanmış ve müşterinin kullanımına hazır ürün parçaları teslim etmenin, ürünün bazı özelliklerine “Bitti.” diyerek kafamızda bir tik atmanın aslında bizlere psikolojik olarak iyi geldiğine de değinildi.

• Önyargılar ve Yanlış Varsayımlar: “Bizim şirkete uymaz” gibi düşüncelerin Scrum’ın ruhuna aykırı olduğu sık sık vurgulandı. Eğitim, Scrum’ın her sektöre ve projeye adapte edilebilecek kadar esnek olduğunu ve genellikle bu tür varsayımların ekiplerin gelişim fırsatlarını engelleyebileceğini gösterdi. Şaşıracaksınız ancak dünyada araba üretimi dâhil çok farklı sektörlerde bile Scrum uygulandığını görebilirsiniz.

Eğitimden Alınan En Büyük Ders

Eğitim, Scrum’ın bir çerçeve olmanın ötesinde bir zihniyet değişikliği olduğunu anlamamı sağladı. İletişim, şeffaflık ve sürekli iyileştirme kültürünü benimsemek, yalnızca projelerin değil, ekiplerin de uzun vadeli başarısında kritik rol oynuyor.

“15 saatte bu kadar şeyi nasıl anladın?” diye soracak olanlar varsa bir Scrum eğitimi almalarını tavsiye ederim. 😊

Eğitmenimizin Kitapları

Eğitime başlarken masamızda bulunanların fotoğrafını keşke çekseydim. Hediyeleri bir görseydiniz!

1. Bir yumuşak tatlı, stres topu,

2. Güzel, çizgili bir defter,

3. Bilgisayarınızı süslemeye hazır, tatlı ve artist Çevik (Agile) temalı stickerlar,

4. Tutuşu yumuşak, yazdıkça yazasınızı getiren çok güzel bir tükenmez kalem,

5. Oyun hamuru (Evet, yanlış okumadınız: oyun hamuru. Herkesin bildiği marka hem de.),

6. Çay ve siyah Moccamaster’da demlenmiş filtre kahve (iş birliği değildir). Ne yazık ki kahve ekşi Etiyopya çekirdeklerindendi.🙄 Bir sabah erken gidip ekibimin ve eğitim şirketinin fakir bünyesine güzel bir Sumatra kahvesi enjekte etmek geçti aklımdan ama ne yazık ki o kadar erken kalkamadım.

7. Sabah için pastane atıştırmalıkları,

8. Yapışkan not kâğıtları,

9. Ve tabii ki yazımın bu bölümünün asıl konusu: eğitmenimiz Mehmet Bey’in kitapları.

1. Scrum: Bir Dönüşüm Hikâyesi

Mehmet Yitmen’in bu kitabı, Scrum’ı uygulamaya başlamak isteyenler için âdeta bir rehber niteliğinde. Kitap, hayali bir kurumsal şirketin Scrum ile tanışmasını ve yaşadığı dönüşüm sürecini hikâyeleştirerek güzel bir şekilde anlatıyor. Hikâye boyunca Scrum uygulamalarında karşılaşılabilecek engeller, bu engellerin kökenleri ve çözüm yolları ele alınıyor.

Kitap, bu hayalî kurumsal şirketin Şelale modeliyle yönetilen projelerinin efor hesaplamalarında öngörülenden daha geç tamamlandığı, yazılımcıların çok fazla mesai yapmasına rağmen projelerin gittikçe daha eksik teslim edildiği, teslim edilen işlerin de iş biriminin isteklerini karşılayaadığı, kimsenin mutlu olmadığı toksik ve kötü bir ortamı anlatarak başlıyor. PMO’dan Hakan, yazılım ekibinden Kenan’ı bir iş hakkında darlamaya geliyor ve normalde arkadaş oldukları hâlde Kenan, Hakan’ın yüzüne bile bakmadan meşgul olduğunu söylüyor. Hakan aslında şirketin yanlış yolda olduğunun farkında aslında ve Kenan’a kızmıyor. Daha güzel bir proje yönetim modeli olup olmadığını araştırıyor ve Scrum ile karşılaşıyor.

Asıl hikâye buradan başlıyor. Hakan, Scrum’ı araştırdıkça araştırıyor. Önce yöneticisiyle, sonra yazılım ekibiyle konuşmaya gidiyor. Yazılım ekibi de Scrum’ı denemek istediklerini söylüyor ve Hakan’ın bir ekip kurma teklifini canıgönülden kabul ediyor. Sonra iş birimini ikna etmek kalıyor. Başta anlaşmakta zorlanıyorlar ama sonunda iş biriminden de bir Product Owner alıyorlar. Başta Scrum’a en uzak davranan ekip iş birimiyken üretilen şirket içi raporlama yazılımını ilk kullanmak isteyen birim de yine iş birimi oluyor. Tabii ki bir Medium yazısında kitabın hepsini anlatamam. Alınız, okuyunuz; tavsiye ederim.😊

Bu kitabın en etkileyici yanı, teorik bilgiler yerine pratik sorunlara ve bunların çözüm yollarına odaklanması. Eğitimin ardından kitabı okuduğumda özellikle şu noktaların üzerinde daha çok durduğumu fark ettim:

• Dirençle Baş Etme: Scrum’a geçişte zihniyet değişikliğine direnen ekiplerin eğitim, pilot projeler ve başarı hikâyeleriyle sürece alıştırılması gerektiği anlatılıyor.

• Gerçekçi Beklentiler: Scrum’ın hızlı değil, istikrarlı bir öğrenme süreci gerektirdiği ve başlangıçta belirsizlik yaratabileceği ancak doğru uygulandığında fark yaratacağı vurgulanıyor.

• Kültürel Uyum: Scrum’ın şirket kültürüyle uyumlu hâle getirilmesi ve güven, açık iletişim gibi değerlerin ön planda tutulması gerektiği belirtiliyor.

• Sprint Review: Bu toplantılarda çalışır bir ürün parçasının gösterilmesi ve paydaşların aktif olarak geri bildirim vermesinin önemine değiniliyor.

• Günlük Scrum: Takım üyelerinin ilerleme raporu vermek yerine takıldıkları noktaları paylaşmasının Sprint Hedeflerine ulaşmada kilit rol oynadığı anlatılıyor.

• Takım Dinamikleri: Roller arasında netlik sağlanmasının, özellikle Product Owner’ın müşteriden gelen talepleri doğru yönlendirmesi açısından kritik olduğu vurgulanıyor.

Bu kitap, Scrum uygulamasına geçmek isteyenler kadar, hâlihazırda Scrum kullanan ekiplerin süreçlerini iyileştirmeleri için de oldukça faydalı bir kaynak.

2. Scrum: Usta Sorulara Uzman Cevaplar

Bu kitap, Scrum hakkında daha derinlemesine soruları olan ve uygulamada karşılaştığı zorluklara çözüm arayanlar için mükemmel bir rehber. Mehmet Yitmen, bu kitabında en sık sorulan ve en kafa karıştırıcı Scrum sorularına kısa ve net cevaplarla açıklık getiriyor. Kitaptaki soruları buraya iliştiriyorum. Soruların kendisi bile cevapları merak ettirmeye yetiyor:

1. Agile mı Scrum mı? Agile nedir, Scrum nedir? Agile ve Scrum arasındaki fark nedir? Çevik yaklaşımı benimsemek için Scrum sürecini uygulamak yeterli midir?

2. Kimdir bu Product Owner? Product Owner rolü ve sorumlulukları nelerdir? Product Owner seçimi neye göre, nasıl yapılmalıdır?

3. Kimdir bu Scrum Master? Scrum Master rolü ve sorumlulukları nelerdir? Scrum Master’ın tam zamanlı bir rol olması zorunlu mudur?

4. İterasyon: İki hafta mı üç hafta mı? Sprint nedir? Sprint uzunluğu neye göre belirlenmelidir? Sprint toplantılarına ne kadar vakit ayrılmalıdır?

5. Yapışkan kâğıtlar mı teknoloji mi? Scrum uygulamak için en uygun talep yönetim ve iş takip aracı hangisidir? Bir program kullanmaya başladığımızda fiziksel Scrum Tahtası’nı da kullanmaya devam etmeli miyiz?

6. Retrospective toplantılarına her zaman ihtiyaç var mı? Retrospective toplantılarımızın verimli ve etkin geçmesi için ne yapmalıyız? Bazı toplantıları iyileştirme aksiyonu bulamadan sonlandırıyor olmamız bir sorun mu? Retrospective toplantısını her Sprint yerine birkaç Sprint’te bir yapsak problem yaratır mı?

7. Scrum uyguluyoruz ama? Scrum çerçevesini oluşturan birçok element var (Scrum Master, Product Owner, Sprint Planning, Daily Scrum vb). Scrum kullanmak istiyoruz ama tüm bu bileşenlerin hepsini kullanmak istemiyoruz. Bu mümkün müdür?

8. Üretkenlik mi verimlilik mi? Scrum takımındaki herkes, Sprint’ler boyunca her zaman %100 dolu olmayabiliyor. Bu durum kaynakların kötü kullanımı değil midir? Daha verimli olmak için bu kişilerin boş kalmadan, gerekirse başka işlerle meşgul olmasını sağlamamız gerekmez mi? Zaten şirkette yeterince kaynak yokken boş kalan kişilerin varlığı kabul edilebilir mi?

9. Peki ya proje yöneticisi? Bir proje yöneticisi olarak Scrum’daki rolümün ne olduğunu anlayamıyorum. Proje yöneticisi ile Scrum takımları arasındaki rol paylaşımı nasıldır?

10. Uzmanlıklar ve kişi bağımlılıkları: Scrum takımı üreteceği ürün/proje kapsamında tüm yetkinliklere sahip değilse, şirket içerisinde bazı yetkinlikler/uzmanlıklar konusunda yeterli sayıda kişi yoksa ve birden fazla proje/takım aynı kişilere ulaşmaya çalışıyorsa nasıl ilerlemek gerekir?

11. Ne olacak yöneticilerin hâli? Çevik yaklaşımını geliştirmeye çalışan ve yaygın bir şekilde Scrum kullanan bir organizasyonda yöneticilere ihtiyaç var mıdır? Böyle bir organizasyonda yöneticilerin görevi ne olmalıdır?

12. Sabit kapsam, sabit bütçe ve sabit bitiş süresi? Klasik yazılım geliştirme sözleşmeleri altında Scrum ile ilerlemek mümkün müdür? Bu durumda Scrum kullanılabilir ise olumlu ve olumsuz yönleri nelerdir?

13. Dijital dünya dışında Scrum? Scrum sadece yazılım takımlarına yönelik yönetsel bir araç mıdır? Yazılım takımları dışında Scrum nasıl kullanılır?

14. Çevik yaklaşımı ne kadar benimsiyoruz? Bunu görmek için nereye bakalım?

Burada benim en merak ettiğim sorular eğitimden daha detaylı ve gerizekalıya anlatır gibi anlatılmıştı. Dolayısıyla okudukça Scrum’ı daha güzel anladım.

Mesela en merak ettiğim sorulardan birisi 12. soruydu: Sabit bütçe, sabit kapsam ve sabit bitiş süresinin Scrum’a etkisi nedir? Bir mühendis olduğumdan mütevellit sorgulamayı severim. Tabii ki Çevik yaklaşımı ne ölçüde benimsediğimizi nasıl anlayabileceğimizi de aşırı merak etmiştim. Bir orta düzey yönetici olarak eğitimde Mehmet Bey, “Scrum’da dikey yöneticiler olmaz, herkes yatayda eşittir.” dedikçe içimden “Daha yeni yönetici olmuştum yaa, napcaz şimdi?” diye hayıflanıp durdum. Retrospective toplantısına her zaman ihtiyaç var mı ve aksiyon maddesi çıkmak zorunda mı? Hâlihazırda çift şapkalı birisi olarak (tahmin edersiniz ki Scrum Master ve Developer), çift şapkanın yeri ve önemi “Kimdir bu Scrum Master?” başlığında çok güzel ve detaylı işlenmişti.

Kitaptaki cevaplardan birkaçını kısaca yazmam gerekirse:

• Sabit kapsam ve bütçeyle çalışırken Scrum’ın esnekliğini korumak için iterasyon bazında çıktılara odaklanmak gerekir.

• Scrum’da yatay yapı, ekibin sorumluluk almasını kolaylaştırırken yönetici olarak benim rolümün daha destekleyici hâle gelmesi gerektiğini fark ettim. Ayrıca hem takım lideri hem de Scrum Master olarak ekibimin planlama esnasında işleri daha doğru anlaması ve daha isabetli bir planlama yapmasını önceliklendirdim. Takıldıkları herhangi bir nokta olursa “orada” olmaya ve elimi uzatmaya dikkat ettim.

• Hem bir yönetici hem de Scrum Master olarak karşılaşılan problemleri daha erken çözebilmek için daha ulaşılabilir olmalıydım. Şirket içi iletişim uygulamamız Teams’i telefonuma da indirip ekibim mesaj yazdığı anda telefonun ve bilgisayarın evi inletmesini sağladım.

• Eğitimde Mehmet Bey’in sıkça dile getirdiği birçok kavram, kitapta daha detaylı bir şekilde açıklanıyor. Örneğin, “Scrum’da herkes eşittir” fikrini ilk başta garipsemiş olsam da kitapta bu yatay yapının nasıl başarıyla işleyebileceği çok iyi anlatılmış.

Bunun gibi pek çok konuda bu kitap, eğitim sırasında öğrendiğim teorik bilgileri daha da pekiştirmeme ve pratikte daha bilinçli kararlar almama yardımcı oldu. Özellikle Scrum’a yeni başlayanlar ve profesyonellerin sık sık karşılaştıkları zorluklar için çok etkili bir rehber. Hem bu kitapları yazdığınız hem de hediye ettiğiniz için çok teşekkürler hocam. 😊