Retro önlemlerinin retrospektiften sonra da etkili olması için 9 ipucu
İlan · HappyScribe iş birliğiyle sponsorlu gönderi.
Retro iyi geçti. Herkes açıkça konuştu, ekip en önemli konularını önceliklendirdi ve sonunda herkesin arkasında durduğu iki ya da üç önlem ortaya çıktı.
Sonra sprint başlar. Ticket’lar birikir, bir üretim hatası salıyı yer, perşembe günü ise kimse tam olarak ne üzerinde anlaşıldığını artık pek hatırlamaz. Bir sonraki retroda biri kod incelemeleriyle ilgili ne olduğunu sorar. Sessizlik.
Retrospektifin kendisi iyi geçmiş olsa bile retro önlemleri başarısız olabilir. Retro panosu ile sprint panosu arasında, sonraki hafta içinde kaybolup giderler.
İyi önlemleri nasıl formüle edeceğinizi zaten ayrı bir makalede anlattık. Bu yazı, onun bittiği yerde başlıyor: retro bittikten sonra. Bir sonraki retro başladığında sonuçlarınızın hâlâ yaşamaya devam etmesini nasıl sağlarsınız? İyi retrospektif önlemleri için örneklerle 10 ipucu.
İpucu 1: Sonlandırmadan önce sonuçları bir kez daha okuyun
Retronun son beş dakikası çoğu zaman en zayıf bölümüdür. Odak dağılır, bir sonraki toplantı bekler ve önlemler aceleyle yazılır.
Kapatmadan önce her önlemi yüksek sesle okuyun. Birlikte şu soruları yanıtlayıp yanıtlayamadığınızı kontrol edin:
- Sorumluluğu kim üstleniyor?
- İlk adım nedir ve ne zaman gerçekleşecek?
- Bu önlemin etkili olduğunu nasıl anlarız?
Bir yanıt tek cümleye sığmıyorsa, önlem henüz tamamlanmamıştır. Herkes hâlâ oradayken netleştirin. Bu şimdi iki dakikanızı alır ve iki hafta sonra yaşanacak kafa karıştırıcı bir tartışmadan sizi kurtarır.
Yardımcı bir test: Retroya katılamayan biri önlemi okuyup ne yapılması gerektiğini anlayabilir miydi? Eğer önce bir açıklama gerekliyse, vedalaşmadan önce eksik bağlamı ekleyin.
İpucu 2: Her önleme sorumlu bir kişi ve ilk adım verin
Eğer “ekip” sorumluysa, günlük hayatta genellikle kimsenin üzerinde somut bir sorumluluk hissedilmez.
Bu yüzden her önlemin yanına bir isim yazın. Bu kişinin her şeyi tek başına yapması gerekmez. Görevi, uygulamayı takip etmek ve bir sonraki retroda bununla ilgili rapor vermektir.
Ayrıca küçük, somut bir ilk adıma ihtiyaç vardır. “Kod incelemelerimizi geliştirmek” bir hedeftir. “Çarşamba günü iki inceleyiciyle 30 dakika ayarlayıp bir kontrol listesi üzerinde uzlaşmak” ise ilk adımdır. Ne kadar küçük ve zamana yakın olursa, takibini yapmak o kadar kolay olur. Önümüzdeki iki gün içinde atılacak bir adım iyi bir başlangıçtır.
Böyle görünebilir:
| Retro sonucu | Sorumlu | İlk adım | Kontrol |
|---|---|---|---|
| Daha kısa daily’ler | Sam | Yarından itibaren kişi başı iki dakikayı deneyin | Sprint ortasında daily |
| Sprint Review’de daha az sürpriz | Priya | Ürünün sahibini salı günkü refinement’a davet edin | Sonraki retro |
| Daha net “Hazır Tanımı” | Alex | Bu hafta 45 dakikalık bir workshop ayarlayın | Sprint ortasında daily |
İsimler ve durumlar örnek amaçlıdır.
İpucu 3: Sadece kararı değil, gerekçeyi de kaydedin
Retrodan bir hafta sonra “PR incelemelerini iki kişiyle yapmak” gibi bir önlem garip görünebilir. İfade hâlâ durur. Ama bunun nedenleri çoğu zaman çoktan unutulmuştur.
Eğer artık kimse bir şeyi neden kararlaştırdığınızı hatırlamıyorsa, önceliği düşer. Ve bir sonraki retroda başarısını sorarsanız, belki de kimse asıl hedefi hatırlamaz.
Bu yüzden problemi doğrudan önlemin yanına yazın. Bir iki cümle yeterlidir: “İncelemeler son sprintte iki gün boyunca bekledi ve üç story’yi bloke etti.” Böylece ortak incelemelerin neden işe yarayabileceği netleşir.
Bazı uzaktan çalışan ekipler, aksiyonları belirledikleri retro bölümünü ayrıca kaydeder. HappyScribe gibi bir yapay zekâ not alma aracı, Zoom, Google Meet veya Microsoft Teams toplantılarına katılabilir, konuşmaları konuşmacı ayrımıyla yazıya dökebilir ve ardından aksiyonları içeren bir özet gönderebilir. Böylece kimin neyi neden önerdiği takip edilebilir. HappyScribe yapay zekâ toplantı not tutucusu.
Bununla bilinçli hareket edin: Retrolar ancak insanlar açıkça konuşacak kadar güvende hissettiklerinde işe yarar. Kayıt almadan önce ekibe sorup neyin kaydedileceğini, kimin erişim alacağını ve kaydın ne zaman silineceğini kararlaştırın. Biri bundan rahatsız olursa yazılı notlarda kalın. Olası bir uzlaşma, açık geri bildirim bölümünü kaydetmemek ve yalnızca önceliklendirme ile aksiyon planlamasını kayda almak olabilir. HappyScribe’da kayıt toplantı sohbetinden duraklatılıp devam ettirilebilir.
Tavsiye 4: Aksiyonları, ekibin her gün baktığı yerlere yerleştirin
Yalnızca retro panosunda duran aksiyonlar kolayca unutulur. O pano muhtemelen günlük çalışma rutininin bir parçası değildir.
Bu yüzden karara bağlanan aksiyonları, gerçekten çalıştığınız yere taşıyın: birçok ekipte sprint panosuna. Sorumlu kişi ve ilk adım için birer kart oluşturun. Böylece iyileştirme, Daily sırasında diğer işlerin yanında görünür olur.
Bunun için iyileştirme fikirleriyle dolu ayrı bir backlog’a ihtiyacınız yok. Echometer’in tavsiyesi şu şekilde kalır: En önemli başlıklar arasına giremeyen fikirler, ilgili kalmaya devam ederlerse daha sonraki ekip geri bildirimleriyle yeniden gündeme gelebilir. Pano üzerine gerçekten kararlaştırdığınız aksiyonlar gelir.
Tavsiye 5: Sprint içinde iyileştirmeler için kapasite planlayın
Retroda bir aksiyon kararlaştırılır. Sprint Planning’de ise sprint ardından özellik çalışmasıyla doldurulur. Aksiyona yer kalmaz ve sessizce ertelenir. Bu size tanıdık geliyor mu?
Scrum Guide, en etkili iyileştirmelere mümkün olan en kısa sürede başlanmasını önerir. Bunlar bir sonraki sprintin Sprint Backlog’una da alınabilir. Scrum Guide: Sprint Retrospective.
Bu nedenle retro aksiyonlarını bilinçli olarak Sprint Planning’e dahil edin. Birilerinin zaten bunu düşüneceğine güvenmeyin. Çabayı, diğer işlerde size yardımcı olacak şekilde, küçük olsa bile, tahmin edin. Gerçek kapasite planlayın. Sprint zaten doluysa, başka bir şeyin geri çekilmesi gerekir.
Bir aksiyon hiç yer bulamıyorsa, bu da önemli bir bilgidir. Belki de doğru aksiyon değildi. Bir aksiyonu bilinçli olarak iptal etmek, onu üç sprint boyunca sürüklemekten daha iyidir.
Tavsiye 6: Sprint ortasında ilerlemeyi kontrol edin
İki hafta, bir aksiyon olduğu gibi bırakıldığında uzundur. Bir sonraki retroya kadar beklerseniz, sprint sırasında rotayı düzeltme fırsatını kaçırabilirsiniz.
Sprint ortasında yapılacak kısa bir kontrol, uygulamayı hareket halinde tutar. Bunun için ekstra bir toplantı gerekmez. Daily’de bir dakika yeterli olabilir. Sorumlu kişi şunları yanıtlar:
- İlk adım atıldı mı?
- Sonraki adımı engelleyen bir şey var mı?
- Bu, yeni bulgularımız ışığında hâlâ doğru aksiyon mu?
Son soruyu atlamayın. Bazen retrodan sonra durum değişir. Ara durum, size artık fayda sağlamayan bir şeyi sonuna kadar götürmek yerine aksiyonu uyarlama imkânı verir.
Tavsiye 7: Aynı gün kısa bir özet gönderin
Anılar solar ve herkes retroyu biraz farklı hatırlar. Aynı gün gönderilen kısa bir yazılı özet, ortak bir temel oluşturur.
Onu, cep telefonunda okunabilecek kadar kısa tutun. Örneğin:
Retro özeti, Sprint 14. Önlem: PR incelemelerini bir sonraki sprintte iki kişiyle gerçekleştirin. Neden: İncelemeler son sprintte iki gün boyunca bekledi ve üç story’yi engelledi. Sorumlu: Priya. İlk adım: Çarşambaya kadar inceleme eşleştirmeleri için bir plan oluşturuyor. Biz kontrol edeceğiz: bir sonraki retroda incelemelere yönelik ortalama bekleme süresi.
Bunu, her gün birbirinizle konuştuğunuz yerde, örneğin ekip sohbetinde yayınlayın. Artık kimsenin açmadığı bir e-posta pek işe yaramaz.
Eğer önlem aşamasını kayda aldıysanız, bir yapay zekâ özeti ilk taslak olarak kullanılabilir. Okuyun, hataları düzeltin ve paylaşmadan önce örnekteki gibi birkaç satıra kısaltın.
İpucu 8: Birden fazla retro boyunca kalıpları arayın
Bazı konular sürekli geri gelir: yavaş incelemeler, belirsiz ticket’lar ya da eksik koordinasyon. Aynı sorun üst üste üç retroda ortaya çıkıyorsa, önlemlerinizin gerçekten işe yarayıp yaramadığını kontrol etmelisiniz.
Yaklaşık her çeyrekte bir, birkaç retroyu birlikte değerlendirin. Bu sorular yardımcı olur:
- Hangi konular tekrar ediyor?
- Hangi önlemler uygulandı?
- Bunun altında yatan sorun gerçekten ortadan kalktı mı?
- Hangi önlemler defalarca ertelendi ve neden?
Tekrarlayan bir konu, şimdiye kadar yalnızca bir semptomu ele aldığınızı gösterebilir. 5-Why yöntemi gibi bir kök neden analizi, daha derine inmenize yardımcı olabilir.
Retrolarınızın üzerinde anlaştığınız bölümlerini yazıya dökerseniz, eski panoları tek tek gözden geçirmek yerine onaylanmış transkriptleri arayabilirsiniz. HappyScribe Chat, örneğin bir klasördeki tüm transkriptler arasında sorular sormanızı destekler: “Bu çeyrekte birden fazla retrospektifte hangi sorunlar ortaya çıktı?” Yanıtları, orijinal notlar veya transkriptlerle doğrulayın.
İpucu 9: Sonraki retrosun başında döngüyü kapatın
Bir sonraki retroya başlamak, yeni geri bildirim toplamadan önce önlemlerinizi gözden geçirmek için iyi bir zamandır.
Echometer bunu, geçmiş retrolardan açık önlemleri listeleyerek destekler. Araçtan bağımsız olarak her önlemi gözden geçirin: Tamamlandı mı? Hedefine ulaştı mı? Onu sürdürelim mi, değiştirelim mi yoksa bırakalım mı? Önlem makalemizde bunun için basit bir değerlendirme matrisi bulunuyor. Retrospektiflerden gelen önlemler için değerlendirme matrisi.
Etkili iyileştirmeleri fark etmek için bir an ayırın. Bu, ekibe retroların değişime yol açtığını gösterir ve bir dahaki sefere katkı sunma isteğini güçlendirebilir.
Bir önlem işe yaramadıysa, onu size bir cevap vermiş bir deney olarak ele alın. Sırada neyi deneyeceğinize ya da bilinçli olarak neyi geride bırakacağınıza karar verin.
Sonuç: Retro biter, uygulama devam eder
İyi önlemler bir başlangıçtır. Ancak iyi formüle edilmiş bir önlem bile, bir sonraki retroya kadar kimse ona yeniden bakmazsa pek işe yaramaz.
Bu makaledeki adımlar küçük: Sonuçları kapanıştan önce okuyun. Her önleme sorumlu bir kişi ve ilk bir adım verin. Kararın nedenini kaydedin. Önlemleri sprint panosuna taşıyın, kapasite ayırın ve sprint ortasında ilerlemeyi kontrol edin. Aynı gün kısa bir özet paylaşın, düzenli olarak kalıpları arayın ve bir sonraki retroya önceki önlemlere bakarak başlayın.
Bunların çoğu sadece birkaç dakika sürer. Sadece bir ipucunu denemek istiyorsanız, İpucu 1 ile başlayın: Net sorumluluk ve somut ilk adımlarla biten bir retro, sonraki hafta için iyi bir temel oluşturur.
