Büyük Ekipler Çevik Yöntemleri Uygulayabilir mi?

Daha önce çevik yöntemlere dönüşümle ilgili yazılar kaleme almıştık (İlgili Makaleler: Çevik Yöntemlere Yolculuk, Çevik Yöntemlere Dönüşüm). Çevik yöntemlere dönüşümde hemen herkesin aklına küçük ekiplerin bir arada çalıştığı üretken ortamlar geliyor. Dahası çevik yöntemlerin küçük firmalar ve aynı yerde çalışan ekipler için uygun olduğu düşünülüyor. Peki, büyük ekipler, farklı yerlerde çalışan takımlar ve kurumsal şirketler çevik yöntemlere geçebilir mi? Örneğin 500 çalışanı olan bir ar-ge bölümü, çevik yöntemlerle çalışabilir mi? Ya da dünya çapında 5 farklı ülkede ofisi olan bir firmada çevik yaklaşımlar uygulanabilir mi?

Ekipteki kişi sayısı arttıkça, takımlar farklı yerlerde (farklı ülke, şehir veya ofis) çalıştıkça, kurumsallık yükseldikçe çevik yöntemleri oldukları gibi uygulamak giderek zorlaşıyor. Ya kurumdaki rolleri ve süreçleri eğip bükerek çevikleştirme yoluna gidiliyor, ya da çevik yöntemleri eğip bükerek kurumlara özgü “çevik ama ...” yöntemler türetiliyor. Hangisi yapılırsa yapılsın, bir şeyler yerli yerine oturmuyor ve bir süre sonra eski alışkanlıklara dönüş eğilimi başlıyor. Bütün bunları aşarak gerçekten uygulamayı başarabilen kurumlarda ise arka planda çevik şövalyeleri diyebileceğimiz insanların olağanüstü gayretleri oluyor. Bu insanların motivasyonlarını yitirmeleri veya kurumdan ayrılmaları durumunda geçmişe dönüş hemen başlıyor.

Büyük ekiplerin çevik yöntemlerle çalışmasındaki zorluklar dünyada epeyce kafa yorulan bir alan. Buna yanıtlardan birisi son birkaç yıldır duyulan LeSS (Large Scale Scrum). Craig  Larman ve Bas Vodde’nin öncülüğü yaptığı bu yöntem Scrum’ın temel felsefesine bağlı kalarak, büyük ve çok büyük ekipler için iki farklı çatı öneriyor.  İlk çatıda 10’a kadar Scrum takımının aynı ürün üzerinde çalışabileceği bir sistematik öneriliyor. İkinci çatıda daha kalabalık ekiplerin örneğin birkaç bin kişinin çalışabileceği bir yapı sunuluyor. Her iki çatıda da tek bir Ürün Sahibi (Product Owner), tek Ürün İş Listesi (Product Backlog) ve sabit süreli Sprintler yer alıyor. Scrum’in temel prensipleri korunmak kaydıyla birinci çatının bildiğimiz Scrum’dan farklı olduğu noktalar:

•  Sprint planlamanın iki aşamalı olması: İlkine her takımdan ikişer kişinin katılıyor ve ürün sahibi ile birlikte hangi takımın hangi işi seçeceği konuşuluyor. Burada kritik nokta takımların farklı yazılım katmanlarında uzmanlaşmış olmak yerine uçtan uca geliştirme yapabilecek şekilde oluşturulmuş olması bekleniyor. Bu sayede bütün takımlar gözle görülür çıktılar üreterek demo yapabiliyorlar. İkincisini ise takımlar kendi içlerinde yapıyorlar, farklı takımlardan kişiler diğer takımlardaki planlamayı izlemek isterlerse kapılar sonuna kadar açılıyor.
•  Günlük Toplantılar, Scrum’la aynı olmakla birlikte takımlar birbirlerinin toplantılarını izleyebiliyorlar.
• Takımlar-arası Koordinasyon Toplantıları: haftada en az bir kez, SoS (Scrum of Scrums) ya da benzeri bir toplantı ile takımların birbirlerindeki gelişmelerden haberdar olması sağlanıyor.
• İş Listesi Sadeleştirme (Product Backlog Refinement) toplantıları da iki aşamalı yani takımlararası ve takım içi olarak yapılıyor.
• Sprint Gözden Geçirme (Sprint Review) ise tüm takımların katıldığı ve daha çok bir teknoloji fuarı havasında geçen, tüm takımların kendi demolarını yapabileceği bir ortamda gerçekleştiriliyor.
• Retrospektifler (İlgili Makale: Çevik Yöntemlerde Retrospektif) de yine iki aşamalı olarak yapılıyor.

İkinci çatıda ise bir ürün sahibinin tüm takımlara yetişemeyeceği ve ofislerin farklı yerlerde olabileceği varsayımıyla Yerel Ürün Sahipleri (Local Product Owner) görev yapıyor. Ürün İş Listesi tek olduğu için takımların çalışmaları tek yerden takip edilebiliyor. Toplantı ve iş akışları ise yukarıdaki yaklaşıma uygun gerçekleşiyor.

Büyük ölçekli ekiplerin uyumlu çalışmasındaki temel konu koordinasyonun sağlıklı yapılabilmesi. Bu amaçla LeSS içinde alttaki yaklaşımlar öneriliyor:

• Devamlı ve kesintisiz entegrasyon
• Takımların tamamına açık kodlar ve standart kodlama yaklaşımı
• Uçtan uca geliştirme yapabilen dikey takımların kurulması
• Pratik Toplulukları (Communities of Practice) ile takımlar arası mimari, standartlar, kullanıcı deneyimi gibi konuların yönetimi
• Takımların yönettiği yazılım derleme sistemi
• Ve tabi ki daha fazla iletişim ve konuşma :)

Biz birinci çatıyı 4 takımla İzmir ve Ankara'da kullanıyoruz. Tek Ürün İş Listesi ve tek Ürün Sahibi'nin bu 4 takımı beslediği bir yapı kurduk. Haftalık SoS de yaparak iletişimi artırmaya gayret ediyoruz. Sprint sonu gözden geçirmelerini her takımın sunum ve demo yaptığı çalıştaylar olarak bir araya gelerek yapıyoruz. Kodlama standartları ve uçtan uca geliştirme yapabilen dikey takımların oldukça yararlı olduğunu gözlüyoruz. 10 ayımızı tamamladık. Özellikle büyük ekipler ve farklı şehirlerde yer alan takımlar için yararlı olabileceğini düşünüyoruz.

Kaynakça:

1. less.works
2. Larman C., Vodde B., 2013 Scaling Agile Development, CrossTalk.
3. Larman C., Vodde B., 2010 Practices for Scaling Lean & Agile Development, Addison-Wesley.