Sprint Sonunda Bitmeyen İşler

Bu makalede sizlere Scrum Takımlar’ının sıklıkla karşılaştığı bir problem olan “Sprint Sonunda Bitmeyen İşler’den” bahsedeceğim. Bu işler neden bitmiyor, nasıl bitirilebilirler? Bitmeyen işleri sonraki Sprint’e taşımalı mıyız? Bitmeyen işi Geliştirme Takımı’nın hızına eklemeli miyiz? Bu konuları dilimin döndüğünce anlatmaya çalışacağım. Aklınıza takılan her konuda bana yazabilirsiniz.

İdeal durumda Sprint’e alınan her iş BİTTİ kriterine uygun şekilde tamamlanır ve teslimatı yapılır. Ne yazık ki, Scrum Takımlar’ında, Sprint sonunda bitmeyen işler yaygındır. Birçok farklı neden dolayı ideal durum gerçekleşmeyebilir. Bu tamamlanamayan madde ile ilgili birkaç soruyu akıllara getirir:

• Bir sonraki Sprint’e taşınmalı mıdır? İş Listesi’nde bu madde ile ilgili ne yapılır?
• Daha küçük parçalara ayrılmalı mıdır?
• Bu madde takımın toplam hızına eklenmeli midir?

Bir sonraki Sprint’e taşınmalı mıdır?

Teknik olarak Sprint’te bir iş bitirilemediğinde bu madde tekrar İş Listesi’ne eklenir. Ürün Sahibi tarafından kalan bu işin bir değerinin olup olmadığına karar verilir. Eğer Ürün Sahibi bu maddenin artık değer kazandırmayacağını düşünüyorsa bu maddeyi İş Listesi’nde alt sıralara atabilir yada İş Listesi’ne hiç eklemeyebilir. Ürün Sahibi kalan bu işin sıradaki Sprint’te değer kazandıracağını düşünüyorsa Sprint Planlama Toplantısı’nda bu maddeyi tekrar gündeme getirebilir ki genellikle bu yapılır. Kısaca Sprint’te bitirilmeyen bir iş otomatik olarak bir sonraki Sprint’e taşınmaz, Ürün Sahibi süzgecinden geçirilir.

Tamamı bitirilemeyen ve sonraki Sprint’lere taşınan madde daha küçük parçalara ayrılmalı mıdır?

Eğer bu madde bir sonraki Sprint’te bitirilecekse yeniden bir kullanıcı hikayesi yazmak israf olabilir. Zaten hali hazırda takımdaki herkes bu maddenin ne olduğunu biliyor. Yeni bir kullanıcı hikayesi yazarak kafa karışıklığına neden olmak anlamsız ve değer üretmiyor.

Bitirilemeyen madde dört beş Sprint gibi çok ileride gerçekleştirilecekse nelerin bittiği ya da bitmediğini hatırlamak zor olabilir. Bu nedenle orjinal madde küçük parçalara ayrılıp biten ve bitmeyen işler birbirinden ayrılabilir. Bitmeyen işler yeniden İş Listesi’ne eklenebilir ve zamanı geldiğinde bu madde tekrar değerlendirilebilir. Yeni bir kullanıcı hikayesi değer katıyorsa oluşturulmalıdır.

Toplam hıza eklenir mi?

Sprint sonunda BİTTİ Kriterine uymayan maddelerin BİTTİ olarak kabul edilmesi ve tamamıyla bitmeyen bu maddelerin takımın hızına eklenmesinin doğru bir pratik olduğunu düşünmüyorum. Akıllara hemen şu sorular gelebilir ve isyan edilebilir;

• Üzerine çok çalıştığımız ve işin çoğunluğunu bitirdiğimiz bu madde neden takım hızına eklenmiyor? Bu adil görünmüyor!
• Bir sonraki Sprint’e alıp tamamlayacağız. Bitirdiğimiz Sprint’te bu iş maddesinin hikaye puanının tamamını eklemeli miyiz?

Bu sorular ve bu isyanlar haksız değildir fakat tamamıyla bitirilmeyen işlerin bitirilmiş gibi gösterilmesi şeffaflığın bozulmasına neden olur. Bu birşeyleri gizler, gölgede bırakır diye düşünüyorum. Takım tamamını bitiremediği bir işi takım hızına eklememeli ve Sprint Retrospektif Toplantısı’nda neden bitiremediğini konuşmalıdır.

Bitirilemeyen madde dört beş Sprint sonra tekrar Sprint’e alınacaksa bölünmesinin iyi bir pratik olduğunu söylemiştim. Kalan işe yeniden hikaye puanı verilerek gelecek Sprint’lerde alınabilir.

Nedenleri Araştıralım, Retrospektifte Konuşalım!

Sprint’e alınan işlerin bitirilememesinin birçok nedeni olabilir. Bunlardan bazılarının önüne geçilebilir bazılarının önüne geçilemez – Sprint içinde Geliştirme Takımı’ndan birinin hasta olması, önüne geçilebilecek bir engel değildir.

Sprint’te işlerin bitmemesinin nedenleri genelde aşağıdaki gibidir:

• Sprint İş Listesi’ndeki maddelerin çok büyük olması
• Geliştirme Takımı’ndaki kişilerin yetkinliklerinin T şeklinde olmaması
• Takımın optimum seviyede çapraz fonksiyonel olmaması
• Ürün Sahibi ya da yönetim baskı yapmıştır, Geliştirme Takımı yapabileceğinden daha fazla iş almak zorunda kalmıştır
• Ürün Sahibi’nin ya da yönetimin baskı yapmadan Geliştirme Takımı’nın bir Sprint’te bitirebileceği işten fazlasını alması

