Belirsizlikleri yönetmenin yöntemlerinden birisinin de projelerin başında uygulanabilecek sprint 0 tekniği olduğundan bahsetmiştik. Bugünkü yazımda da sprint 0 detaylarını aktaracağım.
Agile takımlar kurulmadan önce Product Owner’lar initial product backlog’u hazırlar, ilk sprint için de öncelikli PBI’ları refine ederler. Developer’lar da ilk sprintten itibaren de geliştirmeye başlarlar. Yalnız birkaç sprint sonrasında oluşabilecek bağımlılıklar, gerçekleşen risklerden ötürü takım ilerlemekte sıkıntı yaşayabilir. Bir de geliştirilen projede kurum dışı firmalar, third party ürünler var ise çıkabilecek sürprizler sözleşmesel şartlardan ötürü çok daha büyük problemlere sebep olabilir. Problem ortaya çıktığında ise “Biz Agile çalışıyoruz, Agile’da böyle”, “Ama başta analiz yapmadık ki”, “Waterfall’da ne güzel detaylı analiz yapardık” gibi söylemler duyulmaya başlanır. Projelerin başında uygulanabilecek 2-3 haftalık sprint 0 ile bu tip sürprizlerin yaşanma ihtimali azalacaktır.
Sprint 0’daki amaç projenin hem business hem de teknik anlamda high level seviyede değerlendirilerek bağımlılıkların, risklerin, belirsizliklerin ortaya çıkarılması ve product backlog’un da olgunlaşmasına katkı sağlamaktır. Ayrıca birkaç küçük bir development’la da sürecin, ortamın test edilmesi sağlanabilir.
Sprint 0 öncesi yapılabilecek hazırlıklar;
- Business ve teknik değerlendirmede bulunulacak talep sahipleri, kullanıcılar, teknik kişiler, bağımlılığı olabilecek paydaşlarla randevu ayarlanması
- Kullanılacak design thinking pratiklerinin belirlenmesi
- Belirlenen design thinking pratiğine göre hazırlık yapılması
- Özellikle cevabı aranacak soruların belirlenmesi
Sprint 0’ın ilk haftası:
İlk hafta business ağırlıklı değerlendirmelere ayrılabilir. İlk hafta boyunca talep sahipleri, kullanıcılar ile bir araya gelerek geliştirilecek üründen beklentiler, yaşanan sıkıntılar takım ve paydaşlarla beraber değerlendirilir.
İlk hafta için önerebileceğim design thinking pratikleri; persona belirleme, röportaj yapma, empathy map olabilir. Bunlar temel pratikler diyebiliriz, geliştirilecek projeye göre bu pratikleri daha da zenginleştirebilir. Bu pratikleri kullanarak gerçekleştirilen aktivitelerin yer aldığı 5 güne, Google “Design Sprint” olarak ifade etmektedir. 2010 yılından itibaren de aktif olarak da uygulamaktadır.
Belirlediğimiz personalarla bir araya gelerek röportaj sorularımızı soruyoruz. Burada özellikle belirtmek istediğim nokta ise analiz, yazılım, test ayrımı yapılmaksızın tüm takım üyelerinin personalarla röportaja dahil olması ve aynı soruların sorulmasıdır. Takım üyeleri kendi içinde farklı personlarla bir araya gelerek çıktıları sonradan birleştirebilirler. Herbir takım üyesinin dahil olması müşterinin problemini, ihtiyacını daha iyi anlamasını sağlayacaktır. Kulaktan kulağa değil direkt müşteriden dinlemek talebin daha da sahiplenilmesini sağlayacaktır. Her bir persona için empathy map de oluşturulabilir.
Bu haftanın sonunda ise talep edilen isteklerin, ihtiyaçların sebepleri takım tarafından da anlaşılmış, değerlendirmeler sonrası sahiplenilmiş oluyor. Aynı zamanda backlog’un olgunluğu artmış oluyor.
Diğer önemli bir çıktı ise kullanıcının bakış açısıyla yapılacak aktivitelerin sürecinin yer aldığı User Story Mapping’in oluşması.
Sprint 0’ın ikinci haftası:
İkinci hafta teknik ağırlıklı bir değerlendirmeye ayrılabilir. Geliştirilecek projenin genel mimarisi değerlendirilerek geliştirme sürecinde yaşanabilecek riskler, bağımlılıklar konusunda farkındalıkların artmasını ve alınabilecek aksiyonlarında da erken alınması sağlayacaktır. Third party bir ürün kullanılıyorsa ürünün yetkinliklerinin değerlendirilmesi sağlanacağından ürünle ilgili yaşanabilecek sürpriz de azalacaktır.
Sadece mimari ekiple değil de bilgi güvenliği, devops, operasyon, data ekipleri gibi projenin ilerleyen aşamalarında bağımlı olacağı düşünülen, kurum içinde uyulması gereken standartları koyan ekiplerle kısa kısa bir araya gelerek belirsizlikler minimize edilebilir.
Bu haftanın çıktısını da mimari altyapı, bağımlılıklar ve alınabilecek aksiyonların listesi olacaktır. Hatta kısa dönemli bir proje geliştiriliyorsa draft sprint hedefleri ve product burndown chart’ın çıkması sağlanabilir.
Sprint 0 boyunca ortamsal değişiklikler var ise onların kurulması sağlanabilir. Takım üyelerinin daha önce geldiği farklı takımlardan gelen ufak tefek işler kalmışsa onlar temizlenebilir, ufak birkaç development yaparak da ortamın, sürecin testini gerçekleştirilebilir.
Sprint 0’ı bu şekilde uygulamanın avantajları;
- Talep sahipleri, analiz, geliştirme, test uzmanlık alanları aynı noktada olabilecektir. İhtiyaç benimsenmiş, çok daha etkili çözümlerin çıkması sağlanacaktır.
- Mimari, bilgi güvenliği, operasyon, data gibi kurum içinde merkezi ekiplerle bilgi alışverişinde bulunulmuş hem takım hem de teknik ekipler aynı noktada olacaktır.
- User story mapping ile kullanıcının deneyimi ortaya çıkarılmış, değerli, öncelikli işler daha rahat görünecektir. Yapılacak, değiştirilecek işin de etkisinin farkındalığı artmış olacaktır.
- Bağımlılıklar ve riskler ortaya çıkarılmış olacak.
Sprint 0 sonunda gerçekleştirilerek review etkinliğinde tüm paydaşlar davet edilerek bu çıktılar paylaşılabilir. Herkesin aynı noktada olduğu, farkındalıkların arttığı, benimsendiği , hep beraber çözüm arandığı bir proje de belirsizlikler minimize olacağı gibi yüksek motivasyonla geliştirilmesi sağlanacaktır.
