Scrum'ın 5 Yanlış Umutları ve Nasıl Düzeltilir

Pek çok klasik, hiç bitmeyen çatışma gibi, geliştirme ekiplerinin nasıl örgütlenmesi ve kendi kendini yönetmesi gerektiği konusundaki tartışmalar da sürüyor. Şu anda, neredeyse Scrum hayranlarından daha fazla eleştirmen var gibi görünüyor. En yaygın üç şikayet şunlardır:

1. Süreç, işin merkezinde yer alabilir.
2. Mikro yönetim için başka bir adla kolayca karıştırılabilir.
3. Günlük stand-up, kişinin varlığını haklı çıkarması gereken bir toplantı gibi hissedebilir.

Diğer durumlarda, Scrum'ın rolleri uygun şekilde temsil edilmez. Bazen, ürün sahibi bir sprint içinde çok fazla şey ister veya sprint ortasında öncelikleri değiştirmek ister - saplantılı bir şekilde hızı korumaya ve öğrendiği her yeni Scrum törenini benimsemeye odaklanan bir Scrum ustası. Çerçeve ile bir süre sonra ortak bir soru ortaya çıkıyor gibi görünüyor: “Biz mi yoksa metodoloji mi?”

Scrum'ın Yanlış Umutları

Yukarıda özetlenenler gibi sayısız işlev bozukluğu olsa da, çoğu için basit bir temel neden, Scrum'ın bir organizasyon içindeki temel sorunları yalnızca süreci takip ederek çözmek için tasarlanmamasıdır. Bunu fark etmemek, yeni ekipleri neredeyse başlar başlamaz tehlikeye atabilir.

Yanlış Umut 1: Scrum, Takımların Daha Hızlı Çalışmasını Sağlar

Scrum, dışarıdan birine ek kaynaklar eklemeden süreci hızlandıracakmış gibi gelen terminoloji kullanır. Scrum'a yeni katılan bir ekip olarak terminolojide çıkmaza girmek kolaydır (örneğin, Scrum ustası nedir? Ürün sahibi ile ürün yöneticisi arasındaki fark nedir? Hikaye noktaları nelerdir ve nasıl atanır?)

Daha da sıkıntılı olanı, birçoğunun hız ve sprint gibi terimleri görmesi ve "hız" düşünmesidir. Ancak, Scrum da dahil olmak üzere herhangi bir Çevik metodolojinin amacı, bitmiş bir ürün sunmaktır. Sonunda, ekibiniz Scrum konusunda daha yetkin hale geldikçe, yeni işlevleri daha hızlı sunabileceksiniz. Ancak, hız mutlaka birincil hedef değildir. Bu ayrım, Scrum ekibiniz içinde ve ayrıca Scrum metodolojisini desteklemek için şirketinizde farkındalık oluşturduğunuzda açıkça belirtilmelidir.

Hız satmıyorsunuz; tamamlama satıyorsun.

Yanlış Umut #2: Scrum'a Sıkı Uyum Şirket Kültürü Sorunlarını Çözecek

Herkesin farklı çalışma tarzları vardır. Bazı insanlar toplantıları sever. Diğerleri “sıkı çalış, sıkı oyna” gibi ifadeler kullanır. Şirketinizin değer verdiği çalışma tarzı ne olursa olsun, hem avantajlarını hem de dezavantajlarını kabul ettiğinizi bilmek önemlidir. Toplantılara değer veren bir şirket, büyük olasılıkla günlük ayakta kalma sorunlarıyla mücadele edecektir. Agresif ve hız odaklı ekipler, bir sprint içinde kapsam kayması ile ilgili sorunlar yaşayacaklardır.

Özellikle yeni kurulan takımlar için büyük resmi gözden kaçırmak bazen kolaydır. Önemli olan, sürecin her son parçasını takip etmek yerine bitmiş bir ürün sunmaktır. Metodolojiyi suçlamak yerine, her zaman hedeflerinize ulaşmak için çalışma tarzınızı iyileştirmenin yollarını arayın.

Yanlış Umut #3: Kritik Katkıda Bulunanlar Delegelerini Toplantılara Gönderebilir

Metodolojiye başladığınızda, delegeler yerine asıl ekibin katılması çok önemlidir. Geliştiricilerden gördüğüm neredeyse evrensel bir şikayet varsa, o da Scrum ustalarının ve ürün sahiplerinin gerektiğinde mevcut olmaması ve delegelerinin yetkilendirilmemiş olmasıdır. Hiç kimse bir toplantıya gelmeyi sadece karar verebilecek kişinin müsait olmadığının söylenmesini beklemekten hoşlanmaz.

