Scaling Agile Nereye Gidiyor?
Son bir kaç aydır özellikle SAFe’in yeni versiyonunun yayınlanması ile birlikte Scaling* yöntemleri tekrar gündeme geldi. Uzun süredir düşündüğüm ancak biraz toz kaplamış sorular bu gelişmeyle birlikte açığa çıktı.
İlgili Eğitimlerimize Hemen Göz Atın
Scaling gerçekten gerekli mi?
Scaling yöntemleri olmasa bu yöntemlerin çözmeye çalıştığı problemleri nasıl çözerdik?
Scaling yöntemleri, Agile’ın DNA’sında olan Küçük, Otonom ve Kendi Kendini Yöneten yapılar kavramına ters mi?
Bu soruların cevaplarını bulmaya çalışmadan önce, Scaling yöntemlerinin ortaya çıkışını kısaca bir hatırlayalım…
2000’li yılların başında köklerini salan Agile kavramı, 2010’lu yıllara geldiğimizde artık kendisine belirli bir yer edinmişti. Birkaç takımın bir arada çalıştığı projelerde ve ürün geliştirme çalışmalarında karşılaştığımız problemleri çözebiliyordu. Müşterinin ihtiyacı olan değeri yinelemeli ve artırımlı bir şekilde ortaya koymaya yardımcı oluyordu.
Ancak yıkıcı değişim ve teknolojideki hızlı gelişmeler yaptığımız işin karmaşıklığını da giderek artırdı. Dolayısı ile çok daha fazla insanın bir araya gelip, daha büyük hedeflere doğru koşması gerekliliği ve bunu Agile yöntemlerle yapmaya çalışması yeni Agile yöntemlere ihtiyacı doğurdu. Tam olarak bu dönemlerde ortaya çıkan SAFe, Spotify Model vb. yaklaşımlar bu ihtiyacı karşılamaya çalıştılar.
Bu yöntemlerin temelde çözmeye çalıştığı problemleri sıralamak gerekirse şunları söyleyebilirim:
Fazla sayıda takımın ve profesyonelin bir arada çalışma ihtiyacı
Ortak hedef ve bakış açısının şeffaflığının sağlanması
Çok sayıda profesyonelin bulunduğu gruplarda oluşan hizalanma ve senkronizasyon ihtiyaçları
Büyük sistemlerin geliştirilmesi sırasında ortaya çıkan bağımlılıklar ve bunların yönetimi
Evet, bu yöntemler yukarıda paylaştığımız problemleri çözüyorlar. Hatta çok iyi pratiklerle bunu sağlıyorlar. 2 örnek ile açıklamak gerekirse:
SAFe’te bulunan, ART (Agile Release Train)** yapısı, ART Backlog’u ve PI (Planning Interval) Planning süreci ile yukarıda bahsettiğimiz tüm problemlere bir çözüm üretiyor.
Spotify Modeli’nde bulunan, Tribe**, bu yapıyı oluşturan Squad yapıları ve Tribe’ların gerçekleştirdiği Quarterly Business Review (QBR) vb. aktiviteleri ile birlikte yukarıdaki problemlere net çözümler üretiyor.
Scaling yöntemlerinin ana yaklaşımı, ortaya koydukları çözümlerin tamamına yakınını top-down bakış açısı ile ortaya koymalarıdır. Örneğin SAFe’teki Backlog yapılarına baktığımızda bunu net olarak görebiliriz. Backlog maddeleri hiyerarşik olarak Epic - Feature - Story şeklinde yukarıdan aşağıya doğru inmektedir. Benzer şekilde Spotify Modeli’nde (uygulamasına göre değişkenlik gösterebilir, ancak büyük danışmanlık şirketlerinin modellediği yapıda bu şekilde uygulanmaktadır.) Tribe Leader - Product Owner ilişkisi yukarıdan aşağı olarak tariflenmektedir.
Bana göre problem de tam olarak bu noktada başlıyor. Bu şekilde baktığımızda klasik hiyerarşinin getirdiği piramit yaklaşımını terse çeviremiyorsunuz. Ama aslında yapmak istediğimiz bu piramidi alaşağı etmek. Yani bu resme yukarıdan aşağı değil de, aşağıdan yukarı (bottom up) bakmamız gerekiyor. Peki bunu nasıl başarabiliriz? Kendi kendini yöneten, daha otonom ve daha küçük yapılar nasıl mümkün olabilir?
Burada cevap olarak karşımıza Frederick Laloux’nun Reinventing Organizations bakış açısından ortaya çıkan Progressive Organizasyonlar veya bir başka deyişle Fluid Organizations karşımıza çıkıyor. Fluid Organizations’ı özünde
ART, Tribe vb. sabit Agile yapıları olmayan,
Scrum, Kanban vb. tabanlı bir yaklaşıma ihtiyaç duymayan
Kendi kendini yönetme, işbirliği, ortak amaç ve otonomi değerleri etrafında bir araya gelmiş gruplardan oluşan
organizasyonlar olarak tarifleyebiliriz.
Baştaki sorularımıza dönecek olursak Fluid Organizasyonlar sayesinde Scaling yöntemlerine ihtiyaç duymadığımız, problemleri güven temelinde ele aldığımız ve Agile’ın DNA’sını yaşatabildiğimiz ortamlar mümkün. Sabit takımlarınızın olmadığı, ama takım bazlı çalışarak değer ürettiğiniz bir organizasyon hayal edin. Böyle bir yapı nasıl mümkün olur, bunu da bir sonraki yazımızda değerlendirelim. Görüşmek üzere.
*Scaling (Yaygınlaştırma): Agile’ın çoklu takımlarla birlikte kullanılmasına imkan veren metodlara verilen ortak isim
** ART ve Tribe, SAFe ve Spotify Modeli’ndeki takımlar takımı/grubu olarak adlandırılan yapılardır.
Yorumlar