"Retro gereksizdir": Nasıl tepki verileceğine dair 7 ipucu

Birçok kişi retrospektifin çevik araç kutusundaki en önemli tören olduğunu söyler. Woody Zuill bunu şu şekilde ifade ediyor: 

Eğer sadece bir #agile uygulaması başlatacaksanız, bu retrospektifler olmalıdır. Diğer her şey onu takip edecektir.

Woody Zuill

Peki bir geliştirme ekibinin sprint retrospektifini gereksiz görmesi neden mümkün olabilir? Bir Scrum Master ve psikolog olarak deneyimlerime göre, bu genellikle ekibin olgunluk seviyesiyle ilgilidir.

Peki, takımınızın olgunluğunu artırmak için neler yapabilirsiniz - bu bağlamda ve genel olarak? İşte bu zorluğun üstesinden gelmenize yardımcı olacak 7 düşünce, 7 ipucu.

Ekip retrospektifin gereksiz olduğunu düşünüyor: ne yapmalı?

Bu arada, Scrum sertifika sınavına göre resmi cevap şudur: Scrum Master, ekibi daha verimli hale getirmek için ekip üzerinde çalışmalıdır. Mh, bu gerçekten yardımcı olmuyor. Bununla ne kastediliyor olabilir?

Scrum Master, ekibi daha verimli hale getirmek için ekip üzerinde çalışmalıdır

Bir Scrum Master’ın resmi rolü aşağıdaki gibidir, eğer bakarsanız Scrum Kılavuzu bakıyor: “Scrum Master, Scrum Ekibini, bir sonraki Sprint için daha etkili ve keyifli hale getirmek amacıyla, Scrum süreci çerçevesinde geliştirme sürecini ve uygulamalarını iyileştirmeye teşvik eder.”

Teoride bu, retrospektifin Scrum Master’ın merkezi bir etkinliği olması gerektiği anlamına gelir, çünkü retrospektifin temel amacı ekibin sürekli olarak gelişmesine yardımcı olmaktır. Ancak pratikte, ekip bir retrospektiften gerçekten yararlanacak olgunluğa sahip olmayabilir ve bu nedenle değerini görmez. Bu nedenle, kişisel olarak “ekibi daha verimli hale getirmek” ifadesini soyut bir düzeyde “ekibin olgunluğunu artırmak” olarak yorumluyorum. Bu bağlamda bunu nasıl yapabilirsiniz? İpuçlarına başlamadan önce, bir açıklama daha 🙂

Retro, kişi gerçekten sürekli geliştiğinde değerli kabul edilir. O zaman özerklik, öz-örgütlenme ve öz-yeterlilik hissi yüksektir. Bu da şu hipotezi doğurur: Retrospektiflerin algılanan kalitesi, bir ekibin (çevik) olgunluk seviyesi için en iyi göstergelerden biridir. 

Çevik olgunluğu ölçmek istiyorsanız, retrospektiflerin kalitesini bir gösterge olarak kullanmalısınız. Bu, “retrospektifin algılanan kalitesi” ile bir ekibin “Çevik Olgunluğu” arasındaki tipik zamansal ilişkidir.

Bu ilerleme aşağıdaki şekilde sağlanır: 

1. İlk retroslar gerçekleştirilir, önlemler yazılır. Şu duygu ortaya çıkar: Sonunda bir şeyler oluyor! 
2. Önlemler gerçek anlamda uygulanmıyor. Çok konuşuluyor ama çok az eylem var. 
3. Bir süre sonra hayal kırıklığı ya da basitçe “retro yorgunluğu” ortaya çıkar. Şimdi bu makalenin olgusu ortaya çıkıyor: Retrospektif gereksiz olarak görülür. Ekibin kendisi kendisini nispeten olgun olarak algılar ve hiçbir sorun görmez.
4. Bu noktaya yalnızca birkaç ekip ulaşır. Yani, retrosun kalitesi tekrar arttığında ve sonuçta gözle görülür iyileşmelere yol açtığında ve böylece öz yeterlilik duygusu yavaş yavaş olgunlaşır. 

