Sprint İçinde Gelen Plansız İşleri Ne Yapmak Lazım?

Öncelikle şunu kabul etmek lazım, bazı işler gerçekten de bekleyemez. Canlı ortamdaki bir sorun, kritik bir bug, rekabetin gerektirdiği ani öncelik değişimi gibi. Tabii, Türkiye gerçeğinde, patronun ani bir hevesle “şu işi önümüzdeki haftaya kadar ne yapın edin bitirin” dediği durumlar ve kurumlar da yok değil.

Photo by Bonneval Sebastien on Unsplash

Strateji

Siz bir çevik takım olarak 2 haftalık bir Sprint ile tek amaca odaklanmış, iyi tanımlanmış kapsamı en iyi şekilde yapmaya çalışan bir takımsınız. Dışarıdan herhangi bir sebeple, öncelikleri değiştirmenizi isteyen bir talep geldi. İlk tepkiniz “olmaz abi” demek olabilir. Ama bu doğru değil. Bu durum adeta sizin en iyi dengeyi korumanız gereken bir strateji oyunu.

İki şekilde ele alabiliriz.

• Kısa vadeli aksiyonlar
• Sorunu kökten çözen yaklaşımlar

Kısa Vadeli Aksiyonlar

1- Değişikliği kabul etmek

Bir önceki Sprint’te yapılmış olan bir değişiklik öngörülemeyen sorunlara yol açmış olabilir. Veya gerçekten de anında ihmal edilemeyek bir öncelik değişimi olabilir.

Kural: Yeni gelen iş mevcut Sprint’i kırmayacak, Sprint amacını değiştirmeyecek, takımın az bir ek eforla absorbe edebileceği büyüklükte bir task ise kabul edilmelidir. Tüm takımın bunda hemfikir olması ve product owner’ın da bu değişikliği onaylaması gereklidir.

Tabii ki dizinizi kırıp, her gelen işi Sprint’e eklemeye kalkarsanız Sprint’ler planlandığı gibi bitmez, amaca hizmet eden bir iş çıkartamazsınız. En iyi ihtimalle bile yeni gelen işi kabul ettiğinizde velocity (hız) biraz düşecektir. Ama bir şekilde büyük bir sorun çıkartmadan altından kalkarsanız dert yok.

Bu aksiyonun sık sık, her Sprint’te gerçekleşmesi farklı sorunların semptomu olabilir.

2- İşi bir sonraki Sprint’te ele almak

Mevcut Sprint’te yaptığınız bir user story’nin scope’u değişti ve çok daha kompleks bir hal aldı. Ya da bugün hemen ele almasanız da yer yerinden oynamayacağına inandığınız bir yeni iş geldi. Tabii bu sizin düşünceniz, iş sahibi veya product owner aynı şekilde düşünmüyor olabilir.

Bu durumda, stratejiniz işin scope’u değişen kısmını ayrı bir task olarak çerçeveleyip bir sonraki Sprint’in backlog’una atmaktır. Eğer herkes bu işin yeterince acil olmadığında sizinle aynı fikirde değilse, maalesef sosyal yeteneklerinizi kullanarak ikna etmek sizin göreviniz. product owner’ı kendi yanınıza çekmek iyi bir strateji olabilir. Eğlenceli bir iş olmadığının farkındayım, ama başka çare yok.

3- Mevcut işlerden birisiyle yer değiştirmek

En hızlı, en pratik aksiyonlardan birisi budur. Diyelim ki gelen yeni iş yaklaşık 8 story point’lik ve sizin de elinizde Sprint’ten çıkartırsanız diğer taskların etkilenmeyeceği 8 story point’lik bir task var. Bu durumda o task’ı Sprint kapsamından çıkartıp, yenisini koyarsınız iş biter.

Ama tabii bu iş her zaman o kadar kolay olmayabilir. Çıkarttığınız task, o Sprint’teki bazı taskların önkoşulu oluyor olabilir. Veya bir sonraki Sprint’te yapılacak işin temelini bu task ile atıyor olabilirsiniz. Durumun böyle olup olmadığını anlamak için tüm takımın değişiklikte hemfikir olması gerekir.

Not: İlla ki aynı büyüklükte story point’li bir task bulup yer değiştirmek zorunda değilsiniz. 8 story point’lik bir task’ı koymak için bir tane 5 bir tane de 3 puanlık task çıkartmak da mümkün.

4- Buffer bırakmak

Bazı şirketler vardır, Sprint sırasında iş gelmesi artık gündelik hayatın bir parçası olmuştur. Genellikle küçük yazılım ekibi olan bu şirketlerde, ekip canlı ortama destek verirken hem de yeni bir ürün ortaya çıkartmaya çalışıyor olabilir. Bu kurumlarda canlı ortamda nasıl bir sorunun ortaya çıkacağını veya misal, pazarlama departmanının o gün nasıl bir kampanya çıkmak isteyebileceğini öngöremezsiniz.

Artık her Sprint’iniz kırılır hale gelmiştir ve “bu şirkette Scrum uygulanamaz”, “bizim işimiz günlük, her an değişebilir” denildiğine tanık olmaya başlayabilirsiniz.

Bu tür şirketlerde Sprint’leri planlarken buffer bırakmak bir çözüm olabilir. Diyelim ki, geçmiş tecrübenize bakarak bir ekibin bir Sprint süresince ortalama 70 story point tamamlayabildiğini biliyorsunuz. Bu durumda ekibe, Sprint planlama oturumunda 45–50 story pointlik iş atarsınız. Bir kaç işi de kenarda “lazım olursa” diye tutarsınız. Eğer o Sprint süresince yeni iş gelmezse yedekte beklettiklerinizi Sprint’e eklersiniz.

Bu yöntemin dezavantajı, buffer’ı asla tam öngöremezsiniz. Bazen az, bazen çok olabilir. Bu da doğal bir verimsizlik sorunu getirecektir. O nedenle 3. yöntemdeki “yerine başka task koymak” genelde daha iyi bir çözümdür. Ama kurumun diğer departmanlarında yönetilemeyen bir düzensizlik varsa ve şirket öncelikleri sürekli değişiyorsa, bu yöntem kaçınılmaz olabilir.

Sorunu Kökten Çözen Yaklaşımlar

1- Product owner ve stakeholder’ları eğitmek

Sprint tamgaz giderken bir product owner, pazarlama departmanının çok acil bir işi için değişiklik getirdi. Siz -az önce bahsettiğim- kısa vadeli aksiyonlar ile sorunu bir şekilde çözdünüz. Tam da sorun bertaraf edildi derken, bir kaç gün sonra aynı product owner benzer bir ikinci değişiklik için geldi. Tek fark, bu sefer değişikliği talep iş sahibi (stakeholder) finans departmanı. Siz sürekli bu değişiklikleri ele almaktan Sprint’e bakamaz hale gelebilirsiniz.

Sorun; bariz olduğu şekilde, bu product owner’ın iş sahiplerine hayır diyememesinden kaynaklı. Sprint’in kırılıp, takımın hedefinden kopmasını elbette ki ne product owner, ne de iş sahibi istemez.

Sorunun sebebi:

1. sonradan gelen işlere gereksiz önem addedilmesi,
2. kurum kültürü sorunu
3. product owner’ın “hayır” diyememesi.

Çözüm maalesef kısa vadeli değil. Alınması gereken acı reçete: Product owner ve iş sahibini (stakeholder) çevik yazılım geliştirme süreçleri hakkında bilgilendirmek.

Doğru önceliklendirme yapabilmek, ekibin odağını dağıtmamak, işleri sıraya sokmayı bilmek, önceliklendirme vs… hep bir kurumsal dönüşüm ve bilinç gereken işler. Kurum içi eğitimler düzenleyerek işe başlamanızı ve 1–1 oturumlarla devam etmenizi öneririm.

2- Kaliteyi Arttırın

Yeni bir ürün sahaya çıkarttınız ve bug’ların ardı arkası gelmiyor. Ya da ekibiniz yeni bir ürün teslim aldı ve önünüzde uzun bir yapılacaklar listesi var. Ama maalesef canlı ortamda sürekli sorun çıkıyor, sistem zaten kör topal gidiyor, yeni feature yapmanın nesnel faydası aslında çok az.

Bu tür durumlarda, öncelikle kabul edilebilir bir kalite standartı tutturarak işe başlamanız gerekli. Yaptığınız her yeni geliştirme, sorunu daha da büyütmekten öteye gitmeyecektir. Bir şekilde bir önceki maddedeki gibi, product owner ve stakeholder’larını ikna ederek işe başlamanız gerekiyor. Onlara teknik borç kavramından bahsederek başlayın. Yeni yapılan işlerin geliştirmesinin geçmiş sorunlardan dolayı ne kadar uzun sürdüğünü, kaliteye ayrılacak bir sürenin hem kaliteyi hem de yeni özelliklerin geliştirme süresini nasıl olumlu etkileyeceğinden bahsedin.

Bu aksiyonun kötü yanı, çok bacaklı olması. Öncelikle birilerini ikna etmeniz, sonra da sorunlu bir ürünü toparlamanız ve kaliteye yatırım yapmanız gerekiyor. Bu süreç maalesef bazen çok uzun sürebilir. Bazen de, ürünü yeniden yazmaktan bile zor olabilir. Aradaki dengeli bir noktayı bulmaya gayret edip, minimum kabul edilebilir kalite standartına yatırım yapmanızı öneririm.

3- Bağımlılıkları kaldırın

Yeni bir uygulama geliştirmeye başladınız ve uygulamanız bir backend sisteme ihtiyaç duyuyor. Backend’in sunduğu Rest API’leri başka bir ekip size sağlıyor ve bir de baktınız ki bu API’ler tam bir facia. Data dokümante edildiği gibi gelmiyor, gelse de eksik sonuç dönüyor vs… Bu durum sizin Sprint’inizde sürekli bir ayak bağı oluyor ve ek iş yapmanıza sebep oluyor.

Bu tür durumlarda yapılması gereken en akıllıca adım, kalıcı veya geçici olarak bağımlılığı kaldırmaktır. Eğer kalıcı kaldıramıyorsanız, en azından geliştirme süresince iki takımı birbirinden bağımsız bir şekilde geliştirme yapabilecek ortamı hazırlamak faydalıdır.

Bunu backend ekibinden bir Mock API talep ederek yapabilirsiniz. Bilmeyenler için Mock API, gerçekte işi yapmayan, kendisine yapılan her istekte dokümante edildiği şekle uygun hard-coded cevap dönen API’ler demektir. Bu sayede siz çalışmanıza devam ederken, diğer ekip de kendi sorunlarıyla mücadele edebilir.

Eğer bu imkanı sağlayamıyorlarsa, aradaki protokolü mimikleyen kendi stub’larınızı yazabilirsiniz. Belki de kendi ekibinizden birisini diğer ekibe yardım etmesi için geçici olarak görevlendirmek de bir fayda sağlayabilir.

4- Süreçleri gözden geçirin

Buraya kadar bahsedilen tüm yöntemleri denediniz ama maalesef yine de Sprint’lerinizin kırılmasını engelleyemiyorsanız ve sürekli hedeflediğiniz sprint amacının gerisinde kalıyorsanız bu durumda süreçleri gözden geçirmeniz gerekebilir.

İlk olarak Sprint’leri kısaltmayı düşünebilirsiniz. 2 haftalık Sprint’leriniz sürekli sekteye uğruyorsa öncelikle 1 haftalık Sprint’lere geçmeyi deneyin. Bu sayede Kısa Vadeli Aksiyonlar 2. maddedeki bir sonraki Sprint’e almak yöntemi daha kullanışlı hale gelebilir.

Bu da işe yaramazsa belki de gerçekten de Scrum sizin için en doğru yöntem olmayabilir. Sprint’ler yerine bir akış üzerinde çevik prensipleri uygulamaya çalışan Kanban yöntemine göz atabilirsiniz. Kanban bu tarz ad-hoc işlere daha iyi ayak uyduran, adaptasyonu yüksek bir yöntemdir.

Bu kadar radikal değişikliklere geçmek yerine, eğer ekibiniz yeterince yüksekse, ekibin bir kısmını Kanban ekibi yapıp, kalan kısmını Scrum ekibi yapmak genelde en iyi çözümdür. Tarihçesi uzun şirketlerde çevik prensipleri uygularken, çoğu zaman bu yöntemi uyguladım ve çok iyi sonuç aldım.

Burada dikkat edilmesi gereken şey, Kanban ekibinin bir süre sonra bıkkınlığa uğraması ve kendilerini Scrum ekiplerindeki kadar değerli hissetmemesi sorunsalıdır. Bunu çözmek için de iki ekip arasında geçişkenlik yapılması sağlanmalı, bir rotasyon politikası uygulanması gerekir.

Bonus Materyal: Bu yazıyı hazırlarken benim de ziyadesiyle esinlendiğim, AgileLab’in cheat sheet’i bu prensipleri çok güzel özetliyor. Yazıcıdan bastırıp duvara asmanızı ve sürekli göz önünde bulundurmanızı öneririm.

Cheat sheet’i PDF olarak şu adresten indirebilirsiniz.