Yetkilendirme yaygın bir uygulama olabilir, ancak Scrum'da katılımcıları da yetkilendirmeniz gerekir.

Yanlış Umut #4: Günlük Stand-up'lar Herkesi Daha Fazla Odaklanmaya Zorlayacak

Günlük stand-up toplantıları yalnızca herkesin son 24 saatte ne yaptığına odaklanmamalıdır. Bir sorunu çözmek için ortaya çıkan barikatlara veya yeni yaklaşımlara öncelik vermek çok daha önemlidir.

Scrum, belirli rollerin, özellikle de Scrum ustasının iddialı ancak aşırı güçlü olmamasını gerektirir. Scrum master'ın tamamlanmış ürünlere yol açan olumlu bir ortam yaratması önemlidir.

Yanlış Umut #5: İlk Denemede Başarılı Olacağız

Scrum, tahminde bulunmayı, tümdengelimli düşünmeyi ve hata yapmayı içerir. İnsanlar nadiren ilk denemede doğru anlarlar. Scrum her bakımdan yinelemelidir: sadece bitmiş bir ürüne nasıl ulaştığınız konusunda değil, aynı zamanda süreci nasıl yönettiğiniz ve çalıştırdığınız konusunda da. Scrum, ekiplerin benimsemesi için düşük bir giriş engeline sahip olacak şekilde tasarlanmıştır, ancak aynı zamanda çerçeveye katılımı yineleme ve sürekli olarak iyileştirme taahhüdü gerektirir.

Kırık Bir Scrum Süreci Nasıl Onarılır

Scrum, batık maliyet yanılgısına karşı dirençlidir. Scrum'ın yinelemeli doğası, etkisiz süreçleri uyarlamak veya atmak için fırsatlar yaratır. Scrum süreciniz beklediğiniz kadar etkili değilse, aşağıdaki önerilerden bazılarını göz önünde bulundurun.

Beklentilerinizi İyileştirin

Pazara sunma süresini kısaltmak, ilgi çekici ürünler yaratmak veya ekiplerin işbirliği yapmasına yardımcı olmak olsun, başarı bağlılık ve zaman alır. Yeni ekipler için, elde edilmesi gereken makul bir kilometre taşı, her sprintten sonra üretim ortamınıza çalışan, test edilebilir kodu dahil edip edemeyeceğinizdir.

Gelişmiş ekipler, istek üzerine derleme, test etme ve devreye alma yetenekleriyle başarıyı ölçebilir. Yeni özelliklere yönelik kullanıcı tepkilerini ölçebiliyor ve ölçebiliyor musunuz? Daha geniş organizasyon, ekibin üründe yaptığı değişiklikleri desteklemeye hazır mı?

Katılımcılarınızı Güçlendirin

Ekip üyelerine ekip için değerlerini nasıl artırabilecekleri konusunda çevrimdışı mentorluk yapmak önemlidir. Karar vermeleri isteniyorsa, diğer ekip üyelerini ne zaman ve nasıl dahil edecekleri konusunda onlara koçluk yaparak güvenlerini artırın. Yöneticilerin engelleri aşmaya ve gerektiğinde ekibi desteklemeye hazır olması gerekir.

Sorunları Proaktif Olarak Ele Alın

Scrum, şirketinize yeni bir görünüm kazandırmak için tasarlanmamıştır. Sorunların ele alınmamasına izin verdiyseniz, ürün geliştirme sürecinizde bu sorunların ortaya çıktığını görme olasılığınız çok yüksektir. Scrum ustaları, ekip üyelerinin çatışma hissini azaltmak için geri bildirimlerini yapılandırmaları için olumlu bir yol yaratmak üzere tasarlanmış çerçeveler sunabilir.

Böyle bir örnek, “Keşke, Merak Ediyorum, Ne Olursa” çerçevesidir. Takım tartışmaları veya geçmişe dönük incelemeler sırasında, bir takım üyesi bu üç ifadeden biriyle beyanını açarak geri bildirimde bulunabilir. Örneğin, "Keşke stand-up toplantıları o gün farkında olmam gerekebilecek engellere daha fazla odaklanabilse" diyebilirler. “Seviyorum…” gibi kendi açıcınızı da kullanabilirsiniz.