Buraya birçok madde eklenebilir. Maddeler dikkatli okunursa altında gizli nedenler olduğu görülür. Retrospektif Toplantısı’nın amacı bu nedenleri açığa çıkarmak, konuşmak, çözüme kavuşturmak ve ilerlemektir.

Şimdi maddeler üzerinden tek tek geçerek altta yatan gizli sorunları bulalım!

• İş Listesine eklenen maddeler Geliştirme Takımı tarafından doğru anlaşılmalıdır. Eğer doğru anlaşılırsa bu madde için yapılan tahmin doğruya en yakın olur. Eğer doğruya yakın bir tahmin yapamazsanız, büyük iş listesi maddelerini Sprint’e alır ve bunları bitirememe riskiyle karşılaşırsınız. Böyle bir durumda Scrum Master, Ürün Sahibini ve Geliştirme Takımı’nı daha yakın ve birbirini anlayan bir iletişim kurmaları için gönüllendirmelidir.
• Scrum Takımı’nda çalışmaya başlamadan önce sadece kod yazan kişinin kod yazmaya devam etmesi ve test yapan kişinin test yapmaya devam etmesi olarak karşımıza çıkar. Geliştirme Takımı içinde kişiler hala Geliştirici rolünü tam anlamadığı ve uygulamadığı durumlarda sıkça  yaşanır. Örneğin 7 kişilik bir Geliştirme Takımı olduğunuzu ve sadece 1 kişinin test yaptığını düşünün. Sprint sonunda tüm işleri bitirmek biraz hayal gibi değil mi? Sonraki adımsa mini waterfall olabilir. Bu Sprint’te sadece geliştirme işini yapalım. Bir sonraki Sprint’te ise sadece test yaparız. Scrum Klavuzu’nda açıkça şu belirtilir: Bir Sprint’e alınan işlerin tamamının bitirilmesinden Geliştirme Takımı’nın tamamı sorumludur. Bu nedenle yetişmeyen iş bir test olsada önceki hayatında kod yazan kişi Scrum Takımı’nda çalışmaya başladıktan sonra testtende sorumlu olduğunun bilincinde olmalıdır. En derine inersek Scrum Master, Geliştirme Takımı üyelerine sorumluluklarını anlatamamış demektir. Hem çok iyi kod yazan biri olmak hem çok iyi analiz yapan biri olmak hem de çok iyi test yapan biri olmak zor bir iştir. Bir kişinin yetkinliğinin üst seviyede olduğu bölüm kod yazmak olabilir fakat işleri bitirebilecek kadar test yapabiliyor olması beklenir.
• Kişilerin yetkinliklerinin T şeklinde olması ile bir geliştirme takımının çapraz fonksiyonel olması genellikle karıştırılır. Yukarıdaki örnekten devam edecek olursak 7 kişilik bir Geliştirme Takımı kod yazma yetkinliği yüksek 5 kişi ve test yapma yetkinliği yüksek 2 kişiden oluşturulsaydı, Sprint sonunda bitmeyen işleri kalmayacak ya da daha az kalacaktı. Takımdaki bu ahengi oluşturmak takımı oluşturan kişinin sorumluluğudur.
• Bu maddede görüleceği üzere Scrum’ın yapı taşlarından biri olan kendi kendini yöneten takım olgusuna müdahalede bulunulmuştur. Scrum Master, Ürün Sahibi ya da organizasyonda yönetici rolündeki kişiler emir komuta ile Geliştirme Takımı’nı baskı altına almamalıdır. Bu yapılırsa Scrum’ın ihtiyacı olan şeffaflık bozulur, takım üyelerinin sorumluluk almasına ve takım üyelerinin çalışma isteğine engel olunur. Burada Scrum Master araya girip emir komuta uygulayan kişiyi uyarması beklenir. Eğer bunu yapan Scrum Master’sa çok daha büyük problemleriniz var demektir. Onlara odaklanmanızı tavsiye ederim.
• Bu iyi birşeydir. Geliştirme Takımı üyelerinin ne kadar hevesli olduğunu gösterir. Bu kötü birşeydir. Geliştirme Takımı üyelerinin takım olarak kendilerini tanımadığını gösterir. Eğer ikinci, üçüncü Sprint’ini koşan yeni bir Scrum Takımı’ysanız bunun olması gayet normaldir ve geriye bakarak ilerideki Sprint’ler için iyileştirmeler yapabilirsiniz. Eğer yirminci Sprint’ini koşan bir Scrum Takımı’ysanız ve hala bunu yapıyorsanız ciddi probleminiz var demektir. Nedir bu ciddi problem? Deneyciliği anlamamış dolayısıyla uygulayamıyorsunuz demektir. Yapılması gereken şey geride bırakılan Sprint’lerin ortalama hızı alınıp gelecek Sprint’te bu ortalama hız kadar iş almaktır.

Gördüğünüz gibi yaşanabilecek birçok durum bulunmaktadır. Örnekler benim en çok karşılaştıklarımdır. Scrum’ı ayakta tutan üç sütunu -şeffaflık, gözlem, adaptasyon- düşündüğünüzde birçok soruna cevap bulabilirsiniz. Cevabını bulamadığınız sorularda bana yazın, beraber bulalım 🙂