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 etkinliğinde gerçekleştirir.
Sprint Retrospective, 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 etkinliğine 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 – Wind & Anchors
- Mad – Sad – Glad
- Starfish
- 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
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 kullanmalarını sağlayabilir. (Kişi isterse bu 3 oy hakkını tek bir öneri için kullanabilir. :))
Diğer teknikler için “Retrospective Teknikleri” kategorisini ziyaret edebilirsiniz.
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 Retrospective 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 Retrospektif ile ilgili diğer detaylara ulaşabileceğiniz birkaç kaynak paylaşıyorum. Mutlaka sizlere de faydalı olacaktır.
İlkim Dilara KADAKALOĞLU
d.
İlk Yorumu Siz Yapın