4Ls Retrospective: Sprint Retrospektiflerini Daha Değerli Hale Getirmek

Retrospektifleri Angaryadan Kurtarın: 4Ls Tekniği ile Takımınızı Ateşleyin

Retrospektif toplantıları, Agile ve Scrum süreçlerinin en kritik bileşenlerinden biridir. Sprint sonunda takımın bir araya gelip yaşananları değerlendirmesi, sürekli iyileşme kültürünün temel taşıdır. Ancak pratikte, birçok retrospektif toplantısı beklenen değeri üretmekte zorlanır.

Kariyerim boyunca farklı retrospektif teknikleri deneme fırsatı buldum. Mad-Sad-Glad, Start-Stop-Continue, Timeline Retrospective gibi yaklaşımların her birinin avantajları var. Ancak özellikle mühendislik ekiplerinde çalışırken 4Ls Retrospective tekniğinin oldukça etkili olduğunu gözlemledim. Bu yazıda, 4Ls tekniğinin ne olduğunu, nasıl uygulandığını ve neden işe yaradığını paylaşmak istiyorum.

4Ls Retrospective Nedir?

4Ls, dört temel başlık üzerinden sprint değerlendirmesi yapmayı sağlayan yapılandırılmış bir retrospektif tekniğidir:

• Liked (Beğendiklerimiz): Sprint boyunca işe yarayan ve tekrar edilmesini istediğimiz uygulamalar
• Learned (Öğrendiklerimiz): Sprint sırasında edindiğimiz yeni bilgiler ve tecrübeler
• Lacked (Eksik Kalanlar): İhtiyaç duyduğumuz ancak olmayan ya da yetersiz kalan unsurlar
• Longed For (Beklentilerimiz): Bir sonraki sprintlerde görmek istediğimiz iyileştirmeler

Bu dört kategori, takım üyelerinin farklı perspektiflerden düşünmesini sağlar. Sadece "iyi-kötü" değerlendirmesinden öteye geçerek, öğrenmeye ve geleceğe bakışa odaklanır.

Neden 4Ls Tekniğini Tercih Ediyorum?

Klasik retrospektif formatlarında genellikle "Neyi iyi yaptık?" ve "Neyi kötü yaptık?" sorularına odaklanırız. Bu yaklaşım bazen takımı savunmaya geçmeye ve suçlama yapmaya yönlendirebilir. 4Ls ise daha dengeli bir yapı sunar:

Olumluya Odaklanma: Liked ve Learned başlıkları, takımın başarılarını ve gelişimini öne çıkarır. Bu, morali yüksek tutar ve takımın güçlü yönlerinin farkında olmasını sağlar.

Yapıcı Eleştiri: Lacked başlığı, şikayetten ziyade tespit yapmaya davet eder. "Nefret ettiğimiz şeyler" demek yerine "eksik kalan şeyler" demek, konuşmaları daha yapıcı hale getirir.

Geleceğe Bakış: Longed For, takımın vizyoner tarafını ortaya çıkarır ve sürekli iyileşme için somut hedefler belirlemeyi kolaylaştırır.

Her Bir Kategorinin Detaylı İncelemesi

Liked (Beğendiklerimiz)

Bu bölümde, sprint boyunca başarılı bulunan uygulamaları değerlendiriyoruz. Önemli olan, sadece genel tebrikler değil, somut gözlemler paylaşmaktır.

Örnek: "Code review süreçlerimiz bu sprint daha hızlı ilerledi" yerine "CI/CD pipeline'a eklediğimiz otomatik linter kontrolü sayesinde syntax hatalarıyla uğraşmadan, doğrudan iş mantığına odaklanabiliyoruz" demek çok daha değerlidir.

Somut veriyle desteklenen Liked maddeleri, takımın hangi pratikleri sürdürmesi gerektiğine dair net bir yol haritası sunar.

Learned (Öğrendiklerimiz)

Benim en çok önem verdiğim kısım burası. Retrospektif toplantılarını bilgi paylaşımı platformuna dönüştürmenin en iyi yolu, Learned başlığını etkin kullanmaktır.

Teknik Öğrenmeler: "AWS Lambda'nın cold start süreleri, VPC içinde çalışırken beklediğimizden daha yüksek olabiliyor. Optimizasyon için connection pooling kullanmak gerektiğini öğrendik."

Süreç Öğrenmeleri: "Task'ları daha küçük parçalara bölmemiz gerektiğini gördük. 5 günlük bir task yerine günlük tamamlanabilecek parçalar oluşturmak, tahmin doğruluğumuzu artırdı."

Learned kısmı, özellikle hataların normalize edilmesine yardımcı olur. "Denedik, işe yaramadı, ama şunu öğrendik" kültürü, takımı yenilikçi olmaya teşvik eder.

Lacked (Eksik Kalanlar)

Bu başlık, şikayet değil tespit odaklı olmalıdır. Neyin eksik olduğunu belirlemek, bir sonraki sprintte nelere öncelik verileceğine dair önemli ipuçları sunar.

Örnekler:

• Test ortamında production'a benzer veri seti eksikti, bu yüzden bazı senaryoları test edemedik.
• API dokümantasyonu güncel değildi, entegrasyon yaparken kod okumak zorunda kaldık.
• Sprint planning sırasında design wireframe'leri henüz hazır değildi, tahminlerimizde belirsizlik oluştu.

Bu tespitler, somut aksiyonlara kolayca dönüştürülebilir.

Longed For (Beklentilerimiz)

Bu bölüm, takımın vizyonunu ortaya koyar. Sadece mevcut sprinti değil, orta ve uzun vadeli iyileştirmeleri konuşmak için idealdir.

Örnekler:

• Deployment sürecinin tek komutta, otomatik olarak tamamlanmasını istiyoruz.
• Tüm mikro servislerin loglarının merkezi bir dashboard'da görüntülenmesini arzu ediyoruz.
• Otomatik test coverage'ımızın %80'in üzerine çıkmasını bekliyoruz.

Longed For maddeleri, teknik borçların temizlenmesi ve altyapı iyileştirmeleri için güçlü bir backlog oluşturur.

4Ls Retrospective Nasıl Uygulanır?

1. Hazırlık (5 dakika): Toplantı öncesinde dört başlığı (Liked, Learned, Lacked, Longed For) bir Miro board veya beyaz tahta üzerinde hazırlıyorum.

2. Sessiz Yazma (7-10 dakika): Takım üyelerinin birbirlerinden etkilenmeden düşünmelerini sağlamak için sessiz bir yazma periyodu uyguluyorum. Herkes kendi maddelerini not ediyor.

3. Paylaşım ve Gruplama (15-20 dakika): Herkes maddelerini paylaşıyor. Benzer konular gruplanıyor. Örneğin "Testler eksikti", "Test coverage düşük", "Unit test yazamadık" gibi maddeler "Test Kültürü" teması altında toplanabilir.

4. Tartışma (15-20 dakika): Gruplandırılmış temalar üzerinde konuşuyoruz. Özellikle Lacked ve Longed For başlıklarına odaklanıyoruz çünkü aksiyonlar genellikle buradan çıkıyor.

5. Aksiyon Belirleme (5-10 dakika): Net, ölçülebilir, kişiye atanmış aksiyonlar beliriyoruz. "Daha iyi iletişim kuralım" gibi muğlak hedefler yerine "Ahmet, Çarşamba gününe kadar API dokümantasyonunu Swagger'a aktaracak" gibi somut görevler çıkarıyoruz.

Toplam süre yaklaşık 45-60 dakika.

Dikkat Edilmesi Gereken Noktalar

Sessiz Yazma Önemlidir: Herkesin eşit katılımını sağlamak için sessiz yazma periyodu kritik. Özellikle içe dönük karakterdeki ekip üyeleri bu sayede rahatça katkı sunabiliyor.

Gruplama Yapın: 40-50 madde çıkması normaldir. Hepsini tek tek konuşmak yerine tematik gruplama yaparak verimliliği artırıyoruz.

Aksiyonsuz Retro Olmaz: Eğer retrospektif sonunda somut bir aksiyon çıkmıyorsa, toplantı amacına ulaşmamış demektir. Her retrospektiften en az 2-3 aksiyon maddesi çıkarmalıyız.

Psikolojik Güvenlik Şart: Takım üyelerinin rahatça konuşabilmesi için psikolojik güvenlik ortamı oluşturulmalı. Learned bölümünde hataları paylaşmak, eleştirilmek değil takdir edilmek anlamına gelmelidir.

4Ls Ne Zaman Yeterli Olmayabilir?

Her teknik gibi 4Ls de bazı durumlarda tek başına yetersiz kalabilir:

• Derin Kök Neden Analizi Gereken Durumlar: Eğer ciddi bir sorun yaşandıysa (production outage, major bug vb.), 5 Whys veya Fishbone Analysis gibi daha detaylı tekniklere ihtiyaç duyulabilir.
• Çok Büyük Ekipler: 20-30 kişilik ekiplerde 4Ls yönetmek zorlaşır. Bu durumda alt ekiplere bölmek veya farklı bir format tercih etmek gerekebilir.
• Uzun Süreli Sistemik Sorunlar: Aylar boyunca biriken sorunlar için Timeline Retrospective daha uygun olabilir.

Sonuç

4Ls Retrospective, yapılandırılmış yapısı ve dengeli yaklaşımıyla sprint değerlendirmelerini daha verimli hale getiren güçlü bir tekniktir. Özellikle teknik ekiplerde, öğrenmeye ve sürekli iyileşmeye odaklanmayı kolaylaştırır.

Eğer mevcut retrospektif formatınız beklediğiniz değeri üretmiyorsa, 4Ls tekniğini denemenizi öneririm. Basit yapısı sayesinde hızlıca adapte edilebilir ve ilk toplantıdan itibaren fark yaratmaya başlayabilir.

Unutmamak gerekir, hiçbir süreç mükemmel değildir. Ancak sürekli iyileştirilen, takımla birlikte evrimleşen süreçler vardır. 4Ls de tam olarak bunu destekleyen bir çözüm/çerçeve sunmaktadır. Umarım yazımı beğenmişsinizdir, diğer yazılarıma da göz atmayı unutmayın.