Sprint Planlama Toplantısı Nasıl Yapılır?
Çevikliğin, bir kültür ve “Neden” sorusuna bir cevap olduğunu daha önceki yazılarımda anlatmıştım. Scrum ise bu kültürü oluşturmanın, uygulamanın ve yaşatmanın yollarından biridir. Ayrıca “Nasıl” sorusunun cevabıdır. Scrum’da herşey iyi bir planlamayla başlar. Çevikliği ve Scrum’ı yeni öğrenenlerle sohbet ettiğimde genelde Scrum’da plan olmadığına ve bu nedenle işlerin yolunda gitmediğine dair yakınmalarını duyarım. Aynı şekilde Çeviklik’ten yakınırkende dokümantasyon olmadığını ve bu nedenle birçok sorun yaşadıklarını anlatırlar.
Evet! Scrum’da plan yoktur. Daha etkili olan planlama vardır. Bir plan yaparsanız ona uymak zorunda kalırsınız, bir değişiklikle karşılaştığınızda planı değiştiremezsiniz ve değişikliği kabul etmek istemezsiniz. Şimdi sizlere Scrum’da iyi bir planlamanın nasıl yapılabileceğini ve Çevik Yazılım Geliştirme Manifestosu’nun değerlerinden biri olan “Kapsamlı dökümantasyondan ziyade çalışan yazılım” ile ne anlatılmak istendiğini açıklamaya çalışacağım.(1)
Scrum’da resmi olarak belirtilen dört toplantıdan biri olan Sprint Planlama Toplantısı iki bölümden oluşur. NE ve NASIL bölümlerine ayrılan toplantının ilk bölümünde ne iş yapılacağı, ikinci bölümünde ise bu işin nasıl yapılacağı konuşulur. Geliştirme Takımı, Ürün Sahibi ve Scrum Master’ın toplantıya katılımı zorunludur. Dört haftalık Sprint’ler koşan takımlarda toplantı süresi 8 saatle sınırlıdır. Doğru orantıyla iki haftalık Sprint’ler koşan takımlarda ise 4 saatle sınırlıdır.
Yukarıda Sprint Planlama Toplantısı’na dair kısa ve öz bilgiler verdim. Şimdi bir kontrol listesi hazırlayacağız. Kontrol listesi kullanılmasına karşı olsamda yoğun ve stresli ortamlarda ritüellerde dikkat edilmesi gereken anahtar noktalar gözden kaçabilir. Bu nedenle birkaç Sprint kontrol listelerinin kullanılmasını faydalı bulurum. Birkaç Sprint kullanıldıktan ve bilgi, alışkanlığa dönüştükten sonra kontrol listeleri bırakılmalıdır. Kontrol listesi kullanmak alışkanlık olmamalıdır, kontrol listesi içeriğinde var olan bilgi alışkanlık olmalıdır. Eğer kontrol listesi kullanmak alışkanlık olursa sadece kontrol listesi içeriğinde var olan noktalara dikkat edilecektir. Bu da gerçekleştirilen ritüelin eninde sonunda yapmak için yapılan bir aktivite haline dönüşmesine neden olacaktır. Kendi kendine organize takımların yaratıcılığının ölmesinin başlıca nedenlerden biri budur, yapmış olmak için yapılan aktiviteler.
Aşağıda belirtilen maddeleri Sprint Planlama Toplantısı’nın iki yarısı ve genelinde dikkat edilmesi gereken maddeler olacak şekilde üç ayrı bölümde detaylı şekilde anlatmaya çalışacağım. Bu yazımı bir seri halinde paylaşacağım. Böylece toplantının genelinde, NE ve NASIL bölümünde dikkat edilmesi gerekenleri ayrı ayrı bulabileceksiniz. Buna göre toplantının genelinde dikkat edilmesi gerekenler:
Genel
Toplantı zamanında başladı mı?
Bir toplantının zamanında başlaması ya da başlamaması toplantının yapıldığı kurumla ilgili bir çok bilgi verir. Bunlardan iki tanesi çok önemlidir. Birincisi, eğer toplantı zamanında başlamıyorsa, toplantı katılımcılarından bazıları gelmiş bazıları gelmemişse yapılan israfla ilgili çok kısa bir hesaplama yapalım.
Toplantının 10 dakika geç başlaması durumunda 7 kişilik bir Geliştirme Takımı, 1 Ürün Sahibi ve 1 Scrum Master bulunan Scrum Takımı’nda israf edilen süre 9 * 10 = 90 dakika demektir.
Bu, gerçekleştirilen israfın maddi boyutudur, bir de manevi boyutu bulunuyor. Toplantının başlama saatinde hazır bulunmamak birey olarak bizim gerçekleştirdiğimiz bir eylemdir. Gerçekleştirdiğimiz eylemler ise organizasyon ya da topluluk bazında düşünüldüğünde kültür olarak karşımıza çıkar. Kültür ise bir organizasyona ya da topluluğa virüs gibi bulaşıcı bir şekilde dağılır. Bugün bizim geç kaldığımız bir toplantıya gelecek Sprint Planlama Toplantısı’nda başka biri neden göstermeksizin geç kalacaktır ve bu konuda kendini haklı görecektir. Scrum Takımı’nın kendi kendini yöneten yapısının önündeki en büyük engellerden biri olarak karşımıza çıkacaktır. Toplantıya zamanında katılanlar ile katılmayanlar arasında iletişim problemleri çıkacak ve çalışmaya harcanması gereken enerji ve zaman iletişim problemine ve çatışmalara harcanacaktır. Bu da yine uzun vadede ekonomik kayıplara ve sosyal ilişkilerin bozulmasına neden olacaktır. Sadece toplantıya birkaç dakika geç kalmadan sosyal ilişkileri bozulmasına gelmişsin biraz saçma olmuş diye düşünebilirsiniz. Bunun gerçekleştiğini gördüğüm için paylaşıyorum.
Toplantıya zamanında katılım oldukça önemli bir erdemdir. Kolay gibi görünsede bu kültüre sahip olmayan organizasyonlarda insanların bunu başarması çok güçtür. Bunun önüne geçebilmek için Late-Box denilen uygulama gerçekleştirilebilir. Late-Box geç kalan üyenin geç kaldığı dakika başına belirli bir ücret ödemesidir. Bazı takımlarda çok başarılı şekilde işlese bile işlemediği takımlarda bulunmaktadır. Başka bir yöntemse badi denilen ve askerlikte olduğu gibi takımdaki her bireyin bir badisinin olmasıdır. Biri geç kaldığında bunun hesabı geç kalan kişiye değil onun badisine sorulur. Böyle bir çapraz kontrol sistemi de iletişimin iyi olduğu takımlarda eğlenceli bir şekilde çalışabilir. En güzel yöntem ise herkesin bilinçli şekilde davranıp toplantıya zamanında katılmasıdır diye düşünüyorum.
Sprint içinde eski adıyla grooming yeni adıyla refinement(detaylandırma) aktivitesi gerçekleştirdiniz mi?
Önceki Sprint’lerde Sprint Planlama Toplantısı’nda konuştuğunuz İş Maddelerini daha iyi anlayabilmek ve çözümleyebilmek için Sprint Planlama Toplantısı’ndan önce detaylandırma aktivitesi gerçekleştirdiniz mi? Detaylandırma aktiviteleri, yeni adıyla refinement aktiviteleri, gelecek Sprint’te gerçekleştirilecek İş Maddeleri’nin önceki Sprint’lerde Geliştirme Takımı tarafından değerlendirilmesi anlamına gelmektedir. Böylece Geliştirme Takımı üyeleri, Ürün Sahibine geribildirimde bulunabilirler. Bu geribildirimler doğrultusunda Ürün Sahibi ilgili İş Maddelerini olgunlaştırmak için çalışır. Bu aktivite ile dışa olan bağımlılıklarda ortaya çıkarılmış olur ve işlerin gerçekleştirilmesindeki riskler azaltılır. Riskler azaldığındaysa işler daha pürüzsüz ilerleyecektir.
Böyle bir duruma örnek; Kurumsal Krediler modülü için hizmet veren takımın bir İş Maddesi için CRM ekibinden alacağı web service ihtiyacı olduğunu düşünebilirsiniz. Bu ihtiyaç Sprint ortasında ya da Sprint Planlama Toplantısı’nda değil öncesinde ortaya çıkarılmalıdır. Böylece CRM ekibi ilgili web service’i kendi İş Listesine ekleyebilir ve sizin gelecek Sprint’lerinizden birine hazır edebilir. Bu web service Kurumsal Krediler ekibinin hizmetine açıldıktan sonra kendi geliştirmelerini dışa bağımlılığı kalmadan tamamlayabilir.
Sprint Değerlendirme Toplantısı’nda alınan geribildirimlerden, İş Listesine eklenen bir madde bulunuyor mu?
Sprint Değerlendirme Toplantısı’nda müşterilere -iş birimlerine, hizmet verilen kişilere, aslında ürünü gerçekten kullanacak kişilere- gösterilen çalışan yazılım hakkında alınan geribildirimler verilen hizmetin ya da oluşturulan ürünün geleceğine yön verir. İyi bir Ürün Sahibi burada alınan geribildirimleri dikkatlice değerlendirir ve çalışan ürüne dönüşmesi için Geliştirme Takımı’nın önüne getirir.
İlgili kişileri Sprint Değerlendirme Toplantısı’na davet edip onlardan geribildirimler aldınız mı? Ürün Sahibi bu geribildirimleri değerlendirip İş Listesine ekledi ve Geliştirme Takımı’na getirdi mi?
Bir önceki Sprint Retrospektif Toplantısı’nda alınan kararlar içinde Sprint Planlama Toplantısını etkileyen aksiyonlar varsa bunları yerine getirdiniz mi?
Sprint Retrospektif Toplantısı’nda çıkarılan aksiyonlar Sprint’i ya da Sprint Planlama Toplantısı’nı etkileyebilir. Çıkarılan aksiyona örnek:
Ürün Sahibi, İş Listesi’nde bulunan maddeleri yeterince olgunlaştırmadan* Geliştirme Takımı’nın önüne getirebilir. Bu durumda Sprint Planlama Toplantısı’nın NE bölümü olması gerekenden çok daha uzun sürecektir. Takım, sınırlanan süreye uyamayacaktır. Sprint’i etkileyen bölümü ise Geliştirme Takımı’nın doğru bir Sprint Backlog oluşturmasına engel olmasıdır. Bu olunca Geliştirme Takımı doğru bir planlama yapamaz. Bu engeli kaldırmak için Ürün Sahibi’nin İş Listesini olgunlaştırmış olması ve toplantının NE bölümünde İş Listesindeki maddelerin çok detayına girilmeden geçilmesi gerekir.
*İş Listesindeki olgunlaştırılmış maddelerin şu özellikleri bulunur:
Geliştirme Takımı’nın anlayabileceği, doğru büyüklük verebileceği, dışarı bağımlı olmadan geliştirilebileceği, Ürün Sahibi’nin, Geliştirme Takımı’nın sorularını cevaplayabileceği maddelerdir.
Sprint Planlama Toplantısı için belirlenen süreye uyuldu mu?
Sprint Planlama Toplantısı’nın süresi bir Sprint’in %5’i olarak belirlenmiştir. Sprint Planlama Toplantı’sının belirlenen bu süreye uyması Scrum Takımı’nın tekrar edilebilir bir ritim yakalaması için önemlidir. Tekrar edilebilir ritim yakalanması, deneysel süreç kontrolü için bir gereksinimdir. Her Sprint’te farklı sürelere sahip Sprint Planlama Toplantıları ortamdaki şeffaflığı bozacak ve Sprint Planlama Toplantıları’nın karşılaştırılmasının önünde bir engel teşkil edecektir. Halbuki sürekli aynı süreye ve çevreye sahip Sprint Planlama Toplantıları daha rahat karşılaştırılabilir. Böylece çıkarılacak adaptasyonlara daha kolay karar verilebilir. Sınırlı süreli etkinlikler bilimsel bir deneydeki sabitler olarak düşünülebilir.
Sınırlı süre uygulamasının önemli olan diğer bir yanı ise israfın önüne geçilmesidir. Toplantının belirlenen süreye uymaması israf yaratır. İsrafın önüne geçilmesi Çevik yaklaşımlarda benimsenen Yalınlık pratiklerinden biridir. Organizasyonun daha yalın böylece daha çevik olması anlamına gelir. Takımın bu disipline ve anlayışa sahip olması bulunduğu organizasyon için büyük önem taşır.
Scrum Master, Scrum’a uygun olmayan yerlerde müdahalede ya da hatırlatmalarda bulundu mu?
En iyi Scrum Master olmayan Scrum Master denir. Scrum Takımı’nı, Scrum pratik ve kurallarında o kadar ileri seviyeye taşımıştır ki artık Scrum Takımı’na pratiklerin ya da kuralların hatırlatılmasına gerek yoktur. Geliştirme Takımı kendi kendini yöneten bir yapıya sahiptir. Bu nedenle de bir Scrum Master’a ihtiyacı yoktur. Böyle söylense bile Scrum Master’a ihtiyacı olmayan bir takımın oluşması için Ürün Sahibi, Geliştirme Takımı ve var olan Scrum Master’ın çok büyük bir özveri ile uzun süre çalışması gerekir.
Herşeyin başlangıcı iyi bir planlamadır. Sprint’e iyi başlarsanız başarılı bir şekilde bitirme şansınız yüksek olur. İyi Scrum Master, Scrum Takımı’nın iyi planlama yapmasını sağlar. Bu yazı altında paylaştığım her maddeyi dikkatli şekilde gözlemlemesi ve gerekli yerlerde müdahalelerde bulunması gerekir. Örneğin mimari bir karar alınması gerekirse bu kararı alacak kişiler Geliştirme Takımı üyeleridir. İşin nasıl yapılacağına karar veren rol Ürün Sahibi değildir. Şöyle çelişkili bir durum yaşanabilir; gerçekleştirilmek istenen ürün iki farklı teknoloji ile yapılabilir. Örneğin bir web uygulamasını hem lisans satın almanız gereken hem de açık kaynak bir teknolojiyle geliştirebilirsiniz. Geliştirme Takımı üyeleri lisans satın alınması gereken teknoloji ile bu ürünü geliştirmek isteyebilirler. Lisans satın almanız bütçenizdeki maliyeti artıracaktır dolayısıyla Ürün Sahibi’nin ROI’yı* yükseltme sorumluluğuna bunun etkisi negatif yönde olacaktır. Lisans satın almadan açık kaynak bir teknoloji kullanarak aynı ürün daha düşük bir maliyetle geliştirilebiliyorsa burada Ürün Sahibi konuyu açıklayarak müdahalede bulunabilir. Bu gibi ikilemler yaşandığında arayı bulmak ve doğru seçeneğe Scrum Takımı’nı yönlendirmek Scrum Master’ın sorumluluğundadır.
* Return On Invesment: Yatırım Getirisi
İş Listesindeki maddeler yazılırken herhangi bir yazım tekniği(User Story, INVEST, DEEP…) kullanılmış mı?
İş Listesi, geliştirilen ürün ya da verilen hizmete dair bütün bilginin bulunduğu dokümandır. İş Listesi Maddesi ise bu bilgilerin önceliklendirilmiş, sıralanmış, iş değerleri belirlenmiş maddeleridir. Bir İş Listesi Maddesi’nin belirli teknikler kullanılarak yazılmasının birçok faydası bulunur. Benim gözlemlediğim faydaları aşağıdaki gibidir:
- İş Listesi Maddesi okunduğu zaman herkes – Geliştirme Takımı, Scrum Master, Ürün Sahibi ve diğer paydaşlar – tarafından aynı şeyin anlaşılmasını sağlar.
- İletişimi kolaylaştırır.
- Riski azaltır.
- Düzeni sağlar.
- İşlerin daha çabuk yapılmasını sağlar.
İş Listesi Maddeleri’nde kabul kriterleri belirtilmiş mi?
Kabul Kriteri ve Bitti Tanımı sıklıkla karıştırılır. Bitti Tanımı yapılan işin kalitesini belirtirken Kabul Kriteri o işin işlevsel yönünü anlatmaktadır. Örneğin Giriş sayfasında “Beni Hatırla” seçeneğinin olması ve bu seçenek işaretlendikten sonra kullanıcının 3 gün boyunca o bilgisayarda hatırlanması o maddenin işlevsel yönünü anlatmaktadır. Bir madde için 4 – 5 kabul kriteri yazılması pratikte mantıklı olabilir, daha fazla yazılamaz mı? Elbet yazılabilir fakat karmaşaya yol açabilir.
(1) http://www.agilemanifesto.org/iso/tr/