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 bu bağlamda ve genel olarak ekibinizin – olgunluğunu artırmak için ne yapabilirsiniz? İşte size bu konuda 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 "Scrum Ustası, Scrum Ekibini bir sonraki Sprint için daha etkili ve eğlenceli hale getirmek üzere Scrum süreci içindeki geliştirme süreçlerini ve uygulamalarını geliştirmeye teşvik eder."

Teoride bu, retrospektifin Scrum Master için merkezi bir etkinlik olması gerektiği anlamına gelir, çünkü retrospektifin temel amacı ekibin sürekli olarak gelişmesine yardımcı olmaktır. Ancak pratikte, ekip retrospektifi gerçekten kullanacak olgunluk seviyesine sahip olmayabilir ve bu nedenle değerini göremeyebilir. Bu nedenle ben şahsen "ekibi daha verimli hale getirmek" ifadesini soyut düzeyde "ekibin olgunluk düzeyini artırmak" olarak yorumluyorum. Bu bağlamda bunu nasıl yapabilirsiniz? Bununla ilgili ipuçlarına başlamadan önce, bir açıklama

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. 

Eğer – çevik olgunluk seviyesini ölçmek istiyorsanız, retrospektiflerin kalitesini bir gösterge olarak kullanmalısınız. Bu, "retrospektifin algılanan kalitesi" ile bir ekibin "Agilem olgunluk seviyesi" 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", bu konuda başka bir rol oynamaktadır.

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.

Genellikle ekipte, ekip üzerinde büyük etkisi olan bir "kanaat önderi" vardır. Bu kişiyi belirlemeye çalışın, bakış açısını anlayın ve en iyi ihtimalle onunla birlikte karşı önlemler tasarlayı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 hedefi –'ye ulaşmak için daha fazla zamana ihtiyacı var ve retrospektif yerine bir saatlik kodlama çok önemli olabilir. Bu durumda, retrospektifi birkaç gün ertelemenizde bir sakınca yoktur.

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 bir şeyi değiştiremezsiniz. Ekibin retrospektifi nasıl algıladığını sürekli olarak değerlendirmenize yardımcı olacak basit ve hızlı bir alışkanlık, ROTI skorunu ölçmektir: "yatırılan zamanın geri dönüşü" değeri. Her retrospektiften sonra, belki de bir check-out olarak şu soruyu sormanız yeterlidir: "0 ile 10 arasında bir ölçekte, bu retrospektif için harcanan zaman ne kadar iyiydi?". Zaman içindeki ortalamayı ölçün – umarım yakında olumlu bir eğilim göreceksiniz!

Echometer aracı –'de aylık 0 ila 10 arasında bir ölçekte ortalama "yatırımın geri dönüş süresi" puanı buna değer mi? Öyle görünüyor!

4. Sprint retrospektifinizi çok kısa tutun

Geliştirme ekibi sprint retrospektifinin gereksiz olduğunu düşünüyor – 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, retrospektif –'nin ROTI'sinin, yani harcanan zamanın kalitesinin oldukça düşük olduğunu görünüşe göre "öğrendiler", bkz. yukarıda –. Bunu değiştirmek için oldukça basit bir yaklaşım var: aynı çıktı için daha az zaman harcamak.

Eğer ekip sprint retrospektifinin gereksiz olduğunu düşünüyorsa bu belki de en iyi ipucudur. Ekibinize şunu söyleyin: Tamam, bunu mümkün olduğunca kısa tutacağız (daha fazlasını blog yazımızda okuyun "Kısa geriye dönük – Hızlı 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ırsınız (örneğin 60 dakikadan 30 dakikaya) çünkü bu şekilde ekip zaman ayırmanın ne kadar önemli olabileceğini öğrenir. Ve retrospektifin uzunluğunun tabiri caizse ekipten gelen bir "istek" ya da "arzu" ile "organik" olarak artmasına izin verirsiniz, çünkü bir noktada retrospektif için daha fazla zaman isteyeceklerdir. Bunu nasıl yapacaksınız? 

Siz sadece en önemli soruyu soruyorsunuz:

"Son iterasyon için belirlenen tüm kullanıcı hikayelerini neden 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ük gazeteyi dışarıda bırakırsanız ne olur? Ne olacağını biliyor musunuz? Belki herhangi bir etkisi olmaz – mükemmel, o zaman aynı tutabilir ve zaman kazanabilirsiniz. 

Ö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 zaman dilimindeki "retrospektif geçmişine" bakmaktır. Bunun için ön koşul, 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 süre zarfında ne kadar geliştiğinizi fark edersiniz. Belki de bu "sürekli iyileştirme" yaklaşımı her şeye rağmen işe yarayabilir! Ve retrospektifler gerçekten de bunda büyük bir rol oynamış olabilir. Doğru kullanıldığında, ekipte kesinlikle 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.