Eyleme Yönlendiren Sprint Retrospektifi Nasıl Yönetilir

Bir sprint retrospektifi, sonraki sprintin nasıl çalıştığını değiştirdiğinde faydalıdır. Dürüst gözlemlerle dolu bir pano sadece sürecin ortasıdır; toplantı, sahipleri olan ve gözden geçirilebilecek az sayıda iyileştirmeyle sona ermeli.

Bu rehber, iki haftalık sprinti tamamlayan bir ekip için yöneticiye tekrarlanabilir 60 dakikalık bir akış sunar. Zaman kutucuklarını ekip ve sprintin karmaşıklığına göre kısaltabilir veya uzatabilirsiniz. Resmi Scrum Rehberi, bir aylık Sprint için üç saate kadar izin verir ve kısa Sprintlerin genellikle daha kısa etkinlik gerektirdiğini belirtir.

Bu rehberde

• Kısa versiyon
• Toplantı öncesi hazırlık
• Pratik 60 dakikalık gündem kullanımı
• Gözlemleri bağımsız topla
• Temaları grupla ve oyla
• Tartışmayı eyleme dönüştür
• Bir örneği incele
• Yaygın retrospektif hatalarından kaçın
• Kolaylaştırıcı kontrol listesini kullan

Kısa versiyon

Retrospektifi yedi adımda yönetin:

1. Amacı yeniden belirtin ve güvenli, suçlamasız bir çerçeve oluşturun.
2. Önceki iyileştirmeyi ve ilgili sprint kanıtlarını inceleyin.
3. Açık tartışma başlamadan önce herkesin gözlem eklemesine izin verin.
4. İlgili kartları temalar halinde gruplayın.
5. Ekibin sınırlı zamanı için değerli birkaç konuyu seçmek üzere oy kullanın.
6. Suçluları değil, nedenleri ve seçenekleri araştırın.
7. Bir veya iki özel aksiyon oluşturun, sahip ve gözden geçirme noktası belirleyin.

Sprint Retrospektifi bir durum raporu ya da performans değerlendirmesi değildir. Scrum'da amacı, sprintin insanları, etkileşimleri, süreçleri, araçları ve Tamamlanma Kriterini nasıl geçtiğini inceleyerek kalite ve etkinliği artırmanın yollarını planlamaktır.

Retrospektiften önce: kanıt ve güvenliği hazırlayın

Yararlı bir konuşma aramadan önce başlar. Toplantıyı metrik sunumuna dönüştürmeden hafızaya yardımcı olacak yeterli kanıt hazırlayın.

Aşağıdakiler gibi küçük bir sinyal seti getirin:

• Sprint Hedefi ve başarılıp başarılmadığı;
• devreden işler ve nedenleri;
• olaylar, sürüm problemleri veya tekrarlayan kesintiler;
• ekip tarafından zaten izlenen çevrim süresi veya akış değişiklikleri;
• kaçan hatalar veya tekrar iş dahil kalite sinyalleri;
• önceki retrospektif aksiyonu ve mevcut sonucu.

Kanıtlar soruları başlatmalı, sonlandırmamalıdır. “Üç iş devredildi” bir sinyaldir. “Geliştiriciler kötü tahminde bulundu” ise zaten bir karardır.

Sprint’e uygun yönlendirmeler seçin

Doğrudan iletişim ihtiyaç duyan ekipler için basit üç sütunlu bir pano işe yarar:

• Bize ne yardımcı oldu?
• Önümüze ne çıktı?
• Sonrakinde neyi değiştirmeliyiz?

Durum değiştikçe yönlendirmeleri değiştirin. Bir sürüm retrospektifi hazırlık, uygulama ve iyileşmeye odaklanabilir. Yeni bir ekip netlik ve iş birliği hakkında yönlendirmelere ihtiyaç duyabilir. Sadece yenilik için format değiştirmeyin; ekibin gerçekten yaptığı işi incelemesini sağlayan yapıyı seçin.

Yönlendirmeler konuşmaya uyuyorsa retrospektif şablon kütüphanesinden hazır bir pano seçin:

Retrospektif oluşturucuyu açmadan önce şablon sayfasında sütunları ve toplantı ayarlarını ön izleyin. Geri bildirim topladıktan sonra tüm panoda bir veya iki iyileştirme seçin; sütun sayısı aksiyon maddesi kotası değildir.

