Yeni Kurulan Squad’lara Öneriler
Yeni yazımızda Agile koçlarımıza “Yeni Kurulan Squad’lara Hangi Tavsiyelerde Bulunursunuz?” diye sorduk. İşte sizin için cevapladılar.
Mutlu Çiçek, Agility Consultant
Yeni kurulan her takımın aslında ilk yapması gereken şeylerden birisinin takım olarak hareket edecekleri zemini ve çerçeveyi oluşturmak için “Takım Anlaşması” yapması olduğunu düşünüyorum. Takım Anlaşması, özellikle Agile Dönüşüm içinde olan organizasyonlarda sürekli öğrenme ve sürekli iyileşme hedefinde olan takımlar için bazı durumlarda ortaya çıkabilecek eski davranış biçimlerinin (eski kasların da diyebiliriz) devreye girmesini önlemek ve bu tür durumlarda nasıl hareket edilebileceğini göstermek için bir çerçeve çizmektedir. Kısaca, takım anlaşması takımın ortak değerlerinin, ortak hareket biçiminin yazılı halde ifade edilmiş biçimidir, yani bir çeşit sosyal kontrat durumu görmektedir. Bu yüzden Agile bir takım olsun ya da olmasın, her takım kurulumunda ilk yapılması gereken şeylerden birisinin bu kontratı oluşturmak olduğunu düşünüyorum. Bu kontratın da takımın gösterdiği davranış modellerine ve iş yapısına göre ayrıca sürekli canlı ve güncel tutulması da takım dinamiğinin sürdürülebilmesi adına çok önem taşımaktadır.
Emin Gürbüz, Agility Consultant
- Önce takımlarının net bir vizyonu olmalı; bu takım hangi vizyonu gerçekleştirmek için bir araya geldi? Ortak amaç birliği var mı? Aynı amaçlar için bir araya gelmiş mi? Bu önemli bir sorgulamadır.
- Takım, bu vizyonu gerçekleştirecek, uçtan uca değer yaratacak tüm yetkinlikleri barındırıyor mu? Takımda cross-functionality oluştu mu?
- Takımın “küçük” olması ve küçük kalması çok önemli. Yüksek üye sayısına sahip takımlar Empricism uygulamak için çok uygun değildir. 9’dan az üyesi ve cross-functional olan Developer'lar olmak çok önemli bir başarı faktörüdür.
- Takım mutlaka Forming – Storming – Norming ve Performing aşamalarından geçecektir. O yüzden zamanla her şeyin iyileşeceği unutulmamalıdır.
- Self-organization: takımın kendini ve işini yönetebilmesi için organizasyonun mutlaka takımı yetkilendirmesi gerekir. Otonomi sahibi olmayan takımlar hızlıca demotive olurlar. Yöneticilerin ve diğer paydaşların, takımın işleyişine karışması mutlaka engellenmelidir ve Scrum Master böyle bir sorunun çözümü için yönetim ve organizasyon düzeyinde çalışmalıdır.
- Scrum Framework’ünün bir “bare-minimum” olduğu ve Transparency – Inspection – Adaptation ile (Empricism) çalıştığı akıldan çıkarılmamalıdır. Scrum Framework’ün hiç bir komponentin çıkarılamayacağı ama ilkelere ve felsefesine uygun eklemelerin yapılabileceği unutulmamalıdır. Tüm Scrum Event’lerinin birer Inspection – Adaptation fırsatı olduğu hatırlanmalı ve zaten bu yüzden işe yaradığı, çalıştığı, değer yarattığı hatırlanmalıdır. “Scrum But” yoktur, “Scrum And” vardır.
- Takımın her Sprint’inin bir maliyeti olduğuna göre, Sprint sonunda bu maliyetten daha fazla değer yaratıp yaratmayacağı sürekli sorgulanmalıdır. Bu, Product Owner’a Developer'ların ortak zekasını kullanma ve yüksek yaratıcılığı tetikleyebilme fırsatı verir. Bu sayede hem Sprint Planning event’inin değerini birlikte maksimize etme imkanı elde edilir hem de önemli varsayımlar varsa bunların en çabuk ve en ucuz şekilde nasıl test edilebileceğine dair ortak bir çalışma olanağı sağlanır. Bu sayede Product Backlog Refinement aktivitelerinin gerçekten büyük anlam taşıması da sağlanır. Takımın performansı, ürettikleri değere bağlı olduğuna göre tüm Scrum Takımı bu değeri maksimize etmeye odaklı çalışacaktır.
- Sprint Review çok önemli ve yüksek değerli bir event’tir. Burada paydaşlara, müşterilere, kullanıcılara gerçekten bitmiş, teslim edilmeye hazır çalışan çözüm parçaları göstermek, bu takımın varlığının ana sebebidir. Sprint Review, aynı zamanda tüm Scrum Takımı’nın varsayımlarının da doğrulamaya tabi tutulduğu etkinliktir. Bu etkinlikte gelecek tüm geri-bildirimler, Scrum takımı için yüksek değerdedir ve gerek Product Backlog’u gerekse bir sonraki Sprint Planning aktivitesini etkileyebilir. Temel olarak Çeviklik, bu geri bildirim ve bu geri bildirime adapte olmak demektir. Ürün bazında Çeviklik, burada ortaya çıkmaktadır.
- Sprint’lerin amacı her Sprint sonunda değer yaratmaktır. Bitmemiş işler değer yaratmaz. O yüzden Scrum Takımlarının amacı Sprint sonunda Sprint Hedefini gerçekleştirecek şekilde işleri bitirmektir. Scrum Takımının ne kadar fazla sayıda işe başlamış olduğunun bir anlamı ve değeri yoktur, değer işleri bitirmekle oluşur. O yüzden Sprint içerisinde Developer’ların “Work In Progress Limiti” kullanması da iyi olabilir.
- Dünü, bugünü ve geleceği şeffaf bir şekilde görebilmek, bir Scrum takımının erişebileceği çok değerli seviyelerden biridir. Bunu yapabilmenin yolu da Increment’in (çalışır durumdaki çözümün son hali), Sprint Backlog’un (Sprint planı, yapılacak küçük parçalara bölünmüş işler ve Sprint Goal) ve tabii ki Product Backlog Refinement aktivitesi ile Product Backlog’un şeffaf hale getirilmesidir.
- Bir Scrum Takımı, haftalık Sprint’ler bile koşuyor olsa, süper doğru bir planlama yapamayabilir. Scrum Framework’ü kullanıyor olmamızın sebebi, complex bir ortamda çalışıyor olmamızdır. Dolayısıyla bilinmeyenlerin bilinenlerden daha çok olduğu bir ortamda süper doğru planlama yoktur; aksine sürekli planlama vardır. Developer, Sprint Goal’e ulaşmak konusunda ne durumda olduğunu her Daily Scrum etkinliğinde gözden geçirmeli ve bu amaca ulaşma yolunda sapma varsa yeniden planlama ile planını düzeltmelidir. Daily Scrum’ın varlığının sebebi budur.
- Daily Scrum 15 dakikayı geçiyorsa, takım Daily Scrum’ı yanlış yapıyordur. Başka açıklama aramaya gerek yoktur. Varlık amacı ve nasıl yapılacağı Scrum Guide’da açık şekilde anlatılmıştır.
- Sprint’te bitmeyen hiç bir iş, otomatik olarak sonraki Sprint Planlama’ya dahil edilmez! Bir Sprint süresi geçtikten sonra bitmemiş işlerin halen değerli olup olmadığı, Product Owner tarafından daima sorgulanmak zorundadır. Değişimin bunca yüksek olduğu bir ortamda bir Sprint süresinde bile ürüne eklenmeye çalışılan fonksiyonaliteler değersiz hale gelmiş olabilir. Değeri maksimize etme amacı olan bir Product Owner bitmemiş işleri sonraki Sprint’e otomatik olarak almaz. Dolayısıyla işlerin bitmesi ve değer yaratması temel amacımızdır.
- Sprint’e alınan işlerin bitmediği, sonraki Sprint’lere otomatik olarak yayıldığı, Sprint sonunda bitmiş çalışan çözüm parçası çıkaramamış ve kendini iyileştirerek her Sprint’te bitmiş iş parçaları üreterek değer yaratma motivasyonu olmayan bir Scrum takımı, “Zombie Scrum” enfeksiyonu kapmıştır! Scrum’da Sprint’e “Scrum’ın kalbi” denirken, Sprint içerisinde veya sonunda üretilmiş, bitmiş, kullanıcıya veya müşteriye verilmeye hazır durumda çözüm parçası da Scrum’ın “kalp atışıdır”. Sprint sonunda Increment ortaya çıkmıyor ve bunu iyileştirme konusunda da hiç bir motivasyon yoksa, Scrum şeklen vardır ama yaşamıyordur. Bu yüzden “Zombie Scrum” adını alır. Zombie Scrum’ın ilacı, takımın hızlıca Agile Manifesto, değerler, prensipler ve Scrum Değerlerine geri dönüşüdür. Scrum değerlerini yaşayan ve yaşatan bir takım, Zombie Scrum’a kapılmaz.
Yorumlar