Umarım bu metinde yer alan ipuçları bu yönde birkaç adım atmanıza yardımcı olur. Bununla birlikte, şu metnimizi de şiddetle tavsiye edebilirim “ İyi Eylem Maddeleri için 7 İpucu %E2%80%9D, bu konuda başka bir rol oynuyor.

1. Ekibin neden bir retrospektifin gereksiz olduğunu düşündüğünü anlamak

Bir Scrum Master olarak, ekibin sprint retrospektifinin neden gereksiz olduğunu düşündüğüne dair bir hipoteziniz olabilir. Ancak lütfen bu hipotezi test edin. Ekibe arka plan hakkında açıkça soru sorun.

Çoğu zaman, ekip üzerinde büyük etkisi olan bir “kanaat önderi” vardır. Bu kişiyi seçmeye, bakış açısını anlamaya ve en iyi ihtimalle onunla birlikte karşı önlemleri tasarlamaya çalışın (aşağıya bakın).

Ekibi ne kadar iyi anlarsanız, ekibin olgunluğunu artırmak için o kadar iyi bir plan geliştirebilir ve aşağıdaki ipuçlarından en uygun olanını seçebilirsiniz.

2. geriye dönük incelemenin gerçekleştirilmesi

Temel olarak retrospektifi yapmalısınız. Diyelim ki ekibin Sprint hedefine ulaşması için daha fazla zamana ihtiyacı var ve retro yerine bir saatlik kodlama belirleyici olabilir. Bu durumda, retrospektifi birkaç gün ertelemek sorun değil.

Ayrıca retrospektifin yapısını değiştirebilir, daha kısa hale getirebilir vb. Ancak ekibe retrospektifin değerini göstermenin en iyi yolu gerçekten iyi bir retrospektif yapmaktır. Bu yüzden benim çağrım, ekip takviminizde retrospektif için bir yer ayırdığınızdan emin olun.

3. ROTI değerini ölçün

Ölçmediğiniz şeyi değiştiremezsiniz. Ekibin Retroları nasıl algıladığını sürekli olarak değerlendirmenize yardımcı olacak basit ve hızlı bir alışkanlık, ROTI puanını ölçmektir: “Yatırılan zamandan geri dönüş” değeri. Her retrospektiften sonra, belki de bir çıkış olarak şu soruyu sorun: “0’dan 10’a kadar bir ölçekte, bu retrospektif için harcanan zaman ne kadar iyi değerlendirildi?”. Zaman içindeki ortalamayı ölçün - umarım yakında olumlu bir eğilim görebilirsiniz!

Echometer Aracı’nda aylık ortalama 0 ila 10 ölçeğinde “Zaman Yatırımının Geri Dönüşü” puanı - Retrolar işe yarıyor mu? Öyle görünüyor!

4. Sprint retrospektifinizi çok kısa tutun

Geliştirme ekibi Sprint Retrospektifini gereksiz buluyor - bir Scrum Master olarak şimdi ne yapmalısınız?

Başta da belirttiğim gibi, ekip muhtemelen sprint retrospektifinin gerekli olmadığını düşünüyor çünkü bunun zaman kaybı olduğunu düşünüyorlar.

Başka bir deyişle: Son retrospektiflerde, bir retrospektifin ROTI’sinin - yani yatırılan zamanın kalitesinin, yukarıya bakın - oldukça kötü olduğunu “öğrenmişler”. Bunu değiştirmenin oldukça basit bir yolu var: aynı çıktıyla daha az zaman harcamak 🙂

Bu, ekip Sprint Retrospektifini gereksiz buluyorsa belki de en iyi ipucudur. Ekibinize şunu söyleyin: Tamam, onu olabildiğince kısa tutacağız (blog yazımızda daha fazlası var “ Kısa geçmişe bakış - çabuk olması hiç olmamasından iyidir ”). 

Önemli: Sonsuza kadar böyle kalacağının sinyalini vermek istemezsiniz. Mesajınız aynı kalacaktır: Retrospektifler gerçekten önemlidir. Er ya da geç, retrospektifler artık bu kadar kısa olmayacak.

Ancak retrospektifi kısaltıyorsunuz (örneğin 60 dakikadan 30 dakikaya), çünkü ekip bu şekilde zaman ayırmanın ne kadar önemli olabileceğini öğreniyor. Ve retrospektifin uzunluğunun, ekibin bir “çekme” veya “isteği” yoluyla neredeyse “organik” olarak büyümesine izin veriyorsunuz, çünkü bir noktada retrospektif için daha fazla zaman isteyecekler. Bu nasıl yapılır? 

Siz sadece en önemli soruyu soruyorsunuz:

“Neden son yineleme için belirlenen tüm Kullanıcı Hikayelerini tamamlayamadık?”

Bu, kısa sürede bazı yoğun tartışmalara ve muhtemelen eylem fikirlerine yol açacaktır. Hatta daha uzun tartışmalara bile yol açabilir. Ve ekip şimdiden geriye dönük bir inceleme için daha fazla zamana ihtiyaç duyduklarının sinyalini verdi (tabii ki tartışmayı yapıcı tutmak sizin göreviniz).

Her zaman ekipte iyi düşünceleri veya tartışmaları tetikleyeceğini düşündüğünüz soruyu sormalısınız. Ve her zaman bir sonraki sprintte deneyeceğiniz bir deneyi kaydetme hedefiniz olmalıdır (eylem maddesi olarak da bilinir).

5. Diğer rutinlerin de çıkarılmasını önerin

Yani ekip, geriye dönük bir incelemenin zaman kaybı olduğunu düşünüyor. Tamam. Bir Scrum Master olarak ana hedefiniz asla Scrum’ı uygulayan kişi olmak olmamalıdır. Hayır, mesele “Scrum” değil. 

Bu, ekibin başarılı olması ve müşteriye ve paydaşlara değer sunmasıyla ilgilidir. Scrum’ın ekibin bunu yapmasına yardımcı olması beklenir. Ancak bu sadece bir çerçeve, değeri hızlı, sürdürülebilir ve yüksek kalitede sunmak için birçok olası yaklaşımdan oluşan bir araç kutusu (oldukça iyi bir tane).

Dolayısıyla, ekip retrospektif konusunda memnun değilse, Scrum’a az önce açıklanan perspektiften baktığınızı vurgulayabilirsiniz. Ve sonra da sahip olduğunuz diğer rutinlerden bazılarının aslında retrospektiften daha az önemli olduğunu düşündüğünüzü ekleyebilirsiniz. 

Retrospektif, sürekli iyileştirmenin motorudur. Ekip üyelerinin neyin iyi çalıştığını ve neyin çalışmadığını bulmalarına yardımcı olmak için tasarlanmıştır. Sürekli döngünün bu kısmını dışarıda bırakırsanız, sürekli iyileştirme döngüsünü durdurma riskiyle karşı karşıya kalırsınız.

Örneğin, birkaç Günlüğü atlarsanız ne olur? Ne olacağını biliyor musunuz? Belki hiçbir etkisi olmayacak - mükemmel, o zaman hemen böyle bırakabilir ve zamandan tasarruf edebilirsiniz. 

Öte yandan, bu durum ekip içinde daha zayıf bir iletişime de yol açabilir. Ekip bu nedenle hatalar yapar. Sonunda, daha fazla iletişim için organik bir ihtiyaç olacaktır ve bunu retrospektifte fark edeceksiniz. Ancak bu kez, çevik bir tören sizin ısrarınızla değil, ekibin “acısı” nedeniyle başlatılır. Sonuç olarak, ekipte bu seremoni için çok daha fazla kabul olacaktır.

6. Geçmiş retrospektiflere bakın ve bunların değerini gösterin

Diğer yaklaşımları tamamlayabilecek bir yaklaşım, ekibin daha uzun bir süre boyunca “geçmişe dönük tarihine” bakmaktır. Bunun ön koşulu, son retrospektiflerden bazılarının başarılı olmasıdır.

Örneğin, bir yıl öncesinin retrospektifine bakarsınız ve geçen yıl bu zorlukların ne kadar zor olduğunu fark edersiniz. Ve sonra, edindiğiniz tüm bilgi ve deneyime sahip olsaydınız bugün aynı zorlukları çözmenin çok daha kolay olacağını fark ediyorsunuz.

Başka bir deyişle: Bu arada ne kadar geliştiğinizi fark ediyorsunuz. Belki de bu “sürekli iyileştirme” yaklaşımı işe yarayabilir?! Ve retrospektifler bu konuda gerçekten büyük bir rol oynamış olabilir. Doğru kullanıldığında, bu ekipte bir “aha” anına yol açabilir.

Buna ek olarak, son retrospektifinizin ROTI (zaman yatırımı getirisi) değerine de bakabilirsiniz (yukarıya bakın): Eğer retrospektifin ROTI değerinin 8 ila 10 arasında olduğunu kanıtlayabilirseniz, o zaman iyi bir yatırım yapmışsınız demektir. Örneğin retrospektif aracımız Echometer, her retrospektiften sonra ROTI’yi sorgular ve böylece size ilgili performansın düzenli bir göstergesini verir. Scrum Master olarak performansınız .

7. retrospektifinize daha fazla çeşitlilik getirin

“Geliştirme ekibi sprint retrospektifini gereksiz buluyor - Scrum Master ne yapmalı?” sorusuna verilen tipik cevaplardan biri, yöntemlerinize daha fazla çeşitlilik getirerek ve onları daha eğlenceli hale getirerek retrospektifi daha üretken ve heyecanlı hale getirmektir. Her zaman “eğlencenin” o kadar önemli olmadığını, odağın hala onu üretken hale getirmek olması gerektiğini vurguluyorum. Yine de, eğlence elbette bir miktar yaratıcılık ve motivasyonu tetikleyebilir. 

Bu, bir yandan yaratıcı retrospektif yöntemleri kullanabileceğiniz anlamına gelir - örneğin, aşağıdaki gönderimize bakın: 32 Yeni başlayanlar ve profesyoneller için retrospektif yöntemler -, yani yeni düşünce ve fikirleri tetikleyen açık sorular şeklindeki metaforlar.

Öte yandan, tipik retrospektifin ötesine geçen ancak yine de ekibi geliştirmeyi amaçlayan yöntemler de kullanabilirsiniz. Örneğin, aşağıdaki konulara odaklanan bir retrospektif/ekip çalıştayı düzenleyebilirsiniz psi̇koloji̇k güvenli̇k ekipte geliştirildi - başarılı ekipler için temel ön koşullardan biri. 

Veya retrospektifinize sürekli olarak bilimsel olarak sağlam sorular ekleyen Retro Tool Echometer’imizi kullanın. Ekibin, başarılı ekiplerin temel özelliklerini ne ölçüde karşıladığını düşünmesine yardımcı olurlar. İşte aracımızdaki sorulardan birine bir örnek, başarılı ekipler için bir başka ön koşul - sağlıklı bir geri bildirim kültürü:

Ne kadar iyi performans gösterdiğim ve kendimi nasıl geliştirebileceğim konusunda düzenli olarak faydalı geri bildirimler alıyorum.

Retrospektiflerde tartışılan Echometer aracının bir dürtü örneği.

Retrolarınıza çeşitlilik katmanın birçok başka yolu vardır - yaratıcı olmaktan çekinmeyin. 

Dediğim gibi, ekibin sprint retrospektifini “neden” gereksiz bulduğuna bağlı olarak, daha fazla çeşitlilik muhtemelen sorunu çözmek için tek önlem olmamalıdır.

”Gereksiz Retrolar” hakkında sonuç

Gördüğünüz gibi, 7 ipucu ve eylem bu zorluğu farklı düzeylerde ele almaktadır. Eğer tek bir ipucu vermem gerekseydi, o da yukarıda ana hatlarıyla belirttiğim gibi geriye dönük incelemeyi akıllı bir şekilde kısaltmak olurdu. Tüm bu önlemleri birleştirirseniz, sonuçları kesinlikle çok yakında göreceksiniz. 

1TP17Sürekli İyileştirme çalışmanızda iyi eğlenceler!