Katılımın nasıl işleyeceğine karar verin

Tüm Scrum Ekibini davet edin. Kim yönetecek, sessiz yazma ne kadar sürecek, oylar nasıl dağıtılacak ve anonim katkı uygun mu, karar verin. Agilo, yapılandırılabilir sütunlar, yorumlar, reaksiyonlar, oylama ve isteğe bağlı anonimlik desteği sunar.

Anonimlik hassas sinyal vermenin maliyetini düşürebilir, ancak tek başına psikolojik güvenlik yaratmaz. Yöneticinin hala suçlamayı durdurması, insanları misillemeden koruması ve tartışmayı ekibin etkileyebileceği sistemler ve tercihler üzerinde tutması gerekir.

Pratik 60 dakikalık gündem

Ekip retrospektiflere yeni ise yapıyı basit tutun ve her geçişi açıklayın. Tecrübeli ekipler daha kısa talimat kullanabilir, ancak zaman kutucuklarının görünür olması ve net bir sonuç yine de faydalıdır.

Adım 1: Amacı belirterek açılış yapın, formalite değil

Sonucu belirterek başlayın:

Buradayız çünkü bu sprintin nasıl işlediğini anlamak ve sonraki sprinti daha etkili kılacak bir veya iki değişiklik seçmek istiyoruz.

Ardından hafif kurallarda anlaşın: eksik bilgi olabileceğini kabul edin, gözlemlenen olaylardan konuşun, insanların sözünü bitirmesine izin verin ve süreci eleştirin, kişiye saldırmayın.

Yeni aksiyonlar oluşturmadan önce son retrospektif aksiyonunu gözden geçirin. Tamamlandıysa ne değişti diye sorun. Tamamlanmadıysa nedenini öğrenin. Bu adımı atlamak, ekibe retro taahhütlerinin sekme kapandığında yok olduğunu öğretir.

Adım 2: Tartışmadan önce gözlemleri toplayın

Herkese kart eklemek için beş ila sekiz dakikalık sessiz zaman verin. Sessiz yazmak, en hızlı konuşanın avantajını azaltır ve katılımcıların ilk görüş ortamı şekillendirmeden önce kendi görüşlerini oluşturmalarını sağlar.

Somut gözlemler isteyin:

• Sprint Hedefi'ne ulaşmamıza ne yardımcı oldu?
• İş nerede bekledi, geri döndü veya tekrar iş gerektirdi?
• Hangi varsayım bizi şaşırttı?
• İşleyen neyi korumalıyız?
• Bir sonraki sprintte değiştirme şansımız olan nedir?

Bir kart tek bir sinyal içermelidir. “Sürüm hazırlığı” çok geniş. “QA, kararlı sürümü sadece sürüm penceresinden 20 dakika önce aldı” ekibin araştırabileceği spesifik bir şey verir.

Kurgusal katılımcılarla güncel Agilo arayüzü: Tartışmadan oluşturulan aksiyon maddeleri yanında gözlemler görünür.

Adım 3: Sinyalleri grupla ve önemli olanlara oy ver

Kartları netlik için okuyun, hemen tartışmak için değil. Yazara belirsiz ifadeyi açıklamasını isteyin, sonra aynı sistemi ya da tekrarlayan etkileri anlatan kartları gruplayın.

Örneğin, bu kartlar birlikte olabilir:

• “Derleme planlanan test penceresinden sonra geldi.”
• “Regresyon son saate sıkıştırıldı.”
• “Kod dondurmasından sonra iki düzeltme birleştirildi.”

Ortak tema "sürüm değişiklikleri stabil bir regresyon penceresi bırakmıyor" olabilir. Gruplama, ekibin aynı konuyu farklı etiketlerle üç kez tartışmasını engeller.

Sonra, oy verin. Oylama, önceliklendirmeye yardımcı olur; ağrının bilimsel ölçümü değildir. En çok oy alan iki veya üç temayı seçin, ardından daha az oya sahip bir konunun ihmal edilmemesi gereken acil bir güvenlik, etik veya operasyonel risk olup olmadığını kontrol edin.

Adım 4: Toplantıyı mahkemeye çevirmeden nedenleri araştırın

Bir kerede bir temayı tartışın. Olayı, etkisini, katkıda bulunan koşulları ve olası değişikliği ayırın.

Yararlı sorular şunları içerir:

• Ne oldu ve bunu ilk ne zaman fark ettik?
• Bu sonucu hangi koşullar olası kıldı?
• Bilgi nerede bekledi veya el değiştirdi?
• Kararı hangi varsayım veya politika şekillendirdi?
• Bu ekip bir sonraki Sprint sırasında hangi kısmı etkileyebilir?
• Bize kanıt sağlayacak en küçük deney ne olur?

Yararlı soru "Kim başarısız oldu...?" değil, "Başarısızlığın tekrarlanmasını kolaylaştıran neydi?" olmalıdır. Bireysel sorumluluk önemlidir ancak suçlama, sistem anlaşılmadan önce kanıtları genellikle daraltır.

Tartışmayı sınırlı tutun. Bir konu teknik bir atölye veya yönetim kararı gerektiriyorsa, tüm retrospektifi harcamak yerine o takip görevini atayın.

Adım 5: Bir veya iki uygulanabilir iyileştirme oluşturun

İyi bir aksiyon maddesi, ekibin gözlemleyebileceği bir davranış veya değişikliği tanımlar. Şunları içerir:

• bir arzu değil, net bir eylem;
• ilerletmekten sorumlu bir kişi;
• kontrol edileceği zaman veya olay;
• değişikliğin fayda sağladığını takıma bildiren sonuç;
• gerektiğinde eylemi tetikleyen gözleme bağlantı.

Bu örnekleri karşılaştırın:

Eğer her eylem “iletişimi geliştir” ile başlıyorsa, retrospektif plan değil, fal üretmiştir. Bir sonraki davranışı görünür kılın. 🙂

Bir eylem, onu oluşturduğun gözlemle bağlantılı kalır ve öncelik, durum ve sahipliği kaydeder.

Genellikle iki sahiplenilmiş eylem, on iki niyetten daha değerlidir. Scrum.org da benzer şekilde, iyileştirmeleri önceliklendirmeyi ve takım çok fazla eylem belirlediğinde en değerli bir veya ikisini bir sonraki Sprint için seçmeyi önerir.

Daha fazla durum için, retrospektif aksiyon maddesi örneklerini kullanın: inceleme sıraları, bağımlılıklar ve bilgi paylaşımını kapsar; kopyalanabilir kayıtlar ve tamamlama ile etki kontrolleri sunar.

Adım 6: Geri bildirim döngüsünü kapatın

Toplantı bitmeden önce, her eylemi yüksek sesle okuyup onaylayın:

• sahibinin kabul ettiği;
• ekibin beklenen değişikliği anladığı;
• eylemin ekibin etkisi içinde olduğu veya net bir yükseltme yolu bulunduğu;
• gözden geçirme noktasının görünür olduğu.

Çalışmayı görünür kılmanın en iyi yoluysa, etkili bir iyileştirmeyi bir sonraki Sprint Backlog’una ekleyin. Bir sonraki retrospektif, sonucu gözden geçirerek başlasın. Tamamlanan, değiştirilen ve bırakılan deneyler, sonuç incelendikçe takıma bir şeyler öğretebilir.

Toplantıyı hızlı bir kontrolle kapatın: “Bu toplantı işimize yarayacak bir değişikliği seçmemize yardımcı oldu mu?” Cevabı bir sonraki retrospektifi geliştirmek için kullanın.

Uygulamalı örnek: sprint sinyalinden sahiplenilen aksiyona

Cuma akşamı sürüm yapan bir ekip hayal edin.

Panodaki sinyaller

• QA, sürüm zamanından 20 dakika önce stabil yapıyı aldı.
• Planlı kapanıştan sonra iki “küçük” kapsam değişikliği geldi.
• Geliştiriciler yapılandırma sorununu gidermek için geç kaldılar.
• Sürüm yapıldı ancak regresyon kapsamı azaldı.

Gruplanmış tema

Ekip kartları “geç kapsam değişiklikleri regresyon penceresini kaldırdı” olarak gruplar. Kaliteyi, fazla mesaiyi ve öngörülebilirliği etkilediği için en çok oyu aldı.

Tartışma

Grup, kod kapanışının sadece öneri olarak ele alındığını fark eder. Satış talepleri sohbet üzerinden geldi, reddetme yetkisi yoktu ve QA’nın görünür bir hazır olma noktası yoktu.

Seçilen deney

Önümüzdeki iki sürüm için, sürüm zamanından 48 saat önce kapsamı dondurun. Her istisna, Ürün Sahibi ve Teknik Lider’den görünür bir karar gerektirir. Teknik Lider kontrolün sahibidir; ekip, geç istisnaları ve regresyon süresini bir sonraki retrospektifte inceler.

Bu eylem "daha iyi takım çalışması" vaat etmez. Bir karar kuralını değiştirir, bir sorumlu atar, deneyi sınırlar ve ekibin neyi gözden geçireceğini tanımlar.

Retrospektifleri anlamsız kılan yaygın hatalar

Değişiklik seçmeden şikayetleri toplamak

Sürtünmeyi isimlendirmek rahatlatıcı olabilir, ancak uyum sağlamadan tekrar eden gözlemler sinizme yol açar. Tartışma büyümeden önce eylem aşaması için zaman ayırın.

Çok fazla aksiyon maddesi oluşturmak

Uzun liste sahipliği yayar ve Sprint işine rakip olur. Bir veya iki yüksek değerli değişikliği seçin, diğer fikirleri daha sonra görünür tutun.

Önceki eylemi görmezden gelmek

Kimse kontrol etmezse ekip bir deneyin işe yarayıp yaramadığını öğrenemez. Her retrospektife son taahhütle başlayın.

Oylamanın ciddi riskleri silmesine izin vermek

Oylar paylaşılan ilgiyi gösterir, ciddiyeti değil. Güvenlik, emniyet, taciz veya uyum endişesi, tek oy alsa bile uygun yanıt gerektirir.

Retrospektifi bir performans değerlendirmesine çevirmek

Gözlemler, insanları sıralamak ya da cezalandırmak için kullanıldığında, kişiler faydalı bilgileri paylaşmayı bırakır. İş sistemi ve ekip etkileşimlerini inceleyin; bireysel performansı uygun özel süreçlerle yönetin.

Sadece ekibin kontrol edemediği konuları tartışmak

Dış engeller önemlidir ancak toplantı yine de sonraki adımı gerektirir: bir yükseltme sahibi, kanıt talebi, sınır veya ekibin kontrolünde küçük bir değişiklik.

Kolaylaştırıcı kontrol listesi

Toplantı öncesi:

• sprint ile uyumlu tetikleyiciler seçin;
• birkaç tarafsız kanıt noktası hazırlayın;
• önceki eylem durumunu gözden geçirin;
• panoyu, oylamayı, anonimliği ve zaman kutusunu yapılandırın;
• kolaylaştıranın ve katılımcıların kim olduğunu onaylayın.

Toplantı sırasında:

• amacını ve çalışma kurallarını belirtin;
• herkese sessizce yazma zamanı verin;
• tartışmadan önce netleştirin;
• ilgili sinyalleri gruplayın;
• oy verin, ardından acil ve az oy alan riskleri kontrol edin;
• suçu değil, nedenleri ve etkiyi tartışın;
• son on dakikayı eylemler için ayırın.

Kapatmadan önce:

• bir veya iki iyileştirmeyi tutun;
• her birine bir sahip atayın;
• gözlemlenebilir sonraki davranışı tanımlayın;
• sonucun ne zaman inceleneceğine karar verin;
• retrospektifin kendisinin faydalı olup olmadığını sorun.

Agilo içinde iş akışını yürütün

Agilo Retrospectives, gözlemleri, gruplamayı, oylamayı, yorumları, tepkileri ve atanmış aksiyon maddelerini tek bir paylaşılan panoda tutar. Tetkik ayarlarını ve katılım seçeneklerini yapılandırabilir, bir aksiyonu kaynak kartına bağlayabilir ve toplantı sonrası durumunu görünür tutabilirsiniz.

Bir retrospektif panosu oluşturun ekip, tetikler ve zaman kutusu hazır olduğunda.

Kaynaklar ve daha fazla okuma

• Resmi Scrum Rehberi — Sprint Retrospektifinin amacı, denetim alanları, iyileştirme sonucu ve azami zaman kutusu.
• Scrum.org: Sprint Retrospektifini Yönetmek — basit pano, tartışma, önceliklendirme ve iyileştirme seçimi.
• Scrum.org: Sprint Retrospektiflerinizi Daha Etkili Hale Getirmek — yaygın antipatternler ve bir veya iki iyileştirmeyi önceliklendirme rehberi.