İçeriğe geç

Sprint Retrospective Meeting

Scrum ekibi işinde uzman ve tecrübeli kişilerden oluşsa bile, süreci her zaman geliştirmeye ve iyileştirmeye ihtiyaç vardır. Ekip, süreç boyunca gerçekleştirilen sprintlerin sonunda, işi nasıl yaptıklarını değerlendirmeli, daha iyi ve efektif olanı yakalamak için iyileştirme yolları aramalıdır. Scrum’da ekip bu çalışmayı Sprint Retrospective Toplantısı’nda gerçekleştirir.

Sprint Retrospective Toplantısı, her bir sprint döngüsünün sonunda yapılmalıdır. Yani gerçekleştirilen sprint için yapılması gereken son çalışmadır. Bu toplantıya Scrum Master ve Product Owner dahil olmak üzere tüm ekip katılmalıdır. Scrum bu çalışmanın 1 aylık bir sprint süresi için maksimum 3 saat ile sınırlandırmıştır. Bu süre toplantı sırasında konuşulan konuya göre daha kısa da sürebilir. Zaman zaman önemli konular gündemde olduğunda veya takım içindeki çatışmalar retrospektif toplantısını çok daha uzun sürmesine neden olabilir. Bu durumda timeboxed süresi unutulmamalıdır.

Sprint Retrospective Teknikleri

Scrum ekibinin süreçlerini iyileştirmek için yaptıkları Sprint Retrospective toplantılarında uygulanabilecek bir çok teknik vardır. Ekip, takım üyelerine ve/veya sürece göre hangi tekniğin uygun olduğunu belirlemeli ve uygulamalıdır. En çok kullanılan teknikleri listeleyecek olursak;

  • Start – Stop – Continue
  • Sailboat
  • Mad – Sad – Glad
  • 4Ls (Liked – Learned – Lacked – Longed For)
  • KALM (Keep – Add – More – Less)

Diğer retrospektif tekniklerini ve açıklamalarını bu linkten inceleyebilirsiniz.

Start-Stop-Continue Tekniği

Scrum ekiplerinin genellikle tercih ettiği ve en etkili yol Start-Stop-Continue tekniğidir. Bu teknik ile yapılan retrospektif çalışmasında, her bir ekip üyesine bundan sonra ekibin neleri yapması gerektiği sorulur ve şu başlıklar altında listelenmesi beklenir;

  • Start Doing – Yapmaya başla
  • Stop Doing – Yapmayı bırak
  • Continue Doing – Yapmaya devam et

Sprint Retrospective | start-stop-continue

Start Doing: Scrum ekibinin süreçlerine eklenmesi gerektiğini düşündüğü kararlardır. Bu kararlara örnek vermek gerekirse;

  • Daily Scrum’lara zamanında katıl,
  • Kabul testlerini müşteriye erken çık,
  • Kodda refaktoring yap

Stop Doing: Scrum ekibinin verimsiz ve/veya boşa zaman harcadığını ve süreçlerden çıkarılması gerektiğini düşündüğü kararlardır. Bu kararlara örnek vermek gerekirse;

  • Tüm testlerden geçmeden kodu denetleme
  • Daily Scrum’a 15 dakikadan fazla zaman ayırma
  • Bir hikayenin geliştirmesi bitmeden, bir sonrakine başlama
  • Sprint sonuna doğru geride olduğunu hissettiğinde, Backlog Grooming’i atlama

Continue Doing: Scrum ekibinin vurgulamaya devam etmek istediği kararlardır. Bu kararlar henüz bir alışkanlık haline gelmemiştir bu yüzden continue listesindedir. Bir kaç Sprint daha tecrübe edilmesi gerekir. Dolayısıyla, bu kararlar ileride sağladığı verime göre Start Doing veya Stop Doing listesine eklenebilir.

