Home Agile & Lean
Category:

Agile & Lean

Agile & Lean

Kanban Dönüşümünde Etkinlikler

by mlap
written by mlap

Daha önceki yazılarda vurguladığımız gibi Kanban dönüşümü evrenseldir. Temel amaç; Kanban pratikleri ile takımın israf noktalarını ve darboğazlarını görünür kılması, farkındalık sağlaması ve iyileştirmeler gerçekleştirmesidir.

Kanban evrimsel bir metot olduğundan ihtiyaçlara göre farklı etkinlikler düzenlenebilir. Ancak, Kanban pratiklerinin etkin uygulanabilmesi için özellikle aşağıdaki etkinlikleri önermekteyim:

Olmazsa Olmaz Etkinlikler

🔹 Retrospective

Woody Zuill’in ünlü sözüyle: “If you adopt only one Agile practice, let it be retrospectives. Everything else will follow.”

Retrospective, sektörden veya iş türünden bağımsız olarak periyodik şekilde sürecin değerlendirilmesi için kritik bir etkinliktir. Kanban takımlarında bu etkinlik, israfların görünür kılınması ve iyileştirme aksiyonlarının çıkarılması açısından büyük önem taşır. Düzenli yapılması, iyileşmenin alışkanlık haline gelmesini sağlar.

🔹 Daily Stand-up

Kanban’ın “Görselleştir, Akışı Yönet, Limitle” pratiklerinin sürdürülebilmesi için oluşturulan board’un günlük işletilmesi gerekir.

Takımın her gün 15 dakikalık bir toplantı ile bir araya gelmesi:

  • İletişimi güçlendirir,

  • Ortak hedefe odaklanmayı sağlar,

  • Board’un güncellenmesiyle değer akışının etkin yönetilmesine katkı sunar.

👉 Bu iki etkinliği (Retrospective ve Daily Stand-up) Kanban’ın olmazsa olmazları olarak görüyorum.

İhtiyaca Göre Yapılabilecek Etkinlikler

🔹 Review

Takımın yaptığı işleri paydaşlara aktarması ve geribildirim alması, ürünün kalitesi için kritik bir adımdır.

  • Her Kanban takımı, belli aralıklarla gösterilecek işler çıkaramayabilir.

  • Ancak, uygun dönemlerde yapılması hem takımı motive eder hem de ürünün daha kullanışlı hale gelmesini sağlar.

🔹 Refinement / Planlama / Replenishment

Bir işin öncelikli olarak ele alınması kadar, o işin netleştirilmesi ve risklerin değerlendirilmesi de önemlidir.

“El elden üstündür” atasözümüz burada çok anlamlıdır: Bildiğimiz konularda bile ekip üyelerinin yorumlarıyla yeni bakış açıları kazanılabilir. Bu nedenle işlerin birlikte refine edilmesi büyük fayda sağlar.

Ayrıca, hayatı çok hızlı değişen takımlarda planlanan işlerin gündelik hareketlilikte unutulabildiğini gözlemledim. Bu nedenle, önümüzdeki dönemin planlanması ve işlerin ortada kalmaması için bu etkinliklerin belli periyotlarla yapılması faydalı olur.

Kurumsal Dönüşümlerde Standartlaşma

Kurumsal dönüşümlerde, bazı etkinliklerin standart hale getirilmesi gerektiğini düşünüyorum. Kanban uygulayan takımlar için dönüşümü yönetenlerin, belirli etkinlikleri standartlaştırması hem uygulama kalitesini artırır hem de takımlar arası uyumu kolaylaştırır.

📌 Özet: Kanban dönüşümünde Retrospective ve Daily Stand-up düzenli yapılması gereken temel etkinliklerdir. Bunun yanında Review, Refinement ve Planlama gibi etkinlikler ihtiyaca göre uygulanmalı, ancak periyodik hale getirildiğinde daha güçlü sonuçlar elde edilecektir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Bir Sprintin Akışı

by mlap
written by mlap

Her sprint, Planlama ile başlar, Review ve Retrospective etkinlikleri ile tamamlanır.

Sprint Planlama

Toplantının ilk kısmında (NE ve NEDEN), Product Owner önceliklendirilmiş ve refine edilmiş Product Backlog üzerinden takıma yapılacak işleri aktarır. Takım, her bir backlog maddesinin büyüklüğünü tahminleyerek sprint boyunca taahhüt edeceği işleri belirler.

İkinci kısımda (NASIL), takım işlerin nasıl yapılacağına karar verir. Bu aşamada görselleştirme önemlidir:

  • Fiziksel ortamda: Flipchart veya beyaz tahta,

  • Online ortamda: Miro, Mural gibi dijital araçlar kullanılabilir.

Toplantının çıktıları:

  • Güncellenmiş Product Backlog,

  • Sprint Backlog,

  • Sprint Goal’dür.

Daily Scrum

Sprint boyunca her gün düzenlenen Daily Scrum, takım üyelerinin güncel bilgileri paylaşmasını ve günlerini planlamasını sağlar. Daily sonrası, burndown chart gibi metrikler güncellenir ve gerekli aksiyonlar değerlendirilir.

Refinement

Kaliteli bir planlama toplantısının ön koşulu, iyi yapılmış bir refinement sürecidir.
Refinement yalnızca bir etkinlik değil; Product Backlog Item’ların olgunlaşmasını sağlayan sürekli bir akıştır.

  • Sprint boyunca gerçekleştirilir.

  • Takım ve paydaşların haftada en az bir kez bir araya gelmesi, fikirlerin paylaşılması ve hizalanma sağlanması faydalıdır.

  • Bu yönteme incremental refinement denir.

Sprint Review

Sprint’in son günü yapılan ilk etkinlik Sprint Review’dür.

  • Takım, ürettiği işlerin demosunu paydaşlara sunar.

  • Bu ritüel, bir anlamda takımın “reklam sahnesidir.”

  • Paydaşlardan alınan geribildirimler ürünün gelişimi için kritik öneme sahiptir.

Sprint Retrospective

Sprint’in son etkinliği Sprint Retrospective’tir.

  • Takım üyeleri ilişkileri, süreçleri ve çalışma ortamını değerlendirir.

  • Daha iyiye götürecek aksiyonları belirler.

  • Ayrıca birbirlerini takdir etmeleri de güzel bir pratiktir.

📌 Not: Review ve Retrospective’in sırasını değiştirmemek önemlidir. Çünkü Review’da gelen geribildirimler, Retrospective gündemine taşınabilir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Verimli Refinement Etkinliği Gerçekleştirmenin İpuçları

by mlap
written by mlap

Product Backlog Refinement aktivitelerinden biri de refinement etkinliğidir. Bu etkinlikte tüm takım üyeleri ve PBI’ın olgunlaşmasına katkı sağlayabilecek kişiler yer alabilir. Kısıtlı bir süre içinde birden fazla iş ele alınacağından, zamanın verimli kullanılması çok önemlidir.

Etkinlik Öncesi Hazırlık

  • Önceliklerin belirlenmesi: Product Backlog’daki öncelikler, taslak da olsa belirlenmiş olmalıdır. Özellikle 1–2 sprint içinde yapılacak işlere öncelik verilmesi, zaman israfını azaltır. Gerekirse bir önceliklendirme etkinliği ile herkesin hemfikir olması sağlanabilir.

  • Paydaşlarla görüşme: Product Owner, ilgili paydaşlarla ihtiyaçları netleştirmeli ve yönlendirmelidir. Her talebe “evet” denilmesi, gereksiz işlere ve israfa yol açabilir. İş değeri yüksek taleplerin öne alınması kritik önemdedir.

  • Ürünler arası farkındalık: Product Owner yalnızca kendi ürünü değil, kurum içindeki diğer ürünleri de bilmeli. Böylece duplike işler önlenir, talep sahipleri doğru ürünlere yönlendirilebilir.

Etkinlik Sırasında Dikkat Edilecekler

  • Olgunlaştırılacak PBI’ların önceden belirlenmesi: Etkinlik öncesinde belirlenen maddeler sayesinde zaman daha etkin kullanılır. Gereken konular için developer’lar ön hazırlık yapabilir.

  • Fasilitasyon: Etkinliğin verimli geçmesi için doğru şekilde fasilite edilmesi gerekir. Bu sorumluluk Product Owner’a aittir.

  • Timebox: Zaman kutulaması yapılmalıdır. Aksi halde tek bir konu tüm etkinliği doldurabilir ve diğer maddeler gözden kaçabilir.

  • İncremental refinement: Sprint boyunca birden fazla refinement yapılması faydalıdır. İlk oturumda eksik kalan noktalar tespit edilip sonraki oturumlarda tamamlanabilir.

  • Katılımcı çeşitliliği: Katılım sadece Scrum takımı ile sınırlı olmamalı; gerekiyorsa takım dışındaki uzmanlar da davet edilmelidir.

Etkinlik Sonrası

  • Notların tutulması: Karmaşık gündemli organizasyonlarda alınan kararlar karışabilir. Bu sebeple konuşulan maddeler mutlaka kayıt altına alınmalı ve tüm takımın erişebileceği bir ortamda paylaşılmalıdır. Bu sayede:

    • Aynı konular tekrar tekrar gündeme gelmez,

    • Farklı toplantılarda farklı kararlar alınmasının önüne geçilir,

    • Herkesin aynı noktada hizalanması sağlanır.

Sonuç

Kaliteli bir planlamanın ön şartı, kaliteli refinement çalışmalarıdır. Product Owner, bu sürecin ana sorumlusu olsa da tek başına her şeyi bilmesi mümkün değildir. Bu nedenle Product Owner ve Developer’ların sürekli iletişim içinde, birlikte hareket etmesi kritik başarı faktörüdür.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

PBI’ların Küçük Parçalara Bölünmesi

by mlap
written by mlap

Agile dönüşüm sonrası takımların en çok zorlandığı konulardan biri, Product Backlog Item (PBI)’ları Definition of Done (DoD) kriterlerini dikkate alarak küçük parçalara ayırmaktır. Buradaki amaç, her bir PBI’ın tek başına değer üretenbir iş parçası olmasıdır.

Alışkanlıklarımız genellikle işleri “analiz, yazılım, test” gibi fonksiyonel adımlara bölmek yönünde olduğundan, değer üreten parçalara bölmek ilk etapta zorluk çıkarabilir. Ancak bu kası ne kadar çok çalıştırırsak, takım o kadar hızla gelişir ve yeni yaklaşım bir alışkanlığa dönüşür.

Yazılım geliştirmedeki bir çıktının değeri, üretim ortamına deploy edilebilecek özelliklere sahip çalışan yazılım parçası olarak tanımlanabilir. Bu yüzden PBI’ları küçük parçalara bölerken “değer üretiyor mu?” sorusu en önemli kriter olmalıdır.

Takımlar PBI’ları değer odaklı küçük parçalara ayırmak için aşağıdaki yöntemlerden yararlanabilir:

1. İş Akışına Göre

Bir akışın adımlarına bölmek faydalı olabilir.
Örnek: EFT fonksiyonu için akış şu şekilde olabilir:

  • Gönderen Bilgileri

  • Alıcı Bilgileri

  • Tutar Bilgisi

  • Onay

Her adım, tamamlandığında test edilebilir, kalite onayı alınabilir ve paydaşlardan geri bildirim toplanabilir. Bu parçalar tek başına üretim ortamına alınabilir durumda olur.

2. Platform Bazlı

PBI birden fazla platformu içeriyorsa (mobil, web, desktop) her biri için ayrı PBI oluşturulabilir.
Örnek: EFT fonksiyonu → Mobil Gönderen Bilgileri, Web Gönderen Bilgileri.

3. İşletim Sistemi / Tarayıcıya Göre

Geliştirilen fonksiyon farklı tarayıcılarda veya işletim sistemlerinde çalışacaksa, her biri için ayrı PBI tanımlanabilir.

4. Parametrelere Göre

Filtreleme, arama veya veri girişi fonksiyonları parametrelere ayrılabilir.
Örnek: “Arama” fonksiyonu için isim, tarih, kategori gibi her parametre ayrı bir PBI olabilir.

5. İş Kurallarına Göre

Her akış farklı kurallar barındırabilir. Bu kurallar ayrı PBI olarak ele alınabilir.
Örnek: TC Kimlik numarasının ilk ve son 3 hanesinin maskelenmesi.

6. Test Senaryolarına Göre

Her test senaryosu bir iş kuralını ya da akışı temsil edebilir. Bu senaryolar baz alınarak PBI oluşturulabilir.

7. Rol Bazlı

Üründe farklı kullanıcı rolleri varsa, bu roller için ayrı PBI tanımlanabilir.
Örnek: Kullanıcı rolü için ayrı, yönetici rolü için ayrı geliştirmeler.

8. İşlem Türlerine Göre

İşlem tipleri farklı PBI’lara bölünebilir.
Örnek: Silme, Düzenleme, Görüntüleme gibi işlemler.

📌 Sonuç:

PBI’ları doğru şekilde küçük parçalara bölmek, hem sprint içinde değer üretimini hızlandırır hem de paydaşlardan erken geri bildirim alınmasını sağlar. Bu da ürünün pazara daha hızlı ve doğru uyumlanmasına katkıda bulunur.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Product Backlog Refinement

by mlap
written by mlap

Product Backlog Refinement, backlog’da yer alan işlerin olgunlaştırıldığı ve detaylandırıldığı, sürekli devam eden aktiviteler bütünüdür. Scrum Guide’ın 2013 güncellemesine kadar bu süreç Grooming olarak adlandırılıyordu. Bu nedenle araştırmalarda hem Grooming hem de Refinement ifadeleriyle karşılaşabilirsiniz.

Sorumluluklar

Product Backlog’un tek sorumlusu Product Owner’dır. Dolayısıyla backlog’un detaylandırılmasından da sorumludur. Ancak Product Owner’ın her şeyi tek başına bilmesi veya yapması mümkün değildir. Bu nedenle Developer’ların da refinement aktivitelerine katılması gerekir.

Scrum Guide, refinement’ı zorunlu etkinlikler arasında saymaz. Ancak Scrum’ın kurucuları ve sektörün önde gelen uzmanları, refinement’ın düzenli yapılmasını şiddetle tavsiye eder. Çünkü planlama etkinliklerinin kalitesi, yeterli refinement yapılıp yapılmadığının en önemli göstergesidir.

Eğer refinement sırasında hâlâ mevcut sprintteki işler detaylandırılıyorsa, bu bir önceki sprintte yeterli refinement yapılmadığının işaretidir.

Product Owner’ın Refinement Aktiviteleri

  • Gelen taleplerin, maillerin ilk okunması ve ihtiyaçların netleştirilmesi

  • Kendi bilgi birikimiyle backlog maddesini detaylandırmak

  • Paydaşlarla görüşerek iş ihtiyacını netleştirmek

  • Developer’lardan destek almak, onları paydaş toplantılarına davet etmek

  • Elde edilen bilgileri refinement oturumlarında tüm developer’lar ve ilgili paydaşlarla paylaşmak

  • Cevaplanamayan soruları bir sonraki refinement veya planlama öncesinde netleştirmek

Developer’ların Refinement Katkıları

  • Product Owner’ın sorularını yanıtlamak

  • Paydaşlarla yapılan görüşmelere katılmak

  • Araştırma ve inceleme yapmak (eski doküman, kod, mimari vb.)

  • Product Backlog Item’ların tahmini büyüklüklerine katkı sağlamak

Özet

Refinement, Scrum Guide’da “zorunlu etkinlik” olarak yer almasa da, Scrum’ın etkin uygulanabilmesi için kritik bir süreçtir. Düzenli yapılan refinement, daha kaliteli planlamalara, daha iyi anlaşılmış işlere ve daha verimli sprintlere doğrudan katkı sağlar.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Retrospective Pratikleri 1

by mlap
written by mlap

Agile dünyasında deneysellik ve sürekli iyileştirme için en kritik etkinliklerden biri retrospective’dir. Takımların geçmiş sprintlerini değerlendirip geleceğe daha güçlü hazırlanabilmesi için farklı retrospective pratikleri kullanılabilir. Aşağıda hem basit hem de ileri seviye uygulamalardan oluşan popüler yöntemleri bulabilirsiniz.

1. Neyi İyi Yaptık / Neyi Daha İyi Yapabiliriz

En basit formatlardan biridir ve özellikle yeni kurulan takımlar için uygundur. Sprint boyunca yaşananlar iki başlık altında değerlendirilir:

  • Neyi İyi Yaptık: Olumlu ve güçlü yönler

  • Neyi Daha İyi Yapabiliriz: Geliştirilmesi gereken veya zorluk yaşanan alanlar

Hazırlık: İki kolonlu bir tahta veya dijital board (EasyRetro, MetroRetro).
Çıktı: Öncelikli konular için aksiyonlar backlog’a eklenir.

2. Mad / Sad / Glad

Takımın duygu durumunu hızlıca anlamayı sağlar. Üç kategori üzerinden veri toplanır:

  • Mad: Sinirlenilen, hayal kırıklığı yaratan konular

  • Sad: Üzen, moral bozan konular

  • Glad: Mutlu eden, motive eden konular

Hazırlık: Üç kolonlu tahta veya online şablon (Reetro, Retrium).
Çıktı: Öncelikli sorunlara aksiyon planlanır.

3. Starfish (Start, Keep Doing, More Of, Less Of, Stop)

Daha kapsamlı bir yöntemdir, beş farklı açıdan değerlendirme yapılır:

  • Start: Yeni fikirler, denemeler

  • Keep Doing: Sürdürülmesi gereken güçlü uygulamalar

  • More Of: Daha çok yapılması gereken konular

  • Less Of: Azaltıldığında fayda sağlayacak alanlar

  • Stop: Sonlandırılması gereken aktiviteler

Hazırlık: Beş kolonlu tahta veya dijital board (Retrium, FunRetrospectives, Miro).
Çıktı: Öncelikli konulara göre aksiyonlar belirlenir.

4. 4L – Liked, Learned, Lacked, Longed For

Takımın sprint boyunca ne öğrendiğini de ortaya çıkaran faydalı bir pratiktir:

  • Liked (Sevdik): Takımı memnun eden şeyler

  • Learned (Öğrendik): Öğrenilen yeni bilgiler/tecrübeler

  • Lacked (Eksik Kaldı): Eksik kalan, ihtiyaç duyulan konular

  • Longed For (Özlenen): Keşke olsaydı denilen şeyler

Özellikle öğrenme kültürünü güçlendirmek için oldukça etkilidir.

5. Sailboat (Yelkenli Tekniği)

Takımı bir yolculuk metaforu üzerinden düşündürür. Görselleştirme sayesinde yaratıcılığı artırır.

  • Hedef Ada: Ulaşılmak istenen hedef

  • Yelken: Takımı ileriye götüren unsurlar

  • Çapa: Takımı yavaşlatan engeller

  • Kayalar: Potansiyel riskler

  • Rüzgar: Destekleyen, hızlandıran faktörler

Özellikle görsel düşünmeyi seven takımlar için idealdir.

6. Timeline (Zaman Çizgisi)

Sprint boyunca yaşanan olayları kronolojik olarak ortaya koyar.

  • Takım üyeleri yaşadıkları olumlu/olumsuz deneyimleri zaman çizgisine post-it’lerle ekler.

  • Sprintin hangi noktalarında sıkıntılar veya başarılar yoğunlaşmış net bir şekilde görülebilir.

Uzun sprintlerde veya karmaşık projelerde özellikle faydalıdır.

Sonuç

  • Basit yöntemler (Neyi İyi Yaptık / Daha İyi Yapabiliriz, Mad/Sad/Glad) → yeni takımlar için hızlı ve kolay başlangıç sağlar.

  • Daha kapsamlı yöntemler (Starfish, 4L, Sailboat, Timeline) → oturmuş takımlar için daha derin analiz ve yeni bakış açıları kazandırır.

Hangi format uygulanırsa uygulansın retrospective’in başarısı; şeffaflık, katılım ve uygulanabilir aksiyonların belirlenmesine bağlıdır.

Unutmayın: Retrospective’in asıl amacı sadece konuşmak değil, somut gelişim adımları çıkarmaktır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Dijital Retrospective Uygulamaları

by mlap
written by mlap

Agile dünyasında deneysellik ve sürekli iyileştirme kültürünün önemli bir parçası olan retrospective etkinlikleri, uzaktan çalışma ile birlikte fiziksel araçlardan dijital uygulamalara taşındı. Bu araçlar, hem kolay fasilitasyon hem de çeşitli tekniklerin uygulanmasını mümkün kılıyor.

Popüler Retrospective Araçları

1. EasyRetro (easyretro.io)

  • Kullanımı basit, board mantığıyla çalışıyor.

  • Public link ile anonim yazma özelliği cazip.

  • Hazır şablonların yanında kendi kolonlarınızı oluşturabilirsiniz.

  • “Like”, yorum ekleme ve kart birleştirme özellikleri var.

  • 3 board’a kadar ücretsiz.

2. Reetro (reetro.io)

  • EasyRetro’ya çok benzer ama tamamen ücretsiz.

  • Public link oluşturma, anonim yazma, gruplama ve oylama özellikleri var.

3. Retrium (retrium.com)

  • Profesyonel, adım adım yönlendiren bir uygulama.

  • 30 gün ücretsiz, sonrası ücretli.

  • Retrospective 4 aşamada ilerler: Think → Group → Vote → Discuss.

  • Hazır şablonların yanında kendi akışınızı da oluşturabilirsiniz.

4. FunRetrospectives (funretrospectives.com)

  • Tamamen ücretsiz, üyelik istemiyor.

  • Public link ile kolay paylaşım yapılabiliyor.

  • Energizer aktiviteleri ile başlanabiliyor.

  • Takım olma oyunlarını da barındırması artı bir özellik.

5. MetroRetro (metroretro.io)

  • Ücretsiz, görsel odaklı.

  • Post-it’ler, yorum ekleme, gruplama, oylama özellikleri mevcut.

  • Kendi şablonlarınızı da oluşturabilirsiniz.

6. Miro (miro.com)

  • Kapsamlı bir online whiteboard.

  • Retrospective için özel şablonlar içeriyor.

  • Post-it, voting, timebox ve workshop özellikleri var.

  • 3 board’a kadar ücretsiz.

7. Mural (mural.co)

  • Miro’ya çok benzer.

  • 3 board’a kadar free plan sunuyor.

  • Özellikle workshop’larda tercih ediliyor.

8. Parabol (parabol.co)

  • Tamamen ücretsiz ve open-source.

  • Slack ve GitHub entegrasyonu var.

  • Retrospective dışında check-in ve check-out toplantıları için de kullanılabiliyor.

  • Takım katılımını artırmaya yönelik oyunlaştırılmış özellikler içeriyor.

9. TeamRetro (teamretro.com)

  • Kullanıcı dostu arayüz.

  • Hazır retrospective şablonları + kendi akışınızı oluşturabilme imkânı.

  • Anonim geri bildirim ve gelişmiş raporlama özellikleri mevcut.

  • Ücretli, ama güçlü enterprise özellikleri var.

10. GoRetro (goretro.ai)

  • Ücretsiz versiyonu oldukça kapsamlı.

  • Takımlar arası karşılaştırmalı raporlama yapabiliyor.

  • Jira entegrasyonu ile iş akışını retrospektiflere bağlayabiliyor.

  • Farklı retrospective formatlarını kolayca uygulamaya imkân veriyor.

11. ScatterSpoke (scatterspoke.com)

  • Retro verilerini analiz ederek takımın trendlerini gösteriyor.

  • Takımın sürekli gelişimine odaklanıyor.

  • Jira entegrasyonu mevcut.

  • Ücretli ama güçlü analiz özellikleri var.

Özet

  • Ücretsiz & Basit Kullanım: EasyRetro, Reetro, MetroRetro, FunRetrospectives, Parabol.

  • Profesyonel & Enterprise Odaklı: Retrium, TeamRetro, ScatterSpoke.

  • Whiteboard Deneyimi: Miro, Mural.

  • Entegrasyon Odaklı: GoRetro, ScatterSpoke.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Etkin Retrospective Gerçekleştirmenin İpuçları

by mlap
written by mlap

Retrospective, Agile dönüşüm yolculuğundaki en önemli etkinliklerden biridir. Takımın kendini değerlendirdiği, güçlü ve gelişmesi gereken yönlerini ortaya koyduğu ve iyileştirme aksiyonlarını belirlediği bu etkinlik, ancak belli bir akışta ilerler ve doğru fasilite edilirse gerçekten faydalı olur.

Etkin bir retrospective için öncesinde, etkinlik sırasında ve etkinlik sonunda dikkat edilmesi gereken noktalar vardır.

Retrospective Öncesi

  • Ritüelleştirme: Retrospective düzenli yapılmalı ve takım için bir alışkanlığa dönüşmelidir. Düzenlilik, alınan aksiyonların takibini de kolaylaştırır.

  • Güven ortamı: Herkesin fikirlerini, sorunlarını ve yorumlarını özgürce dile getirebilmesi için güvenli bir ortam şarttır. Güven sağlanmadan şeffaflık ve açık iletişim mümkün değildir.

  • Teknik seçimi: Kullanılacak retrospective tekniği önceden belirlenmeli ve hazırlık yapılmalıdır.

  • Fasilitasyon: Etkinliği yönetecek güçlü bir fasilitasyon olmalıdır. Fasilitasyon olmazsa süreç dağılır, zaman yönetimi kaybolur ve fayda sağlanamaz.

Retrospective Sırasında

  • Timebox uyumu: Her aşama için net bir süre belirlenmelidir. Aksi halde bazı konular gereksiz uzayarak aksiyon alınmadan etkinlik sona erebilir.

  • Icebreaker: Katılımcıların etkinliğe odaklanmasını sağlamak ve varsa gerginliği azaltmak için kısa bir icebreaker yapılabilir.

  • Önceki aksiyonların gözden geçirilmesi: Bir önceki retrospective’te alınan kararların ne durumda olduğu değerlendirilmelidir. Böylece alınan aksiyonların takibi sağlanır.

  • Veri toplama: Değerlendirilecek konular için veri toplanmalı ve kullanılacak teknikler katılımcılara açıklanmalıdır.

  • Önceliklendirme: Tüm konuları konuşmak mümkün olmayabilir. Bu nedenle öncelik belirlenerek en kritik konulara odaklanılmalıdır.

  • Aksiyon belirleme: Retrospective’in başarısını gösteren en önemli çıktı aksiyonlardır. Belirlenen aksiyonların mümkünse bir sahibi de atanmalıdır.

Retrospective Sonrası

  • Etkinlik değerlendirmesi: Son bölümde, etkinliğin nasıl geçtiğine dair katılımcılardan geri bildirim alınmalıdır. Bu geri bildirimler, sonraki retrospective’lerin daha kaliteli geçmesini sağlar.

Unutmayın: Retrospective, yalnızca konuşmak için değil; somut aksiyonlar çıkararak sürekli gelişimi sağlamak için vardır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Retrospective

by mlap
written by mlap

Sprint Retrospective, Scrum Guide’da sprintin son etkinliği olarak tanımlanır. Bu etkinlik, Scrum takımının Kaizen kültürünü yani sürekli iyileşme yaklaşımını kazandığı en önemli aşamadır.

Retrospective sırasında takım; ilişkiler, iletişim, araçlar, süreçler, uygulamalar ve çalışma ortamını değerlendirir. Amaç, daha iyiye götürecek iyileştirme aksiyonlarını belirlemektir. Sadece gelişim noktalarının değil, birbirini takdir etmeninde önemli bir parça olduğunu unutmamak gerekir.
Scrum Guide, 2 haftalık bir sprint için bu etkinliğin en fazla 1,5 saat sürmesini önermektedir.

Retrospective’in Amacı

  • Hangi pratik uygulanırsa uygulansın, takip edilebilir aksiyonların çıkması ana hedeftir.

  • Aksiyon üretmeyen bir retrospective, amacına ulaşmış sayılmaz.

  • Etkinliğin verimli geçmesi için Scrum Master’ın hazırlık yapması ve uygun fasilitasyon tekniklerini seçmesi kritik önemdedir.

Güvenli Ortam ve Fasilitasyon

  • Retrospective’in fayda sağlaması için güvenli, şeffaf ve açık iletişime dayalı bir ortam gerekir.

  • Scrum Master, etkinliği herkesin katılımını sağlayacak şekilde fasilite etmelidir.

  • Doğru fasilitasyon teknikleri, hem katılımı artırır hem de kaliteli çıktılar sağlar.

Lider Katılımı

  • Eğer liderlerin varlığı güveni ve şeffaflığı zedeleyecekse, katılmamaları tavsiye edilir.

  • Aksi halde özellikle bireysel konular dile getirilemez ve etkinlik amacını kaybeder.

  • Ancak, liderlerin katılmaması durumunda bile, bireysel olmayan çıktılar ve takımın çözemediği konular mutlaka onlarla paylaşılmalı, destek istenmelidir.

Etki Alanına Odaklanmak

  • Takım, sadece etki alanındaki konulara odaklanmalıdır.

  • Etki alanı dışında kalan konuların konuşulması, sadece “dertleşme” seviyesinde kalır ve aksiyon üretilemez.

  • Zaman zaman duygusal bir retrospective yaşanabilir, bu doğaldır. Ancak asıl amacın iyileştirme olduğu unutulmamalıdır.

Retrospective’in Önemi

Woody Zuill’in sözü bu etkinliğin değerini çok güzel özetler:
“If you adopt only one agile practice, let it be retrospectives. Everything else will follow.”

Yani, yalnızca bir çevik pratik benimsenecekse, bu kesinlikle retrospective olmalıdır. Çünkü takip edilebilir aksiyonlarile sürekli iyileşmenin kapısını aralar.

Retrospective, sadece bir değerlendirme değil; takımın kültürünü, iletişimini ve verimliliğini sürekli geliştiren en güçlü araçtır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Sprint Review

by mlap
written by mlap

Sprint Review, sprint’in son gününde gerçekleştirilen, sprint boyunca geliştirilen işlerin paydaşlara sunulduğu ve geri bildirimlerin alındığı etkinliktir. Takımın ürettiği değeri sergilediği, adeta “şov sahnesi”dir. Tüm paydaşların ve merak eden herkesin katılımına açıktır. 4 haftalık bir sprint için süresi en fazla 4 saattir.

Katılımın Önemi

Etkinliğin temel amacı geri bildirim almak olduğundan, katılımcı sayısının mümkün olduğunca fazla olması önemlidir.

  • Product Owner, etkinlik öncesinde ana paydaşlarla iletişim kurarak katılımlarını teşvik etmelidir.

Hazırlık Süreci

Review, takımın ve ürünün imajı açısından kritik öneme sahiptir.

  • Etkinlik öncesinde (maksimum 1 saatlik) bir hazırlık yapılmalıdır.

  • Gösterilecek veriler hazırlanmalı, ortamın sorunsuz çalışacağı garanti edilmelidir.

  • Aksi takdirde kaliteli bir ürün bile olumsuz bir izlenim yaratabilir.

Demo Sunumu

Hazırlıklar tamamlandıktan sonra sıra, geliştirilen ürünün/hizmetin demo sunumuna gelir.

  • Sadece “ideal” senaryolar değil, farklı kullanım senaryoları da gösterilmelidir. Bu, yapılan işe duyulan güveni yansıtır.

  • Eğer mobil bir ürün geliştiriliyorsa, katılımcılara cihaz verilerek denemeleri sağlanabilir. Bu, güvenin en yüksek seviyesini gösterir.

Geri Bildirimlerin Alınması

Review’un en önemli çıktısı geri bildirimlerdir.

  • Katılımcılardan yorum gelmiyorsa, Product Owner teşvik etmelidir.

  • Alınan geri bildirimler ürünün gelişimi için fırsat olarak görülmeli, gerekli olanlar Product Backlog’a eklenmelidir.

  • Yorumların atlanmaması için Product Owner not tutmalı; ek olarak bir takım üyesi de not alarak sonrasında birleştirilmesi iyi bir pratiktir.

Takip ve Güven

Bir sonraki Review toplantısında Product Owner, önceki toplantıda alınan geri bildirimlerle ilgili yapılan aksiyonları özetleyebilir.

  • Bu, hem katılımcıları memnun eder hem de takımın/projenin imajını güçlendirir.

  • Paydaşların güvenini artırır.

Sprint Review, yalnızca bir sunum değil; ürünün geleceğini şekillendiren, geri bildirim odaklı bir işbirliği etkinliğidir.

0 comments
0 FacebookTwitterPinterestEmail
Newer Posts
Older Posts