Retrospektifi Aksiyona Bağlamak: Sayı, Sahip ve Takip

Retrospektifin zayıf halkası toplantının kendisi değil, çıktısının nereye gittiğidir. Çoğu ekip aynı üç maddeyi altı sprint boyunca yeniden konuşur, çünkü ilk seferinde yazılan aksiyon kimsenin açmadığı bir dokümanda kalmıştır. Ekip aynı şeyi tekrar tekrar gündeme getiriyorsa, arıza toplantı formatında mı yoksa takip düzeninde mi?

Aynı maddeler neden geri geliyor

Retro çıktılarına bakıldığında maddelerin çoğu aslında aksiyon değil, dilek oluyor. "İletişimi güçlendirelim", "tasarımı daha erken paylaşalım", "dokümantasyona özen gösterelim". Bunların ortak özelliği, yarın sabah kimsenin ne yapacağını bilmemesi.

Ayırt etmek için tek soru yeter: bu maddenin bu hafta içinde tamamlanabilecek ilk adımı ne? Cevap veremiyorsanız elinizdeki şey bir niyettir ve bir sonraki retroda aynı cümleyle karşınıza çıkar. "Tasarımı daha erken paylaşalım" dileği, "sprint ikinci gününde tasarım ekranlarının ilk halini geliştiricilerle birlikte gözden geçireceğiz" haline geldiğinde takip edilebilir bir şeye dönüşür.

Aksiyon sayısı aslında bir kapasite sorusu

Bir retrodan beş madde çıkarıp bunlardan ikisini bitiren ekip, her döngüde listesine üç madde ekliyor demektir. Altı sprint sonra ortada on sekiz yarım kalmış madde birikir. O noktadan sonra kimse listeyi açmaz, çünkü listenin kendisi bir suçluluk kaynağına dönüşmüştür ve yeni gelen maddeler eski yığının içinde kaybolur.

Bu yüzden retroların çıktısı iki maddeyi geçmemeli, çoğu zaman bir madde daha iyi sonuç veriyor. Kalanları not olarak tutmak yerine açıkça "bu döngüde bunu yapmıyoruz" demek daha dürüst; konu gerçekten canlıysa bir sonraki retroda kendiliğinden geri gelir.

Aksiyonları ayrı bir retro dokümanında tutmam. Sprint backlog'una, diğer işlerin arasına, sahibi ve tahmini belli normal bir iş olarak girer. Ekibin her gün baktığı yer orası; ayrı tutulan liste, ne kadar düzenli olursa olsun, ikinci sınıf iş muamelesi görüyor.

UX ekiplerinde retronun asıl kazancı

Tasarım ve geliştirme arasındaki fark, retroda konuşulmadığında sessizce birikiyor. Bir ekran tasarlanır, uygulanır, sonuçta ortaya çıkan şey tasarımdan biraz farklıdır ve kimse bunun nerede ayrıştığını sormaz. Oysa ayrışma noktaları neredeyse hep aynı yerlerde: boş durumlar, hata mesajları, uzun metnin taşması, yavaş bağlantıda yükleme hali.

Bunlar tasarım dosyasında çoğunlukla yoktur, geliştirici de teslim baskısı altında doğaçlar. Retroda sorulacak somut soru şu: bu sprintte hangi ekranın boş ya da hatalı hali kodda doğaçlama oldu? Cevap, bir sonraki sprintin tasarım kontrol listesini kendiliğinden yazar.

Peki araştırma tarafına aynı soruyu sorsak ne çıkar? Son kullanıcı testinden çıkan bulguların kaçı backlog'a girdi, kaçı sunumda kalıp orada bitti? Bu oranı bir kez ölçen ekipler genelde rahatsız olur, ama rahatsızlık doğru yerde olur: sorun testin kalitesinde değil, bulgunun ürüne taşınma yolunun hiç kurulmamış olmasındadır.

Formatı değiştirmek, tartışmayı değiştirir

Aynı üç soruyla (iyi giden, kötü giden, denenecek) ilerleyen retrolar birkaç ay sonra ezber halini alıyor. Birkaç küçük müdahale bunu kırıyor:

• Tartışmadan önce herkes maddelerini sessizce yazsın. İlk konuşan kişinin gündemi belirlemesi, özellikle kıdem farkı olan ekiplerde en sık görülen sapma.
• Kolaylaştırıcılığı sırayla üstlenin. Toplantıyı hep aynı kişi yönetiyorsa, o kişinin körlükleri ekibin körlüğü haline gelir.
• Ara sıra metafor kullanın. Yelkenli formatı (ileri taşıyan rüzgar, yavaşlatan çapa, ilerideki kayalıklar) sorunları kişilerden ayırmakta işe yarıyor, özellikle gergin bir sprintin ardından.

Bir de tersinden yoklamayı deneyin: iyi giden bir şeyi övüp geçmek yerine neden iyi gittiğini kazın. Çoğu zaman altından tekrar edilebilir bir uygulama çıkar, ve tekrar edilebilir bir iyi uygulama, düzeltilmiş bir hatadan daha kalıcıdır.

Ne zaman retro yapmamak gerekir

Ekip aynı hafta içinde büyük bir olaya müdahale ettiyse ya da sonuçları henüz netleşmemiş bir karar sürecinin ortasındaysa, takvime bakıp yapılan retro genelde boş geçer. Bu durumda toplantıyı bir hafta ertelemek, ritmi korumak için içi boş bir seans yapmaktan daha iyi. Retronun düzenli olması değerli, ama düzen kendi başına bir amaç değil.