Bu Retrospective Toplantısı Hatalarını Yapıyor Musunuz?

Merhabalar, bu yazımızla birlikte artık Scrum metodolojisinin detaylarına, daha ileri seviye konulara, uygulanması veya uygulanmaması gereken pratiklere vs. değinmeye çalışacağız. Bu yazı serimizi eğitmenimiz Faisal Mahmood'un katkıları ile hazırlıyoruz. Kendisine bir kez daha teşekkür ederiz. Bu yazımızda Retrospective Toplantıları ile ilgili yapılan bazı yanlışlar üzerinde duracağız:

Sürekli gelişim, Agile metodolojilerin kalbidir. Retrospective Toplantıları, geliştirme takımlarına süreçlerini gözden geçirme ve süreçleri sürekli olarak iyileştirme fırsatı sağlar. Bir çok geliştirme takımı bu avantajı kullanma konusunda başarısız olurlar. Bu nedenle süreçlerini geliştirme konusunda da başarısız olurlar.

Ortak olarak karşımıza çıkan Retrospective toplantısı hatalarını şu şekilde sıralayabiliriz:
  1. Gelişim Aktivitelerini Dikkate Almamak
  2. Seyrek Düzenlenen Retrospective Toplantıları
  3. Takım Katılımındaki Eksiklik
  4. Retrospective Toplantısına Sadece Bir Kişinin Öncülük Etmesi
Şimdi gelin bu hataların detaylarını inceleyelim:

Gelişim Aktivitelerini Dikkate Almamak
Gelişim aktivitelerinin dikkate alınmaması en çok karşılaşılan Retrospective hatalarından birisidir. Takımlar Retrospective toplantısına katılıp, süreçlerini iyileştirmek üzere fikirler üzerine dinamik bir şekilde tartışmalar yürütürler. Bu tartışmalarda sürecin çalışan yönleri ve problemli yönleri konuşulur. Fikir üretmek için bir çok yöntem kullanılır. Bu sayede fikir noksanlığı yaşanmaz, aksine bir çok fikir ortaya atılır. Bu sayede takımlar Retrospective bir düzine fikir üzerine tartışma fırsatı bulurlar. Fikirlerin tartışılması sonrası toplantı sonlandırılır. Takım gelecek Sprint süresince aksiyon alacağı maddeleri seçmez. Ne Scrum Master, ne de Geliştirme Takımı, tartışılan fikirleri not almazlar. Fikirler ve alınacak aksiyonlar toplantıda bırakılır.

Sonuç olarak, takımlar Retrospective Toplantısı sonuçlarının, Sprint süresince herkes tarafından görünür olması konusunda başarısız olurlar. Geliştirme Takımı Sprint ile ilgili geliştirme yapmaya başladığında, Sprint Backlog'ta tanımlı görevler içinde boğulurlar. Takım üyeleri bu arada Retrospective toplantısında neler tartışıldığını unuturlar. Çünkü bütün dikkatlerini ellerindeki işlere vermişlerdir.

Takım bir önceki Retrospective Toplantısında tartışılan iyileştirme fikirlerini uygulamazlar. Bu senaryo bir kaç Sprint devam eder. Takım pratiklerini iyileştirme yönünden başarısız olur. Takım bu sırada Retropective Toplantılarının anlamsız olduğu kanısına varır ve bu toplantları düzenlememeye başlar.
Takımlar, bir çok koşulda, Retrospective Toplantılarında tartışılan bütün iyileştirme fikirlerini uygulamaya çalışırlar. Çok sayıdaki iyileştirme fikirleri, takımı bunaltır ve bu nedenle limitli bir iyileştirme sağlanmış olur.

Seyrek Düzenlenen Retrospective Toplantıları
Bir çok takım Retrospective Toplantılarını düzenlemezler. Çünkü Retrospective Toplantılarının sürekli iyileştirme ile ilgili getirdiği faydayı anlamamışlardır. Retrospective ile Review toplantılarını birbirine karıştırırlar. Takımlar, süreçle ilgili iyileştirme fikirlerini Review toplantılarında tartışırlar. Review Toplantısının kapsamını Retrospective Toplantısınınkiyle karıştırarak, etkin bir Review toplantısı düzenleme konusunda başarısız olurlar. Retrospective Toplantılarını ihtiyaç olması dahilinde -genellikle bir yaygınlaştırmanın (release) veya projenin sonunda- düzenlemeyi seçerler.

Bir projenin sonunda büyük bir Review (gözden geçirme) toplantısı düzenlemek, geleneksel geliştirme süreçlerinin bir pratiğidir. Bir çok organizasyon proje sonu gözden geçirmelerini, Sprint Retrospective Toplantıları ile karıştırmaktadırlar. Bu nedenle bu toplantıyı genellikle proje sonunda düzenlemeye karar verirler.

Takım Katılımındaki Eksiklik
Retrospective Toplantılarında tüm takım üyelerine ihtiyaç duyulmadığı ortak bir yanlış anlaşılmadır. Özellikle Product Owner rolündeki kişilerin bu toplantılara katılması, bir çok takım tarafından yararlı görülmemektedir. Üstelik zaman zaman, Product Owner'ların bu toplantılara katılması konusunda cesaretleri kırılır.

Product Owner, bir Scrum takımında zorunlu bir roldür. O'nun katılımı olmadan Retrospective Toplantısı düzenlemek, bu toplantıların etkinliğini kısıtlamaktadır. Product Owner'ın katılımı olmadan Product Backlog'un temizlenmesi, Sprint Planlama, Sprint Review ve Product Backlog maddelerinin detaylandırılması konularındaki iyileştirmeleri tartışmak zordur. Takımın iyileştirme konularını belirlerken ve iyileştirme önerileri üretirken, Product Owner'ların bu aktivitlere katılımı çok önemlidir ve zorunludur.

Retrospective Toplantısına Sadece Bir Kişinin Öncülük Etmesi
Bir çok örnekte görüldüğü üzere, Scrum Master'ların Retropective Toplantılarında geri planda durması zor olabilmektedir. Bu durum, Scrum Master'ların bu toplantılarda Takım'ın tartışması gerektiği konuları ve problemleri fark etmelerinden kaynaklanmaktadır. Bu nedenle Scrum Master'lar kendilerini, Retrospective işlerini kendi başlarına yapmak mecburiyetinde olduklarını hissederler.

Takımla birlikte çalışmak ve takımın fikir üretmesi için onlara klavuzluk/koçluk etmek yerine, bütün işi Scrum Master'lar kendi başlarına yaparlar. Süreçte iyi giden noktaları tanımlarlar. Süreçteki problemli konuların nasıl iyileştireceğini belirlerler. Sonrasında bu fikirleri, Retrospective Toplantısında takımla paylaşırlar. Böylece bu toplantılar Scrum Master'ların takıma sunum yaptığı bir ders havasına bürünür.

Sonraki yazılarımız da bu hataları nasıl ortadan kaldıracağımıza yönelik ipuçları üzerinde durmaya çalışacağız.

1 yorum: