Kollabe
Retrospektifler
Planlama Pokeri
Standuplar
BuzKırıcılar
Fiyatlandırma
Kontrol Paneli

Gönderiler

Takımınızın Üretkenliğini Öldüren 15 Scrum Anti-Deseni

Tanımlı takım standup toplantısında mekanik hareketler yapıyor cansız ifadelerle, arka planda durgun bir çevik tahta
Matt Lewandowski

Matt Lewandowski

Son güncelleme 16/02/202615 dk okuma

Takımınız Scrum Rehberini takip ediyor. Bir Ürün Sahibiniz, bir Scrum Master'ınız ve çok disiplinli bir geliştirme takımınız var. Her töreni zamanında yürütüyorsunuz. Yine de hiçbir şey çalışıyormuş gibi görünmüyor. Problem genellikle Scrum etkinliklerini atlıyor olmak değildir. Problem, onları üretken görünen ama aslında takımınızın teslim etme yeteneğini aşındıran şekillerde yapıyor olmaktır. Bunlar anti-desenlerdir: normal görünen, belki hatta doğru görünen, ancak Scrum'un bağlı olduğu geri bildirim döngülerini sessizce yok eden uygulamalar. İşte en yaygın 15'i, tören alanına göre organize edilmiş. Birkaçından fazlasını tanıyorsanız, süreciniz bir yapı bandı değil cerrahi müdahale gerektirir.

Sprint Planlama Anti-Desenleri

Sprint planlama tüm sprint için yönü belirler. Ters giderse, sonrasında gelen her şey zarar görür. Bunu iyi yapma hakkında tam bir rehber için bkz. etkili sprint planlama toplantıları nasıl çalıştırılır.

1. Sprint Hedefi Yok

Neye benziyor: Takım kapasite bitene kadar backlog'un üstünden öğeler çekiyor. Tutarlı bir tema veya amaç yok, sadece bir sürü bilet. Neden zararlı: Sprint hedefi olmadan, takımın ortak bir amacı yoktur. Kapsam sprint ortasında müzakere edilmesi gerektiğinde (ve her zaman gerekir), ne keseceğine karar vermek için bir çerçeve yoktur. Her bilet eşit derecede önemli görünür, bu nedenle hiçbir şey kesilmez ve sprint taşar. Nasıl düzeltilir: Her sprint planlama oturumunu, backlog öğelerini seçmeden önce sprint hedefini açıkça ifade ederek başlayın. Hedef "bu sprint neden önemli?" sorusunu cevaplar. Ürün Sahibi bir tane açıklamıyorsa, backlog muhtemelen yeniden yapılandırılması gerekir. Adım adım bir yaklaşım için Scrum törenler rehberi tam planlama akışını kapsar.

2. Ürün Sahibi Kapsamı Belirler

Neye benziyor: PO planlama oturumuna önceden seçilmiş bir öğe listesiyle girer ve takıma bu sprintte ne tamamlayacaklarını söyler. Geliştiriciler başını sallıyor. Neden zararlı: Sprint planlama bir müzakere, bir görev değildir. PO kapsamı belirlediğinde, geliştiriciler taahhütlerinin mülkiyetini kaybeder. Bunun önemli olmadığını öğrendikleri için gerçekçi olmayan zaman çizelgelerine itiraz etmeyi bırakırlar. Sonuç: kronik aşırı taahhüt ve sessiz tükenmişlik. Nasıl düzeltilir: PO öncelikleri önerir ve iş bağlamını açıklar. Geliştiriciler, kapasitelerine ve Yapılmışlık Tanımına dayanarak realistik bir şekilde taahhüt edebilecekleri şeyleri seçerler. Scrum Master bunu bir teslim değil, çift yönlü bir sohbet olarak kolaylaştırır.

3. Planlama Yerine Tarafındaki Tahmin

Neye benziyor: Takım sprint planlama sırasında tahmin edilmemiş backlog öğeleriyle karşılaşır ve her biri için 30+ dakika hikaye puanlarını tartışmakla harcamaktadır. Neden zararlı: Planlama işi seçmek ve taahhüt etmek içindir, ölçeklendirmek değil. Tahmin planlama yapısına sızdığında, toplantı uzar, enerji düşer ve takım planlama bölümünü acele eder. Daha da kötüsü, PO maliyeti bilinmeyen öğeleri uygun şekilde öncelendiremez. Nasıl düzeltilir: Sprint boyunca gerçekleştirilen backlog iyileştirme oturumları sırasında tahmin edin. Tahmini yapılandırılmış ve zaman kısıtlı tutmak için Planlama Pokeri kullanın. Öğeler sprint planlamasına geldiğinde, zaten tahminleri ve net kabul kriterleri olması gerekir. Tahminleriniz grup düşüncesinden veya bağlanma önyargısından sızlanıyorsa, Anonim Planlama Pokeri yardımcı olabilir.

4. Kronik Aşırı Taahhüt

Neye benziyor: Takım tamamlayabileceğinden daha fazla işi taahhüt eder, sprint kapalı sprint. Tamamlanmayan öğeler devam eder. Hız numaraları kağıda iyi görünür çünkü tahminler şişirilmiştir. Neden zararlı: Aşırı taahhüt, takımı sprint taahhütlerini gerçek yerine ilham verici olarak işleme alması için eğitir. Ayrıca paydaş güvenini aşındırır. Her şey "yakında" olduğunda, hiç kimse bir şeyin gerçekten ne zaman yayınlanacağını tahmin edemez. Nasıl düzeltilir: Gerçek hızı (taahhüt edilen değil, tamamlanan) izleyin ve onu bir sonraki sprint için üst sınır olarak kullanın. Planlanmamış iş için tampon bırakın. Takım sürekli erken bitirse, her zaman backlog'tan daha fazla öğe çekebilir.

Günlük Standup Anti-Desenleri

Günlük standup, geliştiricilerin koordine olmasına yardımcı olmak için vardır. Amacından saparsa, herkesin korktuğu toplantı haline gelir. Daha sağlıklı bir yaklaşım için bkz. standup araçları ve asenkron alternatifler.

5. Scrum Master'a Durum Raporu

Neye benziyor: Takım üyeleri Scrum Master veya yöneticiye karşı kalır ve dün ne yaptıklarını bildirir. Sohbet yukarı doğru değil, yana akıyor. Geliştiriciler birbirlerine konuşmuyorlar. Neden zararlı: Standup, bir koordinasyon aracı yerine mini performans incelemesi haline gelir. İnsanlar engelleri ortaya koymak yerine, üretken gibi görünmek için güncellemelerini optimize ederler. Takım, oynadıkları için değil, iletişim kurmaları için birbirlerine yardımcı olmak için fırsatları kaçırır. Nasıl düzeltilir: Scrum Master fiziksel ve sözel olarak geri adım atmalı. Kelimenin tam anlamıyla dairenin dışında durun. "Ne yaptın?" yerine "takımın ne bilmesi gerekiyor?" sorusuna soruları yönlendirin. Tahtayı yürümek (biletleri sağdan sola tartışmak) doğal olarak odağı insanlardan işe kaydırır.

6. 15 Dakikadan Uzun Sürüyor

Neye benziyor: Standup düzenli olarak 25, 30, bazen 45 dakika sürüyor. Sorun giderme ve tasarım tartışmaları patlıyor. İnsanlar dizüstü bilgisayar getirmeye başlıyor. Neden zararlı: Uzun standuplar tüm takımın sabahına yapılan bir vergidir. Toplantının disiplini olmadığını işaret ederek daha fazla sapmayı davet eder. Takım üyeleri çoklu görevlere başlarlar veya zihinsel olarak bağlantıyı keserler. Yan sohbete dahil olmayan insanlar hiç bir şey için 30 dakika kaybettiler. Nasıl düzeltilir: Görünür bir zamanlayıcı kullanın. Bir konu daha derin tartışmaya ihtiyaç duyduğunda, bunu not edin ve yalnızca ilgili kişilerle bir takip planlayın. Kullanılacak cümle: "Standup'tan sonra bunu çevrimdışı tartışalım."

7. Standup'ta Sorun Giderme

Neye benziyor: Birisi bir engelle bahsediyor ve tüm takım 10 dakika birlikte hata ayıklamakla harcıyor. Veya teknik bir soru bir mimari tartışma başlatıyor. Neden zararlı: Bu iki farklı etkinliği karıştırır: senkronize etme ve işbirliği yapma. Standup sorunları tanımlamak içindir, çözmek değil. Sorun giderme üstlere aldığında, katılmayan insanlar boş oturur ve toplantı uzunluk açısından öngörülemez hale gelir. Nasıl düzeltilir: Takımı standup'ı çözmek için değil, açığa çıkarmak için kullanmaya eğitin. Format şöyle olmalı: "X'te takılı kaldım. [Belirli kişi] tarafından yardıma ihtiyacım var." Sonra o iki kişi standup'ın hemen ardından buluşur. Takımın geri kalanı işe döner. Bir yöneticinin masanın başında oturduğu ve takım üyelerinin rahatsız ve sessiz görünerek, duvar üzerinde boş not sabitlerinde olduğu gösterilen retrospektif toplantısı

8. Sadece Scrum Master Konuşuyor

Neye benziyor: SM her kişinin biletlerinde geziniyor, güncellemeler istiyor ve tahtayı anlatıyor. Geliştiriciler tek kelimelik cevaplar veriyorlar. Standup işlevsel olarak tek kişilik bir gösteridir. Neden zararlı: Geliştiricileri ajanstan mahrum eder. SM sohbeti yönettiğinde, takım kendini organize etmez; yönetiliyor. Ayrıca SM koordinasyon için tek bir başarısızlık noktası haline gelir. Hasta olduysa, standup çöker. Nasıl düzeltilir: Takım üyeleri arasında kolaylaştırmayı döndürün. Hatta daha iyisi, açık kolaylaştırmayı tamamen ortadan kaldırın ve takımın tahtayı kendileri yürümesini sağlayın. SM gözlemlemeli, desenleri not etmeli ve günlük eşitleme için mikro yönetim yapmak yerine sistemi sorunlarını retrospektife getirmeli.

Retrospektif Anti-Desenleri

Retrospektif, süregelen iyileştirmenin motoru olması gerekiyordu. Kırıldığında, takım öğrenmeyi durduruyor. Retros'u iyi çalıştırma hakkında bir rehber için bkz. etkili bir çevik retrospektifi nasıl çalıştırılır ve yapılandırılmış formatlar için retrospektif aracımızı deneyin.

9. İşlem Öğelerinin Takibi Yok

Neye benziyor: Takım retro sırasında iyi iyileştirmeler belirler. İşlem öğeleri yapışkan notlara yazılır. İki hafta sonra, kimse ne olduğunu hatırlamıyor. Sonraki retro aynı sorunları ortaya koymaktadır. Neden zararlı: Bu, retrospektif katılımını öldürmenin en hızlı yoludur. İnsanlar önerileri eriştir kayboluşunu gördüğünde, onları yapmayı bırakırlar. Retro hiçbir sonucu olmayan bir harita oturumuna dönüşür ve sonunda insanlar (fiziksel olarak mevcut olsalar da) zihinsel olarak katılmayı durdurar. Nasıl düzeltilir: İşlem öğelerini retro başına ikiye veya üçe sınırlayın. Her birine belirli bir sahip atayın. Bir sonraki retrospektifi, başka bir şeyden önce önceki sprintin işlem öğelerini gözden geçirerek başlatın. Tamamlamayı görünür şekilde takip edin. Bir işlem öğesi bir sprintte tamamlanamazsa, çok büyüktür. Bölün.

10. Her Sprint'te Aynı Format

Neye benziyor: Her retrospektif aynı formatı kullanır. Başla/Durdur/Devam. Her. Tek. Sprint. Takım tam olarak neyi bekleyeceğini bilir ve cevapları hakkında eleştirel düşünmeyi bırakmıştır. Neden zararlı: Tanıdıklık otopilot üretir. Format asla değişmediğinde, takım üyeleri toplantı başlamadan cevaplarını ön hesaplarlar. Sorular onları farklı düşünmeye zorlamadığından yeni içgörüler keşfetmeyi bırakırlar. Retro bir onay kutusu alıştırması haline gelir. Nasıl düzeltilir: Retrospektif formatlarını döndürün. Bir sprint Yelkenli formatını kullanın, bir sonraki 4Ls'i, ardından bir zaman çizelgesi egzersizi. Her format farklı içgörü türlerini ortaya koymaktadır. Retrospektif fikirleri postu aralarından seçim yapabileceğiniz bir format kütüphanesine sahiptir. Çeşitlilik kendisi bu toplantının yatırım yapmayı hak ettiğini sinyal eder.

11. Yönetici Katılımı Dürüstlüğü Öldürüyor

Neye benziyor: Bir yönetici veya paydaş retrospektife katılır. Takım sadece güvenli konuları tartışır: standup zamanları, araç tercihleri, toplantı odası akustiği. Kimse gerçek sorunlardan bahsetmiyor. Neden zararlı: Retrospektifler savunmasızlık gerektirir. İnsanların başarısızlıkları adlandırması, proses arızalarını işaret etmesi ve bazen kişilerarası uyuşmazlıkları ele alması gerekir. Kariyer üzerinde yetkiye sahip biri odadayken hiçbiri gerçekleşmez. Takım "başarı tiyatrosuna" geçer ve gerçek sorunlar gizli kalır. Bu düşük psikolojik güvenlik ders kitabı örneğidir ve çevik törenlerini sessizce baltalar. Nasıl düzeltilir: Takım onları oy birliğiyle davet etmedikçe yöneticiler retrospektife katılmamalı. Kuruluş kültürü yönetim görünürlüğü gerektiriyorsa, retro'dan sonra eylem öğeleri (ham tartışma değil) özetini paylaşın. Scrum Master'ın işi bu sınırı korumaktır.

12. "Her Şey İyi" Retrospektifi

Neye benziyor: Kimse endişe gündeme getirmiyor. Takım işlerin iyi gittiğini kabul eder. Retro 10 dakika içinde sona erer. Ama sprint ölçümleri farklı bir hikaye anlatıyor: kaçırılan taahhütler, artan döngü zamanları, artan teknik borç. Neden zararlı: "Her şey iyi" neredeyse hiçbir zaman doğru değildir. Genellikle üç şeyden birini anlamına gelir: takım konuşmak için ortama yeterince güvenmez, retro formatı gerçek sorunları ortaya koymaz veya takım geçmiş öneriler göz ardı edildiğinden iyileştirme konusunda pes etmiştir. Nasıl düzeltilir: Duygularla değil verilerle başlayın. Sprint'in gerçek ölçütlerini gösterin: hız trendi, taşınan öğeler, kaçan hatalar, döngü zamanı. Sayıların sohbeti başlamasına izin verin. Retro'dan önce anonim giriş koleksiyonu kullanın, böylece insanlar adlarını eklemeden hassas konuları gündeme getirebilirler. Ve anti-desenleri 9 ve 11'in oyunda olup olmadığını yeniden düşünün.

Sprint Gözden Geçirme Anti-Desenleri

Sprint gözden geçirmesi, takımın paydaşlardan gerçek geri bildirim alma şansıdır. Tekill yönlü bir sunuma dönüşürse, bu geri bildirim döngüsü kapanır. Sağlıklı incelemeler hakkında tam bir rehber için bkz. sprint gözden geçirmesi nasıl çalıştırılır.

13. Sadece Demo, Geri Bildirim Yok

Neye benziyor: Takım tamamlanmış işin cilalı bir demosunu sunuyor. Paydaşlar izler, başını sallıyor, alkışlıyor. Kimse soru sormaz veya değişiklik önermez. Toplantı "harika iş, takım" ile sona erer. Neden zararlı: Sprint gözden geçirmesi bir demo değildir. Bu bir müfettiş-ve-uyarla etkinliğidir. Paydaşlar geri bildirim sağlamazsa, takım boşlukta inşaat yapıyor. Uyumsuz beklentiler birden çok sprintte bileşik hale gelir ve çok büyük bir kurs düzeltmesi kaçınılmaz hale gelir (ve pahalı). Nasıl düzeltilir: Gözden geçirmeyi sunumlar değil, sorular etrafında yapılandırın. Her ek gösterildikten sonra, açıkça şunu sorun: "Bu beklediğinize uyuyor mu? Ne değiştirirsiniz? Sonra ne önceliklendirelim?" Paydaşlara sadece izleyebilecekleri değil, etkileşim kurabileceği ürünü verin. Demo'yu önceden gönderin, böylece toplantı tartışmaya odaklanabilir.

14. Paydaş Katılımı Yok

Neye benziyor: Sprint gözden geçirmesi sadece Scrum takımı tarafından yapılır. Müşteri yok, kullanıcı yok, iş paydaşı yok. PO bazen üçünün rolünü oynar. Neden zararlı: Dış perspektifler olmadan, takım gerçek kullanıcı ihtiyaçlarından kaybolur. PO tüm geri bildirim için darboğaz haline gelir ve varsayımları sorgulanmaz. Takım, doğrudan doğrulama yerine kullanıcıların istediğini düşündüğü PO'yu oluşturur. Nasıl düzeltilir: Paydaş katılımını kolaylaştırın. Takvim davetiyelerini erken gönderin. Toplantıyı kısa ve odaklanmış tutun. Neler gözden geçirileceğini gösteren tek sayfalık bir gündem paylaşın. Ana paydaşlar gerçekten katılamazsa, gözden geçirmeyi kaydedin ve asenkron geri bildirim toplayın. Ancak süregelen katılmama, kuruluşun Scrum sürecini önemsemediğini işaret eder, bu da ölçeklemeye değer bir sorundur.

15. PO Çalışmayı Onaylar veya Reddeder

Neye benziyor: Sprint gözden geçirmesi bir kabul kapısı haline gelir. PO her öğeyi gözden geçirir ve son dakika değişiklik istekleri ile sıklıkla "kabul" veya "reddedildi" olarak damgalar. Neden zararlı: Bu sprint gözden geçirmeyi işbirlikçi tartışma yerine kalite denetimine dönüştürür. PO ve takım arasında düşmanca bir dinamik yaratır. Ayrıca Yapılmışlık Tanımı'nın işini yapmadığı anlamına gelir. "Yapılan" öğeler reddedilebiliyorsa, takımın yapılmışlık tanımı belirsizdir veya PO kabul kriteri olarak gizlenmiş yeni gereksinimler ekliyor. Nasıl düzeltilir: Kabul sürekli olmalı, gözden geçirmeye toplanmış değil. PO, tek bir tören için kaydetmek yerine sprint boyunca eklemeleri gözden geçirmelidir. Sprint gözden geçirmesi, bireysel öğeleri kapı tutmak değil, stratejik yön ve paydaş geri bildirimine odaklanmalı.

Kuruluş Anti-Desenleri

Bazı anti-desenler herhangi bir tek töre ait değildir. Tüm süreci enfekte ederler.
🧟Zombie Scrum

Takım Scrum'un her hareketini geçer, ancak hiçbir anlamlı şey çıkmaz. Sprintler kimsenin kullanmadığı eklemeler üretir. Paydaşlar dikkat etmeyi durdurdu. Takım herhangi bir amaç duygusunu kaybetti. Törenler olur ama bunlar boştur. Bu genellikle birpsikolojik güvenlik eksikliğindenkaynaklanır ve takımın ele alma güçsüz hissettiği kuruluş işlevselliği ile birleşir.

🔧Sertleştirme Sprintleri

Takım tüm sprintleri "stabilizasyon" veya "sertleştirme" ye ayırır, hataları düzeltir ve "özellik sprintleri" sırasında biriktirilmiş teknik borcu öder. Bu bozuk Yapılmışlık Tanımı'nın doğrudan bir semptomudur. Kalite çalışması yalnızca özel sprintlerde yapılıyorsa, kalite sürecin parçası değildir. Her sprintte test, refactoring ve belgeleme yapın.

📊Performans Ölçütü Olarak Hız

Yönetim, takımları karşılaştırmak, bireysel performansı değerlendirmek veya hedefler belirlemek için hızı kullanır. Takım öngörülebilir şekilde yanıtlar: tahminleri şişirir. 5 puanlı bir hikaye 8'e döner. Hız yükselir. Gerçek çıktı yapmaz. Proses sağlığını gerçekten ortaya koyan ölçütler için,döngü zamanı ve akış hızı gibi akış ölçütlerinebakın.

Takımınızı Nasıl Teşhis Edersiniz

Hangi anti-desenin takımınıza uygulanacağından emin değilseniz, bu listeyi sağlık değerlendirmesi olarak kullanın. Açıkça yapın, ideal olarak bir retrospektif sırasında takım olarak.

Sprintimizin tüm takımın açıklayabileceği net ve ifade edilen bir hedefi vardır.

Geliştiriciler, PO'dan atama değil, kapasite temelinde kendi sprint kapsamını seçerler.

Backlog öğeleri sprint planlamasına girmeden önce tahmin edilir.

Sprint taahhütümüzün %80 veya daha fazlasını tutarlı bir şekilde tamamlarız.

Standup, durum değil koordinasyona odaklanarak 15 dakikanın altında kalır.

Takım üyeleri standup'ta sadece Scrum Master'a değil birbirlerine konuşurlar.

Önceki sprintin retrospektif işlem öğeleri tamamlanmıştır.

İnsanlar retrospektiftlerde sadece lojistik değil gerçek endişeler gündeme getirirler.

Paydaşlar sprint incelemelerine katılır ve uygulanabilir geri bildirim sağlar.

Hiçbir zaman özel "hata düzeltme" veya "sertleştirme" sprintlerimiz yoktur.

Hız performans değerlendirmesi için değil planlama için kullanılır.

Takımın Yapılmışlık Tanımı test ve belgeleme içerir.

Işaretli olmayan herhangi bir öğe, ele almaya değer bir anti-desene işaret eder. En çok acı veren ile başlayın ve sonrakine geçmeden önce düzeltin. Hepsini aynı anda düzeltmeye çalışmak kendi anti-desenidir.

Özet

Anti-desenler sinsi çünkü süreç gibi görünüyor. Takım Scrum yapıyor, her töreni yürütüyor, Jira'daki her alanı dolduruyor. Ancak sonuçlar yoktur. Deseni tanımak ilk adımdır. Bunu düzeltmek, odada aslında ne olup bittiği hakkında dürüstlük ve bunu değiştirmek için kuruluş cesareti gerektirir. Bir taneyle başlayın. Düzeltin. Çalıştığını kanıtlayın. Sonra birini yürütün. Süregelen iyileştirme, bir sprintte bir kez bu şekilde çalışması gerekir. Daha sağlıklı Scrum törenlerini destekleyen araçları arıyorsanız, Kollabe anonim tahminle Planlama Pokeri sağlar, yapılandırılmış formatlarla retrospektifler ve dağıtılmış takımları hizalı tutan asenkron standuplar.

Anti-desen, yüzeyde üretken görünen veya Scrum'un yapısını takip eden ancak takımın değer sunma yeteneğini gerçekten baltalayan bir uygulamadır. Anti-desenler genellikle takımlar kısayollar bulduğu veya Scrum'ın etkinlikleri ve rolleri arkasındaki niyeti aşan alışkanlıklara düştüğünde kademeli olarak gelişir.

Zombie Scrum, Scrum'un tüm hareketlerini hiçbir sonuç olmaksızın geçen takımları tanımlar. Sprintler olur, törenler zamanında çalışır ve tahta güncellenir, ancak takım paydaşlara, amaca ve müfettiş ve uyarlanma yeteneğine bağlantı kaybetti. Terim Johannes Schartau, Christiaan Verwijs ve Barry Overeem tarafından popülerleştirilmiştir. Tipik olarak kuruluş işlevselliği, düşük psikolojik güvenlik ve takım ile ürünlerini kullanan insanlar arasındaki kopukluk kombinasyonundan kaynaklanır.

Retrospektif ile başlayın. Bu açıkça süreç iyileştirmesi için tasarlanmış tek törendir. Belirli anti-deseni veriler ile gündeme getirin: sprint ölçütlerini gösterin, birden çok sprintte desenleri işaret edin ve bir sprint boyunca denemek için somut bir deney önerir. Bir şikayetiştirir değil, bir hipotez olarak çerçeveleyin. Retrospektif anti-desenleri sorun ise (desenler 9-12), bu takımın müfettiş ve uyarlanma yeteneğini korumak için kuruluş yetkisine sahip olan Scrum Master'a bir sohbettir.

Evet, kısa vadede. Takımlar kırık standuplar çalıştırırken, retro eylem öğeleri atlarken ve her sprintte aşırı taahhüt ederken özellikleri sunabilir. Ancak sürdürülebilir değildir. Anti-desenler gizli maliyetler yaratır: tükenmişlik, teknik borç, güven erozyonu ve ciro. Hasar zamanla bileşiktir. Anti-desenleri erken ele alan takımlar uzun vadeli hızları ve takım sağlığını korur.