Büyük Ölçekli Projelerde Agile Uygulama Yöntemleri: Yaramıza Merhem Olur Mu?
Agile, her ne kadar iş yapış şekli itibariyle çok erken örnekleri olsa da ete kemiğe büründüğü 2001 yılından itibaren, özünde varolan iterasyon, hızlı test, küçük denemeler, odak, önceliklendirme, müşteri entegrasyonu gibi yönleriyle ve ortaya çıkardığı kendisini güçlendiren yeni yaklaşımlarla hala bilgisayar bilimlerinden, pazarlamaya hatta kurumsal yönetime kadar birçok alanda en popüler iş yapış metodu.
Her gün başka bir uygulaması çıkarken, Scrum Master yerine Scrum Monster, Agile is Dead phraseleri kullanan çok sayıda bilgisayar bilimci yeni yöntem arayışlarıyla ortaya çıkıyor. Burada tabi yöntemlerden ziyade prensiplere odaklanmak gerektiğini savunan, benim de kendime daha yakın bulduğum yaklaşımlar var. Agile için yaşanan ve 2018'den itibaren yoğunlaşan bu tartışmaların kökeninde öncelikle şu sorun var “Agile bu kadar iyiyken, neden bizim projelerimiz yada sonucunda çıkan uygulamalarımız harika değil?” yani kısaca neden uygulamada bu kadar zorluk yaşıyoruz.
Bu problemin kökeninde ve yeni geliştirilen yöntemlerin özünde de büyük ölçekli firmalarda, büyük ölçekli projelerde metodolojiye bağlı geliştirme yapmaya çalışmanın yarattığı sorun yatıyor. Biraz önce bahsettiğim gibi ben burada ilkeleri öne çıkarmayı, ve DevOxx Belçika’da Lemi Orhan Ergin’in de bir örneğini anlattığı “Agile değil Agility” kavramını öne çıkararak bir takım, kurum geliştirme kültürü yaratmayı önemsiyorum.
Fakat bunun yanında özellikle büyük ölçekli projelerde yaşanan problemler için öne çıkan metodolojiler de var bir kısmı özellikle oldukça keyifli, başarılı uygulama pratiklerine, case study olacak sonuçlara ve sektörde yaygınlık kazanmaya başlayan uygulama pratiklerine sahipler. Bu yazıda aslında sektör olarak savunma alanında da kendisine yer bulan ve özellikle bir kısmı geliştirilirken (Jeff Sutherland Scrum@Scale için savunma sanayini de odağına aldığını belirtiyor) savunma gibi sektörlere de özellikle odaklanan bu metodolojilere, yöntemlere bir bakış atmak istiyorum.
Başlangıçta küçük, çevik ekipler için tasarlanmış olan agile metodolojiler, büyük ölçekli projelerin benzersiz zorluklarını ele almak için bir değişim geçirme, uyarlama ihtiyacı hissettiler bu metodlar geliştirilirken. Birden fazla, birbirine bağlı ekibi yönetmenin karmaşıklığı, çeşitli gruplar arasında tutarlı süreçlere duyulan ihtiyaç ve daha büyük kapsamlarla ilişkili artan riskler, belirli Çevik uygulamaların geliştirilmesini gerektirdi diyebiliriz. SAFe, LeSS ve Scrum@Scale gibi bu çerçeveler, yapılandırılmış koordinasyon, standartlaştırılmış uygulamalar ve etkili entegrasyon stratejileri sunarak büyük projelerin karmaşık dinamiklerine hitap etmeyi amaçlıyor.
Hepsinin temelinde aslında çevikliğin temel ilkelerinin -uyarlanabilirlik, müşteri odaklılık ve yinelemeli geliştirme- ölçek büyütme sırasında kaybolmamasını sağlamak yatıyor. Bu metodolojiler ayrıca kaynak optimizasyonu, uyumluluk ve risk yönetimi gibi önemli hususları da ele alarak büyük ölçekli projelerin iş hedefleriyle uyumlu ve paydaş geri bildirimlerine duyarlı kalmasını sağlar ve böylece geleneksel Çevik yaklaşımlar ile daha büyük, daha karmaşık proje ortamlarının talepleri arasındaki boşluğu doldurmayı amaçlıyor.
Bu yöntemlerin başlıcalarına hızlıca bakarak olursak:
1. Scrum of Scrums
Scrum of Scrums, aynı proje üzerinde çalışan birden fazla ekibi koordine ederek Scrum’ı tek bir ekibin ötesine ölçeklendiren bir yaklaşımdır. Bu çerçeve, her ekipten temsilcilerin ilerlemeyi, zorlukları ve ekipler arası bağımlılıkları tartışmak üzere Scrum of Scrums oturumunda düzenli olarak bir araya gelmesini içerir. Her ekip kendi günlük stand-up toplantısını yapar ve ardından her ekipten bir temsilci ilerlemeyi, engelleri ve koordinasyonu tartışmak için “Scrum of Scrums” toplantısına katılır .Burada aslında birden çok scrum takımını bir araya toplayan daha büyük bir çerçeve öngörebiliriz, bu tüm scrum aktivitelerinin temsilciler tarafından daha yukarıda bir daha ele alınmasını içerir.
- Ekipler Arası Koordinasyon: Birden fazla Scrum ekibi arasında iletişimi ve sorun çözmeyi kolaylaştırır.
- Düzenli Entegrasyon Toplantıları: Uyumu sağlar ve ekipler arası engelleri ele alır.
- Ölçeklenebilirlik: Scrum çerçevesini daha büyük, çok ekipli projelere genişletir.
2. Scaled Agile Framework (SAFe)
Ölçeklendirilmiş Çevik Çerçeve (SAFe), büyük kuruluşlarda kullanılmak üzere Çevik uygulamaların ölçeklendirilmesine yönelik oldukça yapılandırılmış bir yaklaşımdır. Bir yazar ve yazılım geliştirme metodoloğu olan Dean Leffingwell tarafından geliştirilmiş ve ilk olarak 2011 yılında “Agile Software Requirements” adlı kitabında tanıtılmıştır. O zamandan bu yana SAFe, her biri kullanıcı geri bildirimlerine ve Agile topluluğunun gelişen ihtiyaçlarına dayalı olarak yeni unsurlar ve iyileştirmeler ekleyerek yeni sürümlerle gelişmeye devam etmektedir.
SAFe Nasıl Çalışır?
Çok Düzeyli Yapı: SAFe, her biri organizasyonun farklı yönlerine hitap eden çoklu seviyelerde çalışır:
- Ekip Seviyesi: Burası temel Çevik ve Scrum uygulamalarının hayata geçirildiği yerdir. Ekipler kısa iterasyonlar halinde çalışır ve ürünün yüksek kaliteli artışlarını sunmaya odaklanır.
- Program Seviyesi: Burada birden fazla ekip, ekiplerden oluşan daha büyük bir ekip olan Çevik Sürüm Treni (ART) şeklinde organize edilir. ART, ekipler arasında uyum ve entegrasyonu sağlamak için daha büyük program artışlarında (tipik olarak 8–12 hafta) birlikte planlar, taahhüt eder ve yürütür.
- Portföy Seviyesi: Bu seviyede SAFe, Çevik geliştirmeyi iş stratejisi ile uyumlu hale getirir. Çalışmanın işletmenin stratejik temaları ve hedefleriyle uyumlu olmasını sağlayarak bir değer akışı portföyünün tanımlanmasını, yatırım yapılmasını ve yönetilmesini içerir.
- Roller ve Sorumluluklar: SAFe, ART için baş Scrum Master olarak görev yapan Release Train Engineer (RTE) ve geliştirmenin müşteri ihtiyaçları ve kurumsal hedeflerle uyumlu olmasını sağlayan Ürün ve Çözüm Yöneticileri gibi Agile’ı ölçeklendirmeye yardımcı olan belirli roller sunar.
Etkinlikler ve Seramoniler: SAFe, tüm ekipleri ART üzerinde hizalayan büyük ölçekli bir planlama toplantısı olan PI Planlama gibi benzersiz etkinlikler içerir. Ayrıca, farklı ekiplerden gelen artışların uyumlu olmasını ve kalite standartlarını karşılamasını sağlamak için tutarlı entegrasyon ve demoları da içerir.
SAFe’in büyük ölçekli projeleri yönetmeye yönelik yapılandırılmış yaklaşımı, çeşitli sektörlerde yaygın olarak benimsenmesine yol açmıştır, çok yoğun kullanılan ölçekli agile yöntemlerinden biridir. Birden fazla Çevik ekip arasında daha koordineli bir çabayı kolaylaştırarak kuruluşun tüm bölümlerinin ortak bir vizyonla aynı yönde ilerlemesini sağlar.
3. LeSS (Large-Scale Scrum)
Büyük Ölçekli Scrum (LeSS), Scrum’ı daha büyük kuruluşlara ve birden fazla ekibe ölçeklendirmek için özel olarak tasarlanmış bir Çevik çerçevedir. Craig Larman ve Bas Vodde tarafından geliştirilen LeSS, Scrum’ın temel ilkelerini tek ekipli projelerin ötesine taşıyarak daha büyük ölçekli ortamlarda basitliği ve etkinliği korur. Ölçeklendirme için karmaşıklık katmanları ekleyen çerçevelerin aksine LeSS, organizasyonel karmaşıklığı en aza indirmeye ve değer sunumunu en üst düzeye çıkarmaya odaklanır diyebiliriz.
LeSS’in Temel Farklılıkları:
- Basitlik ve Minimalizm: LeSS, geleneksel Scrum’a kıyasla asgari düzeyde ek rol ve artifaktları savunarak sadeliğiyle öne çıkar.
- Tek Ürün Birikimi (Backlog) ve Ürün Sahibi: Farklı ekipler için birden fazla birikim ve ürün sahibi ortaya çıkarabilen diğer çerçevelerin aksine LeSS, ekip sayısından bağımsız olarak tek bir ürün birikimi ve tek bir Ürün Sahibi sağlar.
- Odak Süreç Kontrolüne Odaklanma: LeSS, Scrum çerçevesinin temel unsurları olan şeffaflık, denetim ve uyarlamayı güçlü bir şekilde vurgular.
LeSS’in Çalışma Prensipleri ve Uygulanması
LeSS uygulaması, bir kuruluşun ortak bir ürün birikimi üzerinde çalışan birden fazla özellik ekibi halinde yapılandırılmasını içerir. LeSS’teki her ekip standart bir Scrum ekibine benzer şekilde çalışır, ancak uyumlu bir ürün geliştirme çabası sağlamak için diğer ekiplerle koordineli olması şarttır.
LeSS Nasıl Çalışır?
- Özellik Ekipleri: Ekipler çapraz işlevlidir ve ortak ürün birikiminin kendi bölümlerini yönetmekten sorumludur.
- Koordinasyon ve Entegrasyon: Scrum’ların Scrum’ına benzeyen düzenli koordinasyon toplantıları, ekiplerin çalışmalarını hizalamalarına ve bağımlılıkları çözmelerine yardımcı olur.
- Genel Retrospektifler ve İncelemeler: Bu etkinlikler tüm ekipleri kapsar ve genel süreci ve ürünü iyileştirmeye odaklanır.
LeSS’in En Önemli Yönleri:
- Öğrenme ve Adaptasyona Odaklanma: Sürekli öğrenme ve geri bildirime dayalı uyarlama LeSS’in merkezinde yer alır.
- Organizasyonel Yeniden Tasarım: LeSS genellikle karmaşıklığı azaltmak ve Çevik ilkelerle uyum sağlamak için organizasyon yapısında değişiklikler gerektirebilir. Örneğin, konfigürasyon yada DevOps fonksiyonlarını geliştiren ekip de ortak ürün birikimi kullanırken, ekibin içerisine daha dahil olmasını gerektirecek bir düzenleme gerekebilir.
- Şeffaflık ve İletişim: Ekipler arasında etkili iletişim ve şeffaf iş süreçleri LeSS’de kritik öneme sahiptir.
4. Spotify Model:
Spotify Modeli, Çevik geliştirme için ekipleri organize etmeye yönelik yenilikçi bir yaklaşımdır ve özellikle özerklik, esneklik ve iletişime verdiği önemle dikkat çekmektedir. Scrum veya SAFe gibi resmileştirilmiş bir Çevik çerçeve olmasa da, Çevik toplulukta etkili olan ekip yapısı ve yönetimi konusunda benzersiz bir bakış açısı sunar. Müzik yayın şirketi Spotify tarafından geliştirilen bu model, hızla büyüyen bir şirkette Çevik uygulamaları ölçeklendirmenin zorluklarına verdikleri yanıttı. Özerk çalışma ile şirketin genel hedefleriyle uyum arasında bir denge sağlamak üzere tasarlanmıştır.
Spotify Modeli Nasıl Çalışır?
1. Takımlar (Squads)
Ekipler, Spotify Modelindeki temel birimlerdir ve geleneksel Agile’daki Scrum ekiplerine benzer. Her ekip, genellikle ürünün belirli bir özelliğine veya bileşenine odaklanan, kendi kendini organize eden, çapraz işlevli bir ekiptir.
Ekipler yüksek derecede özerkliğe sahiptir. Kendi iş akışlarına ve metodolojilerine (Scrum, Kanban, vb.) karar verirler ve tasarımdan dağıtıma kadar kendi alanlarının tüm yönlerinden sorumludurlar.
2. Kabileler (Tribes)
Kabileler, ilgili alanlarda çalışan ekiplerden oluşan koleksiyonlardır. Bir kabilenin birincil amacı, ekiplerin bilgi paylaşması ve daha büyük sorunların çözümünde işbirliği yapması için bir ağ sağlamaktır.
Kabileler birden fazla ekipten oluşsa da, etkili iletişim ve işbirliğini sürdürmek için yeterince küçük tutulurlar (Dunbar sayısı (İngiliz antropolog Dunbar’ın beyin büyüklüğü ve işbirliği içerisinde çalışabilecek grupların büyüklüğüne ilişkin çalışması) yani yaklaşık 150 kişi, genellikle referans alınır).
3. Bölümler ve Loncalar (Chapters and Guilds)
- Bölümler: Bunlar, bir takımdaki tüm arka uç geliştiricileri gibi benzer becerilere veya rollere sahip üyelerden oluşan bir takım içindeki daha küçük gruplardır. Bölümler zorlukları tartışmak, bilgi paylaşmak ve becerilerini geliştirmek için düzenli olarak toplanır. Kişisel ve kariyer gelişimine odaklanan geleneksel bir hat yöneticisinin rolüne benzerler.
- Loncalar: Loncalar, tüm kuruluşu kapsayan ilgi alanına dayalı gruplardır. Şirketteki herkes, takım veya kabile üyeliğine bakılmaksızın bir loncaya katılabilir. Bilgi, araç, kod ve uygulamaları paylaşmak için kullanılırlar.
Temel Özellikler ve İlkeler
- Özerklik: Ekipler nasıl çalışacaklarını seçme özgürlüğüne sahiptir, ancak çabaları şirketin genel hedefleriyle uyumludur.
- İletişime Odaklanma: Düzenli toplantılar ve gayri resmi ağlar, ekipler ve kabileler arasında işbirliğini ve bilgi paylaşımını teşvik eder.
- Kültür ve Öğrenme: Öğrenmeye, büyümeye ve yeniliğe odaklanan güçlü, insan merkezli bir kültürü vurgular.
Spotify Modeli, bir kuruluş büyüdükçe bile çevikliği ve hızlı inovasyonu sürdürme becerisiyle popülerlik kazanmıştır. Ekipleri özerkliği teşvik ederken ortak hedeflere yönelik uyumu sağlayacak şekilde organize ederek, Çevik uygulamaları ölçeklendirmeye yeni bir bakış açısı sunar. Bu model özellikle işbirlikçi, yenilikçi ve uyarlanabilir bir çalışma kültürünü teşvik etmek isteyen kuruluşlar için faydalı olabilir.
5. Scrum@Scale:
Scrum’ın Ken Schwaber ile birlikte yaratıcılarından biri olan Jeff Sutherland tarafından geliştirilen Scrum@Scale, aynı ürün veya ürün grubu üzerinde çalışan birden fazla Scrum ekibinin çabalarını verimli bir şekilde koordine etmek için tasarlanmıştır. Scrum’ı tek bir ekipten tüm bir organizasyona ölçeklendirerek tutarlılık ve maksimum üretkenlik sağlamayı amaçlamaktadır. Scrum@Scale’in temel özellikleri şunlardır:
- Modüler Yaklaşım: Scrum@Scale, her Scrum ekibini daha büyük bir ağdaki bir modül olarak ele alarak Scrum çerçevesini bir kuruluşun birden fazla ekibi ve alanı arasında çoğaltma fikri üzerine inşa edilmiştir.
- İki Paralel Döngü: Çerçeve, organizasyonu iki döngüye ayırır — Scrum Master Döngüsü ve Ürün Sahibi Döngüsü, her biri ölçeklendirmenin farklı yönlerini ele almak için kendi bileşen setine sahiptir.
a) Scrum Master Döngüsü: Koordinasyon, dağıtım ve süreç iyileştirme dahil olmak üzere ekiplerin birlikte nasıl çalıştığına odaklanır.
b) Ürün Sahibi Döngüsü: Ürün birikiminin önceliklendirilmesi, ürün planlaması ve sürüm yönetimi dahil olmak üzere ekiplerin ne üzerinde çalıştığıyla ilgilenir.
Önerdiği Ekstra Çerçeveler:
Scrum’ların Scrum’ı ve MetaScrum: Diğer ölçeklendirme çerçevelerine benzer şekilde Scrum@Scale, her Scrum ekibinden temsilcilerin ilerleme ve zorlukları tartışmak için bir araya geldiği bir “Scrum of Scrums” yaklaşımı içerir. MetaScrum, Ürün Sahiplerinin öncelikleri ve birikmiş işleri hizalaması için paralel bir toplantıdır.
Scrum@Scale, Çevik bir ortamın yaratılması ve sürdürülmesinde liderliğin önemini vurgular. Burada da iki ayrı akışa iki ayrı lider planlayarak bu akışların özerklikle beraber yönetilebilir kalmasını sağlamaya da odaklanmıştır. Ayrıca Scrum değerlerinin (bağlılık, cesaret, odaklanma, açıklık ve saygı) ölçeklendirme başarısı için gerekli olduğunu vurgular. Çerçeve, kuruluşun özel ihtiyaçlarına ve bağlamına uyarlanabilecek şekilde tasarlanmıştır. Kuruluşları gerektiğinde ölçeği büyütmeye veya küçültmeye ve çerçeveyi uygularken kendi yollarını belirlemeye teşvik eder.
Scrum@Scale, özellikle ortak bir hedef doğrultusunda çalışan birden fazla ekibin koordine edilmesi gereken ortamlarda etkilidir ve operasyonların ölçeği arttıkça Çevik ilkelerin kaybolmamasını sağlar. Mevcut Scrum uygulamalarına kolayca entegre edilebilecek ve gerektiğinde diğer Çevik çerçevelerle birlikte çalışabilecek şekilde tasarlanmıştır. En önemli özelliklerinden biri de bu mevcut çalışma şekillerine kolay entegre olabilirlik olarak ele alınabilir.
Büyük ölçekli projeler için uyarlanmış Çevik metodolojiler alanında, yaygın olarak tanınan Scrum of Scrums, Scrum At Scale, LeSS, SAFe ve Spotify Modelinin ötesinde birkaç kayda değer çerçeve daha vardır. Bunlar arasında Scrum.org tarafından Scrum’ı birden fazla ekip arasında ölçeklendirmenin karmaşıklığını basitleştirmek için geliştirilen Nexus; bir kuruluşun proje portföyünü stratejik hedefleriyle uyumlu hale getirmeye odaklanan Çevik Portföy Yönetimi (Agile Portfolio Management) ve çeşitli Çevik metodolojilerden unsurları birleştirerek karmaşık ortamlar için daha kapsamlı bir araç seti sunan Disiplinli Çevik Teslimat (Disciplined Agile Delivery) bulunmaktadır.
Bu çerçevelerin her biri, Agile ilkelerini büyük ölçekli proje yönetiminin zorluklarına uyarlama amacına hizmet etmekle birlikte, özel yaklaşımları ve odak alanları bakımından farklılık göstermektedir. Örneğin, Nexus ekipler arası bağımlılıkları en aza indirmeyi vurgularken, Çevik Portföy Yönetimi üst düzey stratejik uyumla ilgilenir. Bu farklılıklara rağmen, hepsi ortak bir hedefi paylaşmaktadır: büyük, çok yönlü kuruluşlarda etkili Agile uygulamasını kolaylaştırmak. Bununla birlikte, bu alanda en önde gelen ve yaygın olarak benimsenen çerçevelerin Scrum of Scrums, Scrum At Scale, Large-Scale Scrum (LeSS), Scaled Agile Framework (SAFe) ve Spotify Model olduğunu ve her birinin Agile metodolojilerini etkili bir şekilde ölçeklendirmek için farklı yapılar ve stratejiler sunduğunu belirtmek önemlidir.
Özetle, Agile metodolojileri, zaman zaman “Agile öldü” şeklindeki tartışmalara konu olsa da, özellikle büyük ölçekli projelerde karşılaşılan zorluklar için yapılan çalışmalar, geliştirilen yöntemler, sundukları çözüm yollarıyla halen büyük bir öneme sahiptir ve kendini yenilemektedir. Büyük projelerde görülen karmaşa, koordinasyon güçlükleri ve ekipler arası entegrasyon sorunları gibi zorluklar, Agile’ın ölçeklendirilmiş versiyonları olan Scrum of Scrums, SAFe, LeSS ve Spotify Modeli gibi metodolojilerin geliştirilmesine yol açmıştır. Bu metodolojiler, Agile prensiplerinin temel değerlerine odaklanarak tasarlanırken özellikle karmaşıklığı yönetmeyi, süreçleri iyileştirmeyi ve hızlı adaptasyonu hedeflemektedir.
Büyük ölçekli projeler, özellikle savunma sanayi gibi kritik alanlarda, Agile metodolojilerini uygulamanın faydaları açıktır. Bu yaklaşımlar, projelerin daha hızlı ve etkili bir şekilde ilerlemesini, risklerin daha iyi yönetilmesini ve değişen gereksinimlere hızla uyum sağlanmasını sağlar. Ayrıca, Agile metodolojiler, ekiplerin daha yenilikçi ve yaratıcı çözümler üretmesine, müşteri geri bildirimlerine daha hızlı yanıt vermesine ve sonuç olarak daha yüksek kaliteli ürünler ve hizmetler sunmasına olanak tanır. Ancak, bu metodolojilerin etkin bir şekilde uygulanabilmesi için, süreçler ve araçlar kadar, Agile değerlerinin de — işbirliği, müşteri odaklılık, esneklik, sürekli iyileştirme ve şeffaflık — ön planda tutulması gerekmektedir. Bu değerler, projelerin değişen gereksinimlere hızlı bir şekilde uyum sağlamasına, ekipler arası iletişimin etkinliğini artırmasına ve yüksek kaliteli sonuçlar üretmesine olanak tanır. Özellikle büyük ölçekli projelerde, metodolojinin başarısı, bu temel değerlere ne kadar bağlı kalındığına bağlıdır. Metodolojiler, rehber ve araçlar sağlasa da, asıl başarı bu değerleri projenin ve organizasyonun temeline entegre etmekten geçer.
Bu bağlamda, büyük ölçekli projelerde Agile metodolojilerini uygularken, süreç ve araçlara odaklanmaktan ziyade, bu temel değerlere sadık kalmak ve onları her projenin özgün ihtiyaçlarına göre uyarlamak hayati önem taşır. Yöntem seçimi, projenin özel gereksinimleri, ekip yapısı ve organizasyonun kültürüne göre yapılmalıdır. En önemlisi, her yöntemin Agile prensiplerini nasıl desteklediğini anlamak ve bu değerleri organizasyonun her seviyesinde hayata geçirmektir.
Fakat özellikle son olarak şunu vurgulayabiliriz, özellikle büyük ölçekli projeler söz konusu olduğunda, Agile metodolojilerinin etkinliği, farklı sektörlerden gelen çarpıcı örneklerle kanıtlanmıştır. Spotify ve Ericsson gibi teknoloji devleri, bunların yanı sıra Sutherland’ın belirttiği gibi savunma sanayisindeki önde gelen şirketler, Agile yaklaşımlarını başarıyla uygulayarak, büyük ölçekli projelerdeki karmaşıklıkları aşmada ne kadar etkili olduklarını göstermişlerdir. Bu örnekler, uygun Agile metodolojisini seçmenin ve bu metodolojileri, Agile’ın temel değerlerini öne çıkaracak şekilde uyarlamanın, büyük ölçekli projelerin başarısında kritik önem taşıdığını vurgulamaktadır.
References:
