Sprint Retrospektifi ve AI: iyileştirmeler neden modele devredilemez

Bu, AI'ın kross-fonksiyonel geliştirme ekibinin klasik toplantılarını nasıl değiştirdiğine dair serinin beşinci makalesi. Önceki bölümlerde şunları ele aldım: Backlog Refinement, Sprint Planning, Daily Scrum ve Sprint Review. Genel sonuç giderek sertleşiyor: AI konuşma için girdiyi iyi toplar, ama konuşmanın kendisini ikame etmemelidir. Sprint Retrospektifinde bu sınır özellikle önemlidir, çünkü burada ekip yalnızca görevleri ve ürünü değil, kendi alışkanlıklarını, etkileşimlerini, kalitesini ve değişme kapasitesini tartışır.

Sprint Retrospektifi AI için çok uygun bir aday gibi görünüyor. Sprint sonunda zaten Jira, Git, pull request'ler, CI/CD, olaylar, sohbetler, takvim, Daily Scrum notları, Sprint Review kararları, bazen de ekibin kısa anketleri var. Model hızlıca şunları toplayabilir: işi en çok ne yavaşlattı, review darboğazları nerede takıldı, hangi görevler günden güne taşındı, Definition of Done nerede belirsiz kaldı, hangi kararlar tekrarlandı, önceki retrolarda hangi konular dile geldi ve kaybolmadı.

İlk bakışta bu neredeyse ideal bir otomasyon. Tüm sprinti yeniden hatırlamaya gerek yok. Review beklemesinin gerçek bir sorun mu yoksa sadece birinin hissi mi olduğunu tartışmaya gerek yok. Onlarca ticket ve tartışma dalını elle gözden geçirmeye gerek yok. AI gerçekleri hazırlayabilir, kalıpları gruplayabilir, kök neden analizi önerebilir ve hatta sonraki sprint için action item'lar üretebilir.

Ama asıl risk tam burada başlıyor.

Sprint Retrospektifi düzgün bir iyileştirme listesi elde etmek için var değildir. Anlamı, ekibin nasıl çalıştığını dürüstçe görmesi, neyin değişmesi gerektiği konusunda anlaşması ve bu değişimin sorumluluğunu üstlenmesidir. AI retroyu bir öneri listesine dönüştürürse, ekip güzel bir belge elde edebilir ama en önemlisini kaybedebilir: psikolojik güvenlik, sorunun ortak anlaşılması ve gerçek follow-through.

“AI kalıpları aydınlatabilir, ama iyileştirme ancak ekip sorunu kabul edip davranışını değiştirdiğinde başlar.”

Sprint Retrospektifi neden gerekli

İçinde Scrum Guide 2020 Sprint Retrospektifi çok pratik biçimde tanımlanır: ekip kaliteyi ve etkinliği artırma yollarını planlar. Bunun için Scrum Team sprintin nasıl geçtiğini insanlar, etkileşimler, süreçler, araçlar ve Definition of Done açısından inceler. Ekip neyin iyi gittiğini, hangi sorunların ortaya çıktığını ve bu sorunların çözülüp çözülmediğini tartışır. Sonra en yararlı değişiklikleri belirler ve en anlamlı iyileştirmeler mümkün olan en kısa sürede ele alınmalıdır ve sonraki sprintin Sprint Backlog'una girebilir.

Yani retrospektif, sprint sonunda duygusal bir rahatlama değildir. Üç sütunu doldurmanın gerektiği biçimsel bir tören de değildir: ne iyiydi, ne kötüydü, neyi iyileştireceğiz. Bu etkinlik çalışma biçiminin adaptasyonuyla ilgilidir. Bu anlamda Scrum'ın genel mantığıyla doğrudan bağlantılıdır: şeffaflık inceleme için gerekir, inceleme adaptasyon için gerekir ve adaptasyon olmadan inceleme boşalır. Scrum Guide açıkça vurgular: Scrum etkinlikleri yalnızca tutanak üretmek için değil, değişimi teşvik etmek için tasarlanmıştır.

Ek bir referans olarak Scrum Guide Expanded v2026.1yararlıdır, ama yeni bir kanonik Scrum Guide sürümü olarak değil, Scrum Guide 2020 temelinde bir companion kaynak olarak. Bu makale için iki açıdan önemlidir. Birincisi, reflection'ın psikolojik olarak güvenli bir ortamda daha etkili olduğunu söyler. İkincisi, AI bölümünde modeli supervised decision-making partner olarak tanımlar: AI şeffaflığı, incelemeyi ve adaptasyonu güçlendirebilir, ama insan sorumluluğunun yerini almaz ve sürecin ampirik kontrolünü ortadan kaldırmaz.

Bu yüzden Sprint Retrospektifinin amacını beş işlevle tanımlardım:

• ekibin gerçek çalışma kalıplarını görmek, yalnızca en yüksek sesli görüşleri değil;
• etkileşimleri, süreçleri, araçları ve Definition of Done'ı cezalandırılma korkusu olmadan tartışmak;
• gerçekleri yorumlardan ve tahminlerden ayırmak;
• ekibin gerçekten denemeye hazır olduğu az sayıda iyileştirme seçmek;
• bu iyileştirmeleri sonraki sprinte owner, doğrulama kriteri ve iş içinde yer alacak şekilde taşımak.

Bu, AI hakkında konuşmak için bir çerçevedir. Araç ekibin bu işlevleri daha iyi yerine getirmesine yardımcı oluyorsa yararlıdır. Sadece daha güzel bir action item listesi üretiyorsa kullanışlı olabilir, ama ekibi mutlaka daha etkili hale getirmez.

Genellikle ne ters gider

Retrospektiflerdeki sorun nadiren ekibin sorunları adlandıramamasıdır. Genellikle sorunlar başkadır. Ekip yine aynı şeyleri tartışır. Action item'lar sprintten sprinte geçer. İnsanlar suçlu görünmek istemedikleri için dikkatli konuşur. En acı verici konulardan uzak durulur. Scrum Master formatı çıkarır ama değişimi çıkaramaz. Sonunda herkes «daha iyi iletişim kuralım» gibi bir şey üzerinde anlaşır ve bu daha sonraki hafta çoktan eriyip gider.

Lehtinen, Itkonen ve Lassenius'un Empirical Software Engineering üzerine klasik çalışması retrospektiflerin bu yönünü iyi vurgular. Yazarlar yaklaşık üç yıl boyunca 37 ekip düzeyinde retrospektifi inceledi ve birkaç önemli şey gösterdi: tartışmalar genellikle ekibe yakın ve ekibin yönetebildiği konularla ilgilidir, ancak participant bias'tan muzdarip olabilir; hard evidence olmadan her zaman gerçeği yansıtmazlar; bazı konular uzun süre tekrarlanır çünkü ya doğal olarak geri dönerler ya da ekip karmaşıklık veya kontrol edilebilirlik eksikliği nedeniyle bunları kendi düzeyinde çözemez.

Bu, AI için çok faydalı bir çerçevedir. Model gerçekten daha önce yalnızca his olan yere hard evidence getirmeye yardımcı olabilir. Örneğin ekip şöyle der: «review sprinti yavaşlatıyor». AI olguları ortaya çıkarabilir: kaç PR bir günden fazla bekledi, hangileri tam olarak takıldı, hangi yorumlar tekrarlandı, merge sonrası nerede düzeltmeler oldu. Bu, hafızaya dayanarak tartışmaktan daha faydalıdır.

Ancak bu çerçevenin bir de ters yüzü vardır. Ekip rahatsız edici nedeni konuşmak istemiyorsa, AI onu daha dürüst yapmaz. Sorun ekibin etki alanının dışındaysa, model yine de kimsenin uygulamayacağı bir action item'ı güzelce formüle edebilir. İnsanlar bağlama güvenmiyorsa, artık süreç hakkında değil, AI'ın işlerini doğru tanımlayıp tanımlamadığı hakkında tartışacaklardır.

AI gerçekte nerede yardımcı olur

AI'ın Sprint Retrospective'te güçlü bir fayda alanı vardır, eğer iyileştirmenin kendisini ona devretmeye çalışmazsanız. Ben onu retrodan önce ve retrodan sonra kullanırdım, retronun yerine değil.

Ancak burada fazla söz vermemek önemlidir. DORA State of AI-assisted Software Development 2025 araştırması AI'ı organizasyonel sistemin mevcut güçlü ve zayıf yönlerinin bir yükselticisi olarak tanımlar. Retrospektif için bu neredeyse ideal bir formülasyondur: ekip süreci dürüstçe tartışmayı ve iyileştirmeleri eyleme dönüştürmeyi zaten biliyorsa, AI girdiyi daha zengin hale getirir. Retro uzun zamandır takipsiz güvenli bir ritüele dönüştüyse, AI bu ritüeli sadece daha hızlı ve daha düzgün hale getirir.

Toplantıdan önce AI inceleme için girdi hazırlayabilir:

• Daily Scrum, ticket'lar, pull request'ler ve incident notlarından tekrarlayan impediment'ları toplamak;
• work item'ların review, test verisi, Ürün Sahibi kararı veya dış bağımlılık için uzun süre beklediği yerleri bulmak;
• Sprint Planning planını, sprint boyunca alınan fiili kararları ve Sprint Review'da tartışılan sonucu karşılaştırmak;
• Definition of Done ile ekibin görevleri gerçekte nasıl kapattığı arasındaki tutarsızlıkları vurgulamak;
• eski action item'ları toplamak ve hangilerinin tamamlandığını, unutulduğunu veya tekrarlandığını göstermek;
• konuşma için aday sorular formüle etmek: ne olguydu, ne yorumdu ve ne doğrulama gerektiriyor.

Toplantıdan sonra AI takip konusunda yardımcı olabilir: seçilen action item'ları düzgünce kaydetmek, owner, doğrulama kriteri, Sprint Backlog ile bağlantı ve bir sonraki retrospektif için hatırlatma eklemek. Bu özellikle değerlidir çünkü birçok retronun zayıf noktası tartışma değil, iyileştirmelerin bir sonraki sprinte kadar yaşamamasıdır.

Ancak tüm bu senaryolarda AI hazırlık ve destek katmanı olarak kalır. Hangi sorunun ana sorun olduğuna karar vermemelidir. Suçlu atamamalıdır. Root cause'u olgu olarak belirlememelidir. Ve kesinlikle canlı bir doğrulama olmadan otomatik olarak «ekibin iyileştirme planını» yazmamalıdır.

AI neden retrospektifi ekip adına yürütmemelidir

AI destekli Retrospective'in en tehlikeli versiyonu olgun görünür. Model tüm verileri toplar, ekibin ruh halini analiz eder, «sorunların üç ana nedenini» bulur, action item'lar önerir ve özeti Slack veya Confluence'a gönderir. Herkes okur, başını sallar, tepki verir ve retro daha kısa olur. Bazen ekip tamamen şöyle düşünmeye başlar: AI zaten her şeyi analiz ettiyse, konuşmaya bir saat harcamaya ne gerek var?

Sorun şu ki retrospektif yalnızca çıktısıyla değerli değildir. Ortak anlayış süreciyle değerlidir. Ekip için sadece «review çok fazla zaman alıyor» ifadesini almak önemli değildir. Bunun neden olduğunu, ekibin neyi değiştirmeye hazır olduğunu, hangi uzlaşmayı kabul ettiğini ve eylemi kimin üstlendiğini müzakere etmesi gerekir. Bazen bu konuşmada verilerden görünmeyen şeyler ortaya çıkar: güçlü bir geliştiriciyle tartışma korkusu, belirsiz product context'ten kaynaklanan rahatsızlık, sürekli acil görevlerden yorgunluk, mevcut Definition of Done'a sessiz muhalefet.

Amy Edmondson'ın psikolojik güvenlik ve öğrenme davranışı burada moda bir referans olarak değil, pratik bir pusula olarak önemlidir. İnsanlar kişilerarası risk olmadan sorunlar hakkında konuşabileceklerini hissetmezlerse, retrospektif güvenli ifadelere dönüşür. Böyle bir durumda AI protokolü daha akıcı hale getirebilir, ama ekibi daha dürüst yapamaz.

Dahası, ekip AI'ı izleme olarak algılarsa AI dürüstlüğü kötüleştirebilir. Model Slack, Jira, PR yorumları ve takvimi okuyup sonra «Aleksey'in review'a tepki hızı düşük» veya «QA sık sık veri hazırlığını geciktiriyor» yazarsa, bu artık retrospektif desteği değildir. Bu, süreç iyileştirme kılığında performans yönetimidir. Böyle bir ortamda insanlar gerçek süreci tartışmak yerine görünür aktiviteyi optimize etmeye, modelle tartışmaya ve itibarı korumaya başlar.

Bu yüzden NIST Generative AI Profile, OWASP Top 10 for LLM Applications 2025, EDPB Opinion 28/2024 ve ICO'nun şu konudaki materyalleri: işyerinde izleme burada relevanttir. Makalenin hukuki bölümü olarak değil, bir hatırlatma olarak: retrospektif veriler kolayca hassas hale gelir. İnsanlara, davranışlara, çatışmalara, hatalara, gecikmelere, yazışmalara ve bazen yönetimdeki zayıf noktalara dokunurlar.

Pratik sınır basittir: retroda AI work and system'i analiz etmeli, not people. Yani tıkanmış işi, tekrarlayan beklentileri, belirsiz kuralları, Definition of Done'daki boşlukları, kötü handoff'ları, aşırı yüklenmiş süreç noktalarını. "Kim kötü çalıştı" değil, "sistemde ne bizi tekrar aynı sonuca getiriyor".

“İyi bir retro AI-input'u tıkanmış işe ve tekrarlayan desenlere bakar. Kötü bir AI-input'u insanları rapor satırlarına dönüştürür.”

Vaka çalışmasına devam: B2B LMS ve e-posta hatırlatmaları

Önceki makalelerdeki aynı vakayı ele alalım: B2B LMS platformu, zorunlu kurslar, zorunlu kursu son tarihe kadar tamamlamayan çalışanlara e-posta hatırlatmaları. Sprint Planning'de ekip dar bir Sprint Goal seçti: sistem, zorunlu kursu tamamlamamış aktif çalışanlara son tarihe kadar tek bir doğru hatırlatma gönderir ve doğrulanabilir gönderim geçmişini saklar. Daily Scrum'da ekip deduplikasyon, saat dilimleri ve test verileriyle ilgili riskleri takip etti. Sprint Review'de ekip bunun ürün ve Product Backlog için neyi değiştirdiğini tartıştı.

Şimdi Sprint Retrospective geliyor. AI olmadan konuşma hızla alışılmış hislere kayabilir. Backend şöyle der: «bizi eligibility netleştirmeleri yavaşlattı». QA şöyle der: «test verileri geç geldi». Frontend şöyle der: «API sprintin ortasında değişti». Ürün sahibi şöyle der: « expiredhakkında bu kadar çok soru beklemiyorduk». Scrum Master şunları yazar: «iletişimi iyileştir», «verileri daha erken hazırla», «gereksinimleri daha az değiştir». Retro yapılmış gibi görünür.

AI girdiyi daha somut hale getirebilir. Sprintin geçmişini çıkarır ve gösterir:

• dört PR review için bir günden fazla bekledi ve hepsi retry logic ve idempotency ile ilgiliydi;
• deaktive edilmiş kullanıcılar için eligibility yorumu üç kez değişti;
• QA verisi, ekibin planning'de beklediğinden üç gün daha geç ortaya çıktı;
• Definition of Done, negatif senaryolar için doğrulanabilir gönderim geçmişini gerektirmiyordu;
• eski action item «PR boyutunu küçült» yerine getirilmedi ve sorun olarak tekrarlandı;
• Slack'teki tartışmaların bir kısmı uygulama hakkında değil, expired.

konusunda tek bir kararın olmaması hakkındaydı. Bu iyi bir girdi. Ama bu henüz retrospektif değil.

Retrospektif, ekip bunlardan gerçekten neyi değiştireceğini tartıştığında başlar. Örneğin şuna karar verebilir: «daha erken iletişim kur» değil, «planning'de tartışmalı eligibility durumlarını ve bunların product owner kararını açıkça kaydet». «QA verileri daha hızlı hazırlasın» değil, «kritik senaryonun uygulanmasına başlamadan önce Sprint Backlog'a test verileri için ayrı bir work item eklenir». «Daha az PR yap» değil, «notification architecture'taki değişiklikler için PR tek bir review senaryosuna sığmalı ve çalışma başlamadan önce review sahibi olmalı». «DoD'yi iyileştir» değil, «Definition of Done artık hatırlatmaların negatif senaryoları için doğrulanabilir gönderim geçmişini içeriyor».

İşte bunlar artık action items. Somut, doğrulanabilir ve bir sonraki sprintle bağlantılı. AI desenleri görmeye yardımcı oldu. Ekibin değişikliği seçti.

Anti-pattern'ler

Aşağıda, AI'ı Sprint Retrospective'e dahil ederken ayrıca izleyeceğim birkaç anti-pattern var.

1. AI özeti canlı konuşmanın yerini alır

Ekip sadece oluşturulan özeti okuyup onaylarsa, retro en önemli şeyini kaybeder. İyi soru «AI sprinti doğru tanımladı mı?» değil, «bunlardan hangisini işimizde değiştirmeye hazırız?» sorusudur.

2. Sentiment analysis ekiple ilgili gerçeğe dönüşür

Duygu analizi yararlı bir zayıf sinyal olabilir, ama bağlamı bilmez. Alaycılık, yorgunluk, yerel çatışma, şaka, sessizlik ve temkinli ifade bir metriğe iyi dönüşmez. Ekibin ruh hali bir grafiğe indirgenemez.

3. AI sistemik desenler yerine suçlu arar

Model insanları hıza, aktiviteye veya "oluşturulan engelleyici" sayısına göre sıralamaya başladığı anda retrospektif izlemeye dönüşür. Bu, psikolojik güvenliği zedeler ve insanların getirmeye istekli olduğu bilginin kalitesini düşürür.

4. Kök neden doğrulama olmadan kabul ediliyor

Model kendinden emin bir şekilde şöyle yazabilir: "Gecikmelerin ana nedeni belirsiz gereksinimler." Ancak bu yalnızca görünen kısım olabilir. Gerçek neden mimari borç, öncelik çatışması, test verisi eksikliği veya sorunu yükseltme korkusu olabilir. AI'dan gelen kök neden bir hipotezdir, gerçek değil.

5. Action item'lar fazla genel kalıyor

"İletişimi iyileştir", "review'u hızlandır", "daha iyi hazırlan" neredeyse hiçbir zaman davranışı değiştirmez. İyi bir action item şu soruları yanıtlamalıdır: kim yapıyor, tam olarak neyi değiştiriyor, bu bir sonraki sprint'te nerede görünür ve takım etkiyi nasıl doğrular.

6. İyileştirmeler Sprint Backlog'a girmiyor

Scrum Guide, en anlamlı iyileştirmelerin bir sonraki sprint'in Sprint Backlog'una girmesine izin verir. Takım bir iyileştirme seçti ama buna dikkat, owner ve işte yer ayırmadıysa bu improvement değildir. Bu bir dilektir.

Roller nasıl değişiyor

AI, Scrum Team içindeki sorumluluk alanlarını ortadan kaldırmaz, ancak konuşmaya hazırlığı değiştirir. Sprint geçmişini elle yeniden oluşturmanın değeri azalır. Dürüst yorumlama, küçük bir deney seçme ve iyileştirmeyi sonuca götürme değeri artar.

Rol	Kötü AI senaryosunda risk	Olgun AI kullanımı
Geliştiriciler	Kendi aktivitelerinin AI değerlendirmesiyle tartışır ve süreci konuşmak yerine itibarı savunur.	Gerçekleri ve kalıpları girdi olarak kullanır, ancak mühendislik pratiklerinde, review, DoD ve handoffs'ta neyi değiştireceklerini kendileri seçer.
Ürün sahibi	AI retrosunu takımın performans raporu olarak okur ve hız konusunda baskı yapar.	Ürün belirsizliğini gidermeye, takımı yavaşlatan kararları netleştirmeye ve bir sonraki Sprint Backlog'daki iyileştirmeleri desteklemeye yardımcı olur.
Scrum Master	Kolaylaştırıcılığı modele devreder ve dürüst bir konuşma yerine düzgün bir tutanak alır.	Hazırlık için AI girdisini kullanır, ancak psikolojik güvenliği, sistem odağını ve seçilen action item'ların follow-through'unu korur.
Kalite mühendisi / QA mühendisi	Model sorunları yüzeysel olarak testle ilişkilendirirse "gecikme kaynağı" rolünü alır.	Kalite sinyallerini Definition of Done değişikliklerine, test-data ownership'e ve gözlemlenebilirliğe dönüştürmeye yardımcı olur.
UX/UI tasarımcısı	AI ağırlıklı olarak kodu, PR'ları ve geliştirme görevlerini analiz ettiği için retro'dan düşer.	Takımın ve ürünün çalışma kalitesini etkileyen etkileşimleri, kararları ve kullanıcı bağlamını öne çıkarır.
Engineering Lead / Tech Lead	AI retrosunu mühendisleri kontrol etme panosu olarak kullanır.	Sistemik engineering darboğazlarını bireysel aktiviteden ayırmaya ve bir sonraki sprint'e gerçekten sığacak teknik iyileştirmeyi seçmeye yardımcı olur.

AI destekli Retrospektif için pratik filtre

"AI retro yönetsin" fikriyle başlamazdım. Daha dar bir soruyla başlardım: hangi girdi takımın çalışma biçimini daha dürüst incelemesine ve gerçekten uygulayacağı bir-iki iyileştirmeyi seçmesine yardımcı olur?

AI girdisi Sprint Retrospective için şu soruları yanıtlamaya yardımcı oluyorsa faydalıdır:

• hangi sorunlar tekrarlandı, hangileri tek seferlikti;
• hangi gerçekler temayı doğruluyor, hangileri görüş veya duygusal değerlendirme;
• neyin takımın etki alanında olduğu, neyin Supporters, yönetim veya başka bir takımın yardımını gerektirdiği;
• hangi eski action item'lar tamamlanmadı ve neden;
• bir sonraki sprint'te hangi tek süreç, araç, working agreement veya Definition of Done değiştirilmeli;
• takım değişikliğin işe yaradığını nasıl doğrulayacak.

Tam tersine: AI girdisi ağırlıklı olarak "kim darboğazdı" sorusunu yanıtlıyorsa bu tehlikeli bir sinyaldir. Retrospektif, takımın çalışma sistemini iyileştirmesine yardımcı olmalı, katılımcıların gizli bir sıralamasını üretmemelidir.

Veriler ve sınırlar

Sprint Retrospective verilere karşı özellikle hassastır, çünkü AI kolayca insanların kişisel algıladığı şeyleri toplamaya başlar: sohbet mesajları, yanıt hızı, yorum tonu, PR'a tepki süresi, toplantılara katılım, tekrarlayan hatalar, tartışmalardaki çatışmalar. Erişim ne kadar genişse analiz o kadar ikna edici olur. Ancak hassas bağlamın sızma riski, model çıktısına aşırı bağımlılık ve retro'nun employee monitoring'e dönüşme riski de o kadar yükselir.

Pratikte AI'ı retro'ya sokmadan önce birkaç kural belirlerdim:

• retro sorusu için gereken minimum kaynak setini kullanmak;
• açık mutabakat ve gereklilik olmadan kişisel mesajları analiz etmemek;
• kişisel sıralamalar, score ve performance management hakkında sonuçlar üretmemek;
• takıma hangi verilerin kullanıldığını ve hangilerinin hariç tutulduğunu göstermek;
• gerçekleri üretilen yorumlardan ayırmak;
• önemli sonuçları birincil kaynaktan doğrulamak;
• hassas takım bağlamı içeriyorsa AI özetlerini silmek veya saklamayı sınırlamak.

Bu bürokrasi değil. Bu dürüst bir konuşmanın koşulu. İnsanlar modelin tam olarak neyi okuduğunu ve çıktısının sonra nasıl kullanıldığını anlamazsa, daha temkinli konuşacaklar. Temkinli bir retrospektif ise neredeyse her zaman güvenli ama zayıf iyileştirmeler üretir.

Peki gerçekte ne değişiyor

AI gerçekten Sprint Retrospective'i daha faydalı hale getirebilir. Hazırlık maliyetini düşürebilir, konuşmaya olgular getirebilir, tekrar eden örüntüleri gösterebilir, tamamlanmamış action item'ları hatırlatabilir, Definition of Done ile tutarsızlıkları vurgulayabilir ve belirsiz «iyileştirmemiz gerek» ifadesini somut bir next-sprint experiment'e dönüştürmeye yardımcı olabilir.

Ama bu yalnızca takım sınırı anlarsa işe yarar: AI inspection için malzeme hazırlar, takım adına adaptation yapmaz. Verileri görmeye yardımcı olur ama psikolojik güvenlik yaratmaz. Root cause önerebilir ama insanların ne hakkında konuşmaktan korktuğunu bilmez. Bir action item yazabilir ama owner almaz ve sonraki sprintte davranışı değiştirmez.

Bu yüzden ana tezi şöyle formüle ederdim: AI, olguları yeniden oluşturmanın maliyetini düşürmeli ki takımın dürüst konuşmaya ve küçük bir iyileştirme seçmeye daha fazla dikkati kalsın. Bunun tersi olur ve Sprint Retrospective otomatik olarak üretilmiş bir öneri listesine dönüşürse, takım tam da etkinliğin var olma nedenini kaybeder: ortak öğrenme, değişim sorumluluğu ve işin kalitesini artırma yeteneği.

Olgun bir takım şunu sormaz: «Retrospektifi AI'a yaptırabilir miyiz?». Farklı sorar: «AI hazırlığın hangi kısmını alabilir ki retrospektifimiz daha dürüst, daha somut olsun ve eyleme daha iyi ulaşsın?». Bu daha az gösterişli bir soru. Ama gerçek continuous improvement'a daha yakın olan tam da bu.

Kaynaklar ve yönlendirici ilkeler

• Scrum Guide 2020 — Sprint Retrospective, kalite ve etkinlik, insanlar / etkileşimler / süreçler / araçlar / Definition of Done, en faydalı iyileştirmeler ve Sprint Backlog ile bağlantı.
• Scrum Guide Expanded v2026.1 — Scrum Guide 2020 temelli companion kaynak: psychological safety, anlamlı sürekli iyileştirme takibi ve AI'ın denetimli karar alma ortağı olarak kullanımı.
• Scrum.org: Introduction to the Sprint Retrospective — Sprint Retrospective'in takımın çalışma pratiklerinin inspection and adaptation'ı için bir etkinlik olarak pratik açıklaması.
• Lehtinen, Itkonen & Lassenius: Recurring opinions or productive improvements — neredeyse üç yıl boyunca 37 retrospektif üzerine ampirik bir çalışma: participant bias, hard evidence, recurring topics ve corrective actions.
• Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — psikolojik güvenliğin team learning koşulu olarak klasik kaynağı.
• NIST Generative AI Profile — confabulation, data privacy, human-AI configuration, overreliance, information integrity ve üretken AI'ın diğer riskleri.
• OWASP Top 10 for LLM Applications 2025 — hassas bilgi ifşası, aşırı ajans, yanlış bilgi ve LLM uygulamalarının operasyonel riskleri.
• DORA State of AI-assisted Software Development 2025 — AI, organizasyonel sistemin mevcut güçlü ve zayıf yönlerinin bir yükselticisi olarak.
• EDPB Opinion 28/2024 ve ICO monitoring at work guidance impact assessment — kişisel veriler, şeffaflık, orantılılık ve işyeri gözetiminin sınırlarına dair yönlendirici ilkeler.