“Antipatern”( antipattern) tabiri,  yazılım dünyasında kullanılır. Genel olarak  başlangıçta çekici, kolay görünen çözümlerdir. Resimde olduğu gibi bol çiçekli bir yol gibi, ancak daha sonra problemi çözmekten uzak ,daha büyük sorunlara , sizi resimdeki gibi korkunç canavarlarla karşılaştırabilecek davranışlar, çözümler olarak nitelendirilir.

Scrum kılavuzunda da belirtildiği üzere;

İnsanların mümkün olan en yüksek değere sahip ürünleri üretken ve yaratıcı bir şekilde geliştirirken, karmaşık ve adaptasyona açık sorunları ele alabildikleri bir çerçeve.

Scrum tanıtırken kullanabileceğiniz anahtar 3 sıfat dersek te;

• Basittir
• Anlaması kolaydır
• Ustaca yönetmek zordur.

45 dk ya da 1 saat içerisinde Scrum’daki bütün unsurları birisine anlatabilir, anlamasını sağlayabilirsiniz. Aslında çoğu zaman karmaşık problemlerle karşılaştığımızda ve iş çıkarabilmek için tek bir yetkinlik ve uzmanlığın yeterli olmadığı durumlarda içgüdüsel olarak geliştirdiğimiz  “task force”,”war-room” gibi uygulamaların çoğaltıldığı bir çerçeve. Ve bütün araştırmalar ve deneyimler gösteriyor ki 1990 lı yılların başından beri kullanılan Scrum, bu çerçeve doğru uygulandığında başarımızı ve verimliliğimizi arttırıyor.

Ama ,ya anlaması çok kolay, ne gerek var böyle yapmaya ben tavsiye edildiği gibi uygulamadan ve ustalaşmadan ara çözümler, kısa yollarla bunu uygulayayım yani “antipatern”ler geliştireyim ve kullanayım dediğinizde beklenen başarı ve etki düşüyor ve o zaman Scrum-But dediğimiz formunu alıyor.

Daha önceki bir yazımda dövüş sanatları uygulamasındaki çırak-usta-profesyonel seviyelerinin (Shu-Ha-Ri) doğru şekilde geçilmesinin öneminden bahsetmiştim. Bu konsepti hatırlamak isterseniz blog yazıma buradan ulaşabilirsiniz.

Scrum’ın geceden sabaha bir mucize yaratmayacağını, insanların yeni çalışma şekillerine alışması ve özellikle kültürel dönüşüm için zamana ihtiyaç olduğunu aklımızda tutalım. Çok sık karşılaştığımız dolayısı ile yorumsuz olarak aşağıda en kötü “antipatern”lerden bahsedeceğim.

• Takım kendisine görev atanmasını bekler, Scrummaster’da görevleri atar ve bu şekilde kendi kendi kendini örgütleyen ve karar alan bir takımın gelişmesini tahrip eder.
• ScrumMaster’ın ismindeki “Master” kısmı teknik ya da domain uzmanı gibi algılanır ve takımdaki en deneyimli yazılımcı ScrumMaster olarak belirlenir, bu şekilde takım geliştirme kapasitesini olumsuz etkilemiş olur.
• Product ownerlar takımı en iyi şartlarda sadece Sprint planlama ve Review da görür, Sprint süresince takımla ve müşteriyle vakit geçiremez, dolayısıyla hızlı karar alma ve öğrenme süreci yavaşlar.
• Sprint planlama toplantısında bütün taskler kişilere baştan atanır ve tüm Sprint boyunca kollobrasyon yaratmaksızın herkes sadece kendi taskının sorumluluğunu alır, takım değil, bireysel çalışma devam eder.
• Bu şekilde kollobrasyon ve takım olarak günlük karar alma kabiliyetine imkan sağlayan Daily Scrum yapmazsak olur mu sorularını duymak çok şaşırtıcı değil:) Hemen daily Scrum’dan vazgeçilir.
• Kendi başına anlam ve değer üreten fonksiyonlar takip edilmez, ister sonuca ulaşsın, ister ulaşmasın tasklara odaklanılır.
• Retrospektif yapılmaz.
• Review yapılmaz, yapılırsa da sadece o sprintte ne üretildiğine bakılır, genel olarak servis ya da ürünün hangi noktada olduğu ve büyük resim unutulur.
• Toplantılarda “timebox” gözetilmez.
• Sprint devam ederken Sprint kapsamının büyük bir oranı değişir.
• Sprint planlamada sadece ne yapılacağı konuşulur, Nasıl sorusunun cevabı için ilerleyen günlerde zaman kaybedilir.
• Bir şirkette takımlar “velocity” üzerinden karşılaştırlır.

Bir çırpıda aklıma gelip yazdıklarım bunlar , sizler de bu “antipatern”lere ekleme yapmak isterseniz bize yazın, yazıya ekleyelim.

Bir sonraki yazıda görüşmek üzere, çevik kalın.