Gönderiler

Retrospektiflerinizden İş Yapılabilir Eylem Maddelerini Nasıl Elde Edersiniz

Ekibiniz retrospektifler yapıyor. Sorunları tanımlıyorsunuz. Eylem maddelerini yapışkanlı notalara yazıyor veya paylaşılan bir belgeye yazıyorsunuz. Ve sonra hiçbir şey olmuyor. Sprintin ortasında kimse ne karar alındığını hatırlamıyor. Bir sonraki retrospektifte aynı sorunlar yeniden ortaya çıkıyor. Bu, çevik ekiplerde en yaygın başarısızlık modudur ve seçtiğiniz retrospektif formatıyla ilgisi yoktur. Sorun tartışma bittikten sonra ne olduğudur. Etkili retrospektifler yürüten ekipler, eylem maddeleri belirsiz, atanmamış ve izlenmiyor olduğunda takip konusunda başarısız olur. 2023 Scrum Alliance anketi, ekiplerin yalnızca %35'inin retrospektiflerinden gelen eylem maddelerini tutarlı bir şekilde tamamladığını bulmuştur. Diğer %65'i, asla üzerinde harekete geçmedikleri içgörüler üretiyor ve bu, hiç konuşmamanın olmadığından daha kötüdür. Bu ekibe retrospektifler değişime yol açmadığını öğretir.

Eylem Maddelerinin Mezarlığı

Sorunu düzeltmeden önce, retrospektif eylem maddelerinin neden öldüğünü anlamak yardımcı olur. Dört tutarlı örüntü vardır.

Sahip Yok

"Kod incelemelerimizi geliştirmeliyiz" tahtaya gelir. Herkes başını sallıyor. Kimse bunu gerçekleştirmekten sorumlu değildir. Yanında bir ad olmadan, bir eylem maddesi istektir, taahhüt değildir.

Çok Belirsiz

"Daha iyi iletişim kurmak" kimsenin üzerinde hareket edebileceği bir şey değildir. Daha iyi ne demek? Neyle ilgili iletişim kurmak? Kimle? Belirsiz eylem maddeleri başlatılamaz çünkü kimse ilk adımın nasıl göründüğünü bilmiyor.

Çok Iddialı

"Dağıtım ardışık düzenini yeniden yazmak" bir eylem maddesi değil, bir projedir. Kapsam tek bir sprint için çok büyük olduğunda, ekip ya hiç başlamıyor ya da yarıda bırakıyor çünkü diğer işler öncelik alıyor.

İzleme Yok

İyi yazılmış eylem maddeleri bile izlemek için bir sistem olmadığında kayboluyor. Kimsenin açmadığı toplantı notlarında yaşıyorlar veya silinen bir beyaz tahtada. Görünürlük olmadan hesap verebilirlik yoktur.

Bir Eylem Maddesini İş Yapılabilir Yapan Nedir

İş yapılan bir eylem maddesi ile yapılmayan bir arasındaki fark genellikle dört özelliğe iner. Hedef belirleme için SMART hedef çerçevesini kullandıysanız, aynı ilkeler burada da geçerli olup sprint boyutlu çalışmaya ölçeklenmiştir. İşte basit bir test: yeni bir ekip üyesi eylem maddesini bağlam olmadan okusaydı, tam olarak ne yapacağını, kimin bunu yapacağını ve ne zaman biteceğini biliyor mu? Değilse, daha keskin olması gerekir.

Öncesi ve Sonrası: Belirsiz vs. İş Yapılabilir

İşe yaramaz bir eylem maddesi ile kullanışlı bir arasındaki boşluk genellikle sadece birkaç ek sözcüktür. Gerçek örnekler aşağıda verilmiştir.

Belirsiz Eylem Maddesi	İş Yapılabilir Sürüm
Kod incelemelerini geliştir	Çarşambaya kadar PR şablonuna 5 maddelik bir kontrol listesi ekle, atanan: Sarah
Tıkanıklıklar hakkında daha iyi iletişim kurmak	Tıkanıklıkları #dev-blockers Slack kanalına karşılaştıktan 1 saat içinde yayınla, bu sprintten başlayarak, atanan: tüm ekip
Kararsız testleri düzelt	CI'daki en kararsız 3 testi sprint sonuna kadar tanımla ve düzelt, atanan: James
Daha iyi planla	Salı günü sprint planlama öncesinde ürün sahibi ile birlikte ilk 5 backlog öğesini gözden geçir, atanan: Maria
Toplantıları azalt	Çarşamba senkronizasyonunu iptal et ve 2 sprint boyunca bir deneme olarak Slack'te asenkron bir güncellemeyle değiştir, atanan: Alex

Deseni fark edin. Her iş yapılabilir sürüm üç soruyu yanıtlar: kim ne ne zaman yapacak. Bu tek şablon çoğu retrospektif çıktısını dönüştürür.

Daha İyi Eylem Maddeleri Oluşturma Teknikleri

Spesifik, atanmış, zamana sınırlı eylem maddelerine ulaşmak tesadüfen olmuyor. Bu teknikler bunu retrospektif akışının doğal bir parçası yapar.

"Kim ne yapacak ne zaman" şablonunu kullanın

Ekip bir sorunu tartıştıktan ve bir yöne karar verdikten sonra, eylem maddesini henüz yazmayın. Bunun yerine, yüksek sesle üç soru sorun:

1. Kim bunun sahibi olacak?
2. Ne yapacaklar?
3. Ne zaman biteceğini?

Eylem maddesini yalnızca üçünün yanıtlandıktan sonra yazın. Bu, madde başına 30 saniye sürer ve çoğu belirsiz taahhüdü ortadan kaldırır. Pek çok retrospektif şablonu artık bu üç elemanı yakalamak için ayrılan bölümler içerir, bu da formatı tutarlı tutar.

Sadece Sorunlar Değil, Eylem Maddelerine Oy Verin

Çoğu ekip sorunları önceliklendirmek için nokta oylaması kullanır. Ama en büyük sorunu tanımlamak iyi bir çözüm garantilemez. Bunun yerine, her ilk sorun için iki veya üç aday eylem maddesi oluşturun, ardından ekibin hangi eylem maddesine bağlı olmak istediğine oy verin. Bu, enerjisini "ne yanlış" tan "bunu nasıl düzelteceğiz"e kaydırır ve burada bir retrospektifin gerçek değeri yatmaktadır.

Retrospektif başına 1-3 Eylem Maddesine Sınırlandırın

Bu sezgisel olmayan bir durum, ama daha az eylem maddesi daha fazlasının yapılması anlamına gelir. Bir ekip yedi eylem maddesinden bir retrospektiften çıktığında, bilişsel yük çok yüksektir ve hiçbiri dikkat almaz. İki tane olduğunda, ekip gerçekten odaklanabilir. Retrospektiflerinizin Kadansı burada da önemlidir. Her sprintte retrospektif yapan ekipler yineleme için daha fazla fırsata sahip olduğundan, her bireysel retrospektif daha az maddede odaklanabilir.

İzleme Takibinin Yapılması

İyi eylem maddeleri yazmak sorunun yarısı. Diğer yarısı, retrospektifler arasında kaybolmadıklarından emin olmaktır.

Önce Geçen Sprintin Maddelerini Gözden Geçirin

Her retrospektifi, önceki sprintten eylem maddelerini inceleyerek başlatın. Her biri için sorun: yapılmış mı? Evet ise, yardımcı oldu mu? Değilse, neden? Bu bir geri bildirim döngüsü oluşturur. Ekip eylemlerinin iyileştirmeye yol açıp açmadığını görüyor ve bu bir sonraki sefer daha iyi takip etmeyi motive ediyor. Ayrıca sistematik engelleri ortaya çıkarır. Aynı eylem maddesi art arda üç sprint boyunca devrediliyorsa, ekip onu daha küçük adımlara bölmesi veya bunun gerçek bir öncelik olmadığını kabul etmesi gerekir.

Eylem Maddelerini Sprint Sırasında Görünür Yapın

Eylem maddeleri ekibin zaten çalıştığı yerde yaşamalıdır. Bunları sprin panosuna ekleyin. Bunları biletler olarak ekleyin. Sabitlenmiş bir Slack mesajına koyun. Mekanizm görünürlükten daha az önemlidir. Ekibin eylem maddelerini araması gerekiyorsa, onlar bunu yapmayacaklar. Bazı ekipler retrospektif eylem maddelerini doğrudan sprint planlama backloglarına ekleyerek bunları birinci sınıf iş öğeleri olarak ele alırlar. Bu etkilidir çünkü ekibi iyileştirme çalışmasını kapasitesine dahil etmeye ve düzenli teslimat çalışmasının üstünde olmasını umut etmeye zorlar.

Eylem Maddelerini Kendi Yapılmış Tanımınıza Yerleştirin

Retrospektif eylem maddesi "tüm PR'ler en az iki gözlemciye ihtiyaç duyar" gibi yeni bir ekip standardı oluşturduğunda, bunu hazır tanımı kontrol listenize ekleyin. Bu, tek seferlik bir iyileştirmeyi kalıcı bir süreç değişikliğine dönüştürür. Eylem maddesi, DoD güncellendiğinde ve ekip bunu takip etmeye başladığında yapılmış olur.

1. Retrospektif Sonu: Eylem Maddesini Yazın

   Kim/ne/ne zaman şablonunu kullanın. Bir sahip atayın. Sprint içinde bir son tarih belirleyin.

2. Sprint Planlama Sırasında: Pano'ya Ekleyin

   Retrospektif eylem maddelerini sprint çalışması olarak işleyin. Panoda değilse, gerçek değildir.

3. Sprint Ortasında: Kontrol Edin

   Sahip, stand-up veya asenkron kontrol sırasında hızlı bir durum güncellemesi verir. Yolunda mı?

4. Sonraki Retrospektif: Gözden Geçirin ve Kapatın

   Sonraki retrospektifi eylem maddesini gözden geçirerek başlatın. Yapılmış olarak işaretleyin veya neden sıkışıp kaldığını tartışın.

Eylem Maddeleri Başarısız Olmaya Devam Ettiğinde

Ekip, onları iyi yazmasına ve takip etmesine rağmen tutarlı bir şekilde eylem maddelerini tamamlamaması durumunda, temel neden genellikle üç şeyden birisidir. Ekip aşırı yüklenmiş. Her sprint sınıra kadar dolu olduğu için iyileştirme çalışması için kapasite yok. Çözüm: sprint kapasitesinin %10-15'ini retrospektif eylem maddelerine ve teknik borca açıkça ayırın. Bir umut değil bir politika yapın. Eylem Maddeleri Yeterince Önemli Değil. Devamlı olarak düşük önceliklendiriliyorsa, asında eylem maddeleri olmamalıydılar. Retrospektif hafif bir rahatsızlık ortaya çıkardı, gerçek bir sorun değil. Daha iyi problem tanımlanması, insanların tamamlamaya gerçekten önem verdiği eylem maddelerine yol açar. Kimse Mülkiyeti Hissetmiyor. Bu genellikle daha derin psikolojik güvenlik sorununu işaret eder. İnsanlar süreci değiştirmeye yetkili hissetmiyorsa, rakip öncelikler ortaya çıktığında eylem maddeleri için savaşmayacaklar. Fasilesiyanın işi, eylem maddelerinin gerçek satın almaya sahip olduğundan emin olmaktır, sadece nazik anlaşma değil.

Eylem Maddeleri İçin İnşa Edilmiş bir Retrospektif Çalıştırma

İşe yarar çıktılar doğal olarak üreten hafif bir format aşağıdadır. Retrospektif şablonunuz ile son adım olarak çalışır. Her şey 60 dakikalık bir zaman kutusuna sığar ve ekip iyi niyetli bir listeyle değil somut, atanmış, izlenen taahhütlerle çıkar.

Başlarken

Retrospektifleriniz hiçbir yere gitmeyen eylem maddeleri üretiyorsa, sürecin tamamını bir defada yeniden yapılandırmayın. Bir değişiklikle başlayın: sonraki retrospektif sonunda, ilk eylem maddesini alın ve kim/ne/ne zaman filtresi aracılığıyla çalıştırın. Bir ad atayın. Bir tarih belirleyin. Sprint panosuna ekleyin. Sonra aşağıdaki retrospektifi yapılmış olup olmadığını sorup açın. Bu tek döngü, onu açık bir şekilde yazın, izleyin, gözden geçirin temelin temelidir. Ekip retrospektif kararlarının gerçekten değişime yol açtığını gördüğünde, retrospektif içindeki konuşmaların kalitesi iyileşecektir. Bir sonuç olarak birşey olacağına inandıklarında insanlar daha iyi sorunlar ortaya koydular. Retrospektifleriniz ürettikleri değişiklikler kadar değerlidir. Bu değişiklikleri belirgin, atanmış ve görünür yapın ve retrospektif takvimindeki en üretken toplantı haline gelir.