Toplantılar sırasında yardımcı olabilecek bir başka yapılandırılmış geri bildirim çözümü, Brian Robertson tarafından oluşturulan ve Zappos gibi şirketler tarafından kullanılan Holocracy'den Triyaj yöntemidir. Örneğin, katılımcılar tartışmak için bir “gerilim” gündemi oluştururlar. Her katılımcı, sorununu “Gerginliğim var” diyerek anlatır ve ardından sorunu çözmek için ihtiyaç duyduğu kişi ve kaynakları listeler. Holokrasi, katılımcıları sorunları doğrudan "gerginlikler" olarak ele almaya teşvik ederek, katılımcıların bir çatışma ortamı yaratmadan özgürce iletişim kurmalarını sağlar.

Sorunları Çözmek ve Süreci Yinelemek için Retrospektifleri Kullanın

Pek çok şirkette geriye dönük incelemeye gereken önem verilmemektedir. Bunun temel nedeni, birçoğunun geçmişe bakışın eski tartışmalar, çatışmalar ve şikayetler için bir yer olduğu korkusudur. Takımın değerlerini ve şirket kültürünü yansıtan temel kurallar geliştirmesi takım için hayati önem taşır.

Aynı derecede önemli olan, statik süreçlere yatırım yapmaktan kaçınma ihtiyacıdır. Bir kez işe yarayan sonsuza kadar çalışmayabilir. Birçok takım, katılımcı cirosu ile mücadele eder. Katılımcılar başka ekiplere atandığından, terfi ettirildiğinden veya şirketten tamamen ayrıldığından bu, birçok şirkette yaygındır. Takımın bileşimi geliştikçe, Scrum'da her şeyin yinelemeli olduğuna bağlı kalmamak önemlidir. Hatalar olacak, ancak umarım siz yineledikçe kısa ömürlü olacaklardır.

Scrum, İlkeler Mevcut Olduğunda En İyi Çalışır

Takımda olmak, mevcut ve müsait olmayı taahhüt etmelisiniz. Ürün geliştirme, muhtemelen şirketinizin uzun vadeli büyümesini iyileştirmek için üstlenebileceği en önemli süreçtir. Bu nedenle, yeni ürün geliştirmenin birincil yolu olan Scrum sürecinin hak ettiği ilgiyi görmesi önemlidir. Pek çok ortamda, geliştirici ekip genellikle şirketin hedeflerini yönlendiren kararlardan ve tartışmalardan bağımsız olarak çalışır. Scrum farklıdır. Scrum, kararların, yönün ve gelişimin tek bir süreç olarak bir araya geldiği yerdir. Scrum metodolojisinde yer alan toplantılardan delege göndermek veya ekip üyelerini dışarıda bırakmak bir süreç için çok önemlidir.

Özet: Bozuk Bir Scrum Sürecini Onarabilirsiniz

Yinelemeli doğası nedeniyle, Scrum, işi çok fazla ilerlemekten ve kötü bir fikir veya kötü uygulanmış bir süreç olarak sonuçlanabilecek şeylere bağlı kalmaktan korumaya yardımcı olur. Bu ilkeye bağlı kalmak, geçmişteki hatalardan kurtulmaya ve Scrum sürecini yinelemeli olarak iyileştirmeye yardımcı olabilir.

Sahip olduğunuz bireylere ve ekibe odaklanmanız önemlidir. Ekip üyeleri değişir. Tüm projeler farklıdır. Bir sürece sıkı sıkıya bağlı kalmak her zaman en iyi sonuçları vermez. Süreç dışında ekip üyelerinize yatırım yaptığınız şey, süreç içinde kendinizi nasıl yürüttüğünüz kadar önemlidir.

Scrum esnek olabilir. Bir şey çalışmıyorsa, hem Agile içinde hem de dışında diğer çerçevelerden öğeler eklemeyi düşünün. Çatışmacı tartışmalara yol açan yapılandırılmış iletişim tarzlarını belirleyin ve benimseyin.

Scrum, ekiplerin değişen müşteri ihtiyaçlarına yanıt olarak eksiksiz ürünler oluşturmasını sağlayarak uzun vadeli yatırım getirisi için faydalıdır. Scrum, büyük fikirlere daha fazla gelişme alanı verirken, sizi aşırı bağlanmaktan kötü fikirlere alıkoymak için muhtemelen en iyi metodolojidir.