Scrum Master retrospektif toplantılarında takım üyelerini yönlendirmelidir. Onlara bu listeyi oluşturmasında yardımcı olmalı, her bir üyenin görüşlerini almalıdır. Ayrıca önceki retrospektif toplantılarında alınan kararların sürece uyarlanmasını takip etmeli ve ekibin bu kararlara odaklanmasını sağlamalıdır.

Oylama (Vote)

Takım üyelerinden gelen tüm önerilerin karar listelerine alınması gerekmez. Listedeki önerilerin herkesçe kabul görmesi için Scrum Master bu önerileri oylamaya sunabilir. Özellikle yaratıcı ve yeni önerilerin gelmesi azaldığı zaman oylama çalışmasını yapmak, daha sağlıklı kararlar almayı sağlayacaktır.

Oylama çalışmasında Scrum Master’ın önemli bir rolü vardır. Scrum Master’ın bu çalışma için uygulayacağı yöntem, alınacak olan kararların ne kadar sağlıklı olacağına direk etki eder. Örneğin, takım üyelerinden sadece en önemli gördükleri öneriye oy vermelerini isteyebilir. Veya her bir takım üyesine 3 oy hakkı vererek çoklu oy kullanlamalarını sağlayabilir. (Kişi isterse bu 3 oy hakkını tek bir öneri için kullanabilir. :))

Sonraki Retrospektifler

Sprint Retorspective toplantılarında Scrum Master’ın toplantıyı ve süreci takip etmesi, takım üyelerinin aldığı kararlar kadar önemlidir. Önceki retrospektifte alınan kararların listesi sonraki toplantılarda Scrum Master tarafından taşınması gerekir.

Önceki belirlenmiş kararlar sadece Scrum Master değil tüm ekip tarafından takip edilmesi gerekir. Bu kararları herkesin görebileceği büyük bir kağıt veya bir panoda olması önerilir. Böylece ekipteki herkes ihtiyaç duyduğunda buraya kolayca bakabilir.

Sprint Retrospectives vs Lessons Learned

Bu iki aktiviteyi, müşteriye sunulan çıktı sonrasındaki değerlendirme çalışması olarak gördüğümüzde birbirine benzer özellikler taşırlar. Ama bütünüyle baktığımızda oldukça farklı olduklarını görebiliriz.

En önemli farklarında biri, retrospektif toplantılarında ekip için, lessons learned toplantılarında geliştirilen proje için iyileştirme yöntemleri aranır. Bu iki aktiviteyi karşılaştıracak olursak;

Scrum – Sprint Retrospective

Project Management – Lessons Learned 

Çevik değer ve ilkelerine göre ekibe odaklı bir aktivitedir. Çevik geliştirmeye uygun olmayıp projeye odaklı bir öğrenme aktivitesidir.
Karşılaşılan engelleri (impediments) hemen çözmek üzerine tasarlanmıştır. Geliştirilen projede karşılaşılan engellerin gelecekteki projelerde tekrarlanmaması için süreç ve prosedürlere eklenmek üzere belgelenen bir proje kaydıdır.
Amaç, ekip içerisinde sorunları basitçe çözmektir. Ekip ilişkilerini iyileştirmek için dizayn edilmemiştir.
Her Sprint sonunda yapılır. Proje bitince, ekip dağılmadan önce yapılır.
İyileştirme sürekli olarak gerçekleşir. İyileştirme toplu olarak gerçekleşir.
Ekip içindeki güveni sağlamaya odaklıdır. Gelecekteki başarısızlıklardan kaçınmaya odaklıdır.
Ekibin kendi kendine yön vermesini destekler. Genellkle yönetici ve/veya liderler önderliğinde kararlar alınır.

 

 

Aşağıda Retorspektif ile ilgili diğer detaylara ulaşabileceğiniz birkaç kaynak paylaşıyorum. Mutlaka sizlere de faydalı olacaktır.

 

İlkim Dilara KADAKALOĞLU

Tarih:ScrumScrum Meetings

İlk Yorumu Siz Yapın

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

%d blogcu bunu beğendi: