SAFe Vaka Çalışmaları: Sahadan Dönüşüm Notları

Yayınlanan: 2022-08-23

Bu makale, proje yöneticilerine ekip genişletme çabalarında rehberlik etmek için tasarlanmış, Toptal'ın Çevik ölçeklendirme serisinin üçüncü bölümüdür. Birinci bölümü okuduğunuzdan emin olun, “5 Çevik Ölçekleme Çerçevesi Karşılaştırıldı: Hangisini Kullanmalısınız?” ve ikinci bölüm, “Agile Scaling: Scrum Masters için SAFe En İyi Uygulamaları”.

15. Yıllık Çeviklik Durumu Raporuna göre çeviklik, şirketlerin %94'ü tarafından bir şekilde uygulanmaktadır. Ancak araştırmalar, kuruluşların %90'ının kurumsal çapta Çevik uygulama ile mücadele ettiğini de gösteriyor. Tipik olarak, bu çabaları yönlendirmek ve organize etmek Çevik koçların, Scrum ustalarının ve diğer proje yönetimi profesyonellerinin işidir. Genellikle, anlaşılması zor bir şirket kültüründe, değişime dirençli ekipler veya departmanlarla çalışıyorlar.

Bu yuvarlak masa toplantısında, üç Toptal proje yöneticisi, Çevik dönüşümlere öncülük etmenin zorluklarını tartışıyor. Çözümleri Scaled Agile Framework (SAFe) ile uyumlu olduğundan, SAFe'nin yaratıcısı Dean Leffingwell ile de konuştuk. Kolektif içgörüleri, SAFe uygulayıcılarının çevikliğin ne olduğuna dair net bir vizyon ve inatçı ekipleri bir araya getirebilecek bir liderlik planı hazırlama ihtiyacını göstermektedir.

Çerçevenin Oluşturucusu ile SAFe Konuşmak

Scaled Agile tarafından resmileştirilen bir çerçeve olan SAFe, yalnızca 2014 yılına kadar uzanır. Ancak Leffingwell için çalışma, 2000'lerin başında Agile ekipleriyle ilk karşılaştığında başladı. Bir yazılım geliştirme metodolojisi uzmanı olarak, geliştirme ekiplerinde Çevik uygulamaların sonuçlarından etkilendi ve hemen zihniyetin tüm şirkette nasıl uygulanabileceğini keşfetmeye başladı. Çevik bir ekip sonuç üretebiliyorsa, uyumlu Çevik ekiplerden oluşan bir ekip ne üretebilir? Çevik uygulamalar, ulusal veya uluslararası şirketlerde tam ölçekli dönüşüm projelerinde nasıl kullanılabilir? Leffingwell'in dediği gibi, “Yazılım geliştirmeyi seviyorum. Agile'ı seviyorum. Sadece büyük istiyorum."

"En Popüler Ölçeklendirme Çerçeveleri" başlıklı bir çubuk grafik. "Scaled Agile Framework (SAFe)," "Scrum@Scale/Scrum of Scrums", "Enterprise Scrum", "Spotify Model", "Agile Portfolio Management (APM)," "Disiplinli Çevik (DA) etiketli 10 çubuk vardır. ," "Büyük Ölçekli Scrum (LeSS)," "Nexus", "Yalın Yönetim" ve "Kurumlarda Çevik Yönetim (RAGE) için Tarifler". Her çubuk aynı zamanda bu çerçeveyi kullanan kuruluşların oranını temsil eden yüzdelerle etiketlenmiştir: sırasıyla %37, %9, %6, %5, %3, %3, %3, %3, %2 ve %1. Grafiğin altındaki bir satırda "Kaynak: 15. Yıllık Çevik Durum Raporu" yazıyor.
SAFe, 15. Yıllık Çevik Durum Raporunda yanıt verenlerin %37'si tarafından tercih edilen en yaygın kullanılan ölçeklendirilmiş çerçevedir.

O zamandan beri şirketler, daha kısa teslimatlar, daha yüksek ürün kalitesi, daha fazla verimlilik ve daha bağlı çalışanlar dahil olmak üzere SAFe'nin faydalarını fark ettiler. 2021 itibariyle, dünya çapındaki kuruluşların üçte birinden fazlası SAFe'yi kullandı ve en önemli yönlerinden biri, sağladığı ortak süreçler ve birleşik dildir. Örneğin, bir takım bir sprintin iki hafta sürdüğünü ve diğeri 30 gün olduğunu düşünürse, bu Leffingwell'in "Babil Kulesi sorunu" olarak tanımladığı şeyi yaratır. Ekipler için "özelliğin" ne anlama geldiği konusunda anlaşamazlarsa hangi özelliklerin ekleneceğini tartışmaları zordur. “Büyük çözümler oluşturmak istiyorsanız, ortak bir şekilde çalışan insanlara ihtiyacınız var” diyor. “Sektörümüzde 'yineleme', 'sprint' veya 'birikim' gibi aşırı yüklenmeyen bir terim yok. Ekip ve bölgesel sınırlar arasında çalışmaya çalışıyorsanız bu yardımcı olmaz.”

Çevik Başarı Öyküleri

Bir şirketteki herkesin bir iş hakkında konuşma ve iş yapma konusunda birleşik bir yol benimsemesini sağlamak, değişim için muazzam bir aciliyet olduğunda bile göz korkutucu bir iştir. Yerleşik şirketlerde daha zor olabilir. Leffingwell şöyle açıklıyor: “Çok para kazanan, inanılmaz derecede iyi iş çıkaran ve rekabet eden dünyanın en büyük şirketlerine bakıyorsunuz ve değişmeleri gerekiyor. Peki, onlar için soru, neden yapsınlar?” Burada Toptal proje yöneticilerinin her biri kendi ölçeklendirme faaliyetleri sırasında buna benzer sorularla karşılaştı ve her biri SAFe kullanarak Çevik dönüşümlerinde kendi çalışma yollarını buldu.

Değer Göstermek

Santiago, Şili'deki bir Toptal proje yöneticisi olan Alvaro Villena, kısa bir süre önce çapraz iş platformu geliştiren bir portföy için SAFe geçişini tamamladı. “Geçişimdeki ilk kilometre taşı, bir değer akışı çalıştayı yürütmekti” diyor. Basit bir ifadeyle, bir değer akışı çalıştayı, konseptten teslimata kadar tüm iş sürecini ve aradaki tüm adımları, kullanıcıları, sistemleri ve sorunlu noktaları tanımlayan bir başlangıç ​​toplantısıdır.

Tüm işletmeden temsilcilerin çalıştaya katılması, Villena'nın şirket kültürünü ve önündeki engellerin neler olabileceğini anlamasına yardımcı oldu. "Atölyeyi uygulamadan önce, bir işletmenin kendi ekibinin, başka bir işletmenin ekibinin ve bir sonraki işletmenin ekibinin olduğu bir yapı vardı - üçü birbiriyle konuşmuyordu."

Villena, tüm ekiplerin benzer acı noktalarını paylaşmasına rağmen, çözümler üzerinde işbirliği olmadığını tespit etti. Örneğin portföydeki her işletme ürün sevk etmesine rağmen sadece bir tanesi takip sistemi geliştirmişti. Kimsenin bilgiyi paylaşmamış olması dışında, hepsini kullanmamaları için hiçbir sebep yoktu. Çalıştay onları konuşturduktan sonra ekipler, işletmeler ve ürün sahipleri arasında bilgi akışı başladı. “Bu tür bir konuşma program için gerçekten çok güçlüydü. Güzel bir başlangıç ​​noktasıydı,” diyor Villena. DevOps, tasarım ve ürün, diğer ekiplerin ne yaptığını bildiğinde, şirkette kullanabilecekleri çözümler olduğunu görürler. “Buna nasıl sahip olabilirim?” diye sormaya başlıyorlar. İşte burada devreye giriyor ve 'Bu süreci takip edin' diyorsunuz.”

"Kimse nedenini öğrenene kadar değişim istemez. Yani bir neden ile başlıyorsunuz ve onlara daha iyi bir gelecek veriyorsunuz.” SAFe'nin yaratıcısı Dean Leffingwell

Leffingwell, ekiplerin bazen dirençli olduğunu biliyor. Toptal'a “Kimse nedenini öğrenene kadar değişim istemez” diyor. “Yani bir neden ile başlıyorsunuz ve onlara daha iyi bir gelecek veriyorsunuz.” Ekiplere ne kadar verimli olabileceklerine dair bir fikir vermek, değişim liderliği için güçlü bir araçtır.

Herkes hevesli bir şekilde gemide olsa bile, yine de zorlu başlangıçlar beklemelisiniz. Örneğin, geleneksel Şelale geliştirmeye ve büyük sürümlere alışmış olan ekipler, bunun değerini görseler bile daha yinelemeli ve çevik bir geliştirme sürecine geçmekte zorlanabilirler. Villena, "Yaptığımız ilk program artışı, takımlar için bir tür felaketti" diyor. “Ve bunun olacağını biliyorduk; müşteriye ilk üç ayın zor olabileceğini beklemesini söyledik.” Bunu telafi etmek için, ilk program artışının (PI) sonunda ekiplerin ilerlemelerini değerlendirebilecekleri bir haftalık bir tekrarlama oluşturdu. Yalnızca, olağan inceleme ve uyarlamanın ötesine geçecek iyileştirmeler ve değerlendirmelere ayrılmış bir sprint düzenledi. Sadece ürüne değil, aynı zamanda iş geçişine de Çevik bir zihniyet uygulamayı, geri adım atmak, neyin işe yarayıp neyin yaramadığını görmek ve buna göre ayarlama yapmak için zaman ayırmayı faydalı buldu.

Küçük Zaferler Yaratmak

SAFe'yi benimsemenizde beklenmeyen engellere hazırlıklı olmak önemlidir. Birkaç yıl önce, Sırbistan'ın Belgrad kentindeki Toptal proje yöneticisi Miroslav Anicin, bir telekomünikasyon şirketini SAFe'ye geçiriyordu. Şirket, tüm yazılım geliştirmesini dışarıdan temin etmişti. Tesis dışı bir ekibin dahil edilmesi özellikle zahmetli bir iş değildi - söz konusu olan sorunlar çoğunlukla lojistikti. Ancak çaba, şirketin kendi geçişinde öngörülemeyen zorluklar yarattı. “Serbest bırakma treninde ihtiyacımız olan yetkinlikleri arıyordum” diyor. "Ve seçmem gereken tüm insanlar pazarlamadan, hukuktan, ürünlerden, finanstan - tamamen Çevik zihniyetten ve hatta Çevik konusunda herhangi bir deneyimden yoksundu."

Yönetimin Çevik ekipleri yönetme deneyimi olmadığı ortaya çıktı. Dağıtılmış karar verme, yöneticilerin bazı kontrollerden vazgeçmelerini gerektirir; bu, Çevik çerçeveler konusunda deneyimli değillerse liderliğin vazgeçebileceği bir gerçektir. Bunu çözmek için Anicin, aşağıdan yukarıya ve yukarıdan aşağıya, liderlerine ekipleriyle birlikte koçluk yapmak zorunda kaldı.

Leffingwell, daha merkezi olmayan karar verme sürecine böyle bir geçiş, "hizmetkar liderlik yoluyla komuta ve kontrolden, bu güçlendirici öğrenme kültürüne ve Çevik kültüre ve hataları tolere etme yeteneğine geçmeyi" gerektirir.

Anicin, bireysel ekiplerin bir miktar uygulamalı deneyim geliştirebilmesi için, SAFe çerçevesinde değil, tek ekipler içinde gerçekleştirilen küçük Çevik projelerle aşamalı olarak ölçeklendirme sürecine başladı. Bu projeler, ilk denemede bir şeyler ters giderse şirketin zarar görmemesi için önemsiz ve yeterince küçük olmalı, ancak ekibe yaklaşımla nelerin başarılabileceğini gösterecek kadar faydalı olmalıydı. Örneğin, pazarlama ekibi, Anicin'in onlara Scrum'ın temellerini öğrettiği bir dahili pazarlama kampanyası oluşturdu. Villena'nın atölyesine benzer şekilde, bu küçük projeler Çevik'in değerini gerçek anlamda gösteriyor, böylece ekip üyeleri ve liderler tam ölçekli geçişten önce kısa sürümlerin ve sürekli iyileştirmenin faydalarını görebilirler.

Ekiplerinizin İhtiyaçlarını Karşılama

Paris merkezli bir Toptal proje yöneticisi olan Imane Marouane, büyük, çok uluslu bir finans kurumunun dönüşümüne öncülük ettiğinde, bireysel ekiplerin sağlam işler ürettiği ancak şirket çapında hiçbir vizyonu paylaşmadığı kaotik bir ortama adım attı. "Her takımın kendi önceliği vardı. Her ürün yöneticisi önce ürününün teslim edilmesini istedi.”

SAFe'nin bu soruna çözümü, ağırlıklı kısa iş ilk (WSJF) modelinde bulunabilir. WSJF, işe öncelik vermek için bir standart sağlar, bu nedenle bir sonraki görevin ne olacağına karar verme zamanı geldiğinde, ilk adım, önem sıralamasına ilişkin anlaşmazlıkları içermez. Akış tabanlı bir Çevik sistemde, her şeyi bir kerede teslim etme konusunda endişelenmenize gerek yok çünkü Leffingwell'in dediği gibi “en önemli şey bir sonraki işin ne olacağıdır. Ve bu, cevaplaması en değerli işin ne olduğundan çok daha kolay bir soru.” SAFe, ekipler arasındaki bağımlılıkları çözmenin bir yolunu sunar; bu sonuç için görevlerin sıralanması çok önemlidir.

"Ağırlıklı En Kısa İş İlk Formülü" başlıklı bir illüstrasyon. Bir kutu, "WSJF, Gecikme Maliyetinin İş Süresine (İş boyutu) bölünmesine eşittir" formülünü içerir. En altta "Kaynak: Ölçekli Çevik" yazan bir satır var.
Ölçekli Çevik'in Öncelikli Ağırlıklı En Kısa İş formülü, gecikme maliyetini gereken işin zorluğuna ve süresine karşı tartarak görevleri öncelik sırasına koyar.

Marouane'nin bağımlılık çözümüne giden yolu belirsiz hale geldi: "İki sprintten sonra, ilk inceleme ve uyarlamadan önce, bazı takımların PI planımıza uymadığını fark ettik." PI planında tanımlanan bağımlılıklar takip edilmiyor, bu nedenle bir takımın çalışması başlayamadı çünkü başka bir takımın katkısı hazır değildi.

Marouane, "Bu ilk yineleme olduğundan ve ekipler bu tür çalışmalara alışık olmadığından, fazladan bir tören düzenlemeye karar verdik - bağımlılıklarla ilgili ilerlemeyi tartışmak için haftalık bir toplantı," diyor. "Her takımdan bir kişi katkılarıyla ilgili ilerlemeyi güncellemek için geldi." Bu şekilde, A Takımı teslim edemeyeceklerini söylerse, B Takımı sprintlerinin başında gerçekleşmeyecek katkıları beklemek yerine önceden bilip buna göre plan yapabilirdi.

Leffingwell, SAFe'de bu tür ayarlamalar yaparken dikkatli olmayı öğütler: “SAFe bir sorumluluklar sistemidir. … Uyarlayabilirsiniz ama çok dikkatli olmalısınız.” Çerçevenin uyarlanabilir olması amaçlanmış olsa da, yeniden değerlendirilmediği takdirde değişiklikler pişme eğilimindedir. Essential SAFe konfigürasyonu, herhangi bir değişikliğin temel kriterleri karşıladığından emin olmak için mevcuttur.

Marouane'nin ekstra töreni ikinci PI'ye tekrar dahil edildi ve üçüncüsünde aşamalı olarak kaldırıldı. Ekiplerin, daha önce bildirilmemiş olan rapor edecek hiçbir şeyleri yoktu. Biraz ekstra esneklik, Marouane'nin ekipleri daha geleneksel bir süreç yoluna geri götürmesine izin verdi. Finansal kurumun ekiplerinden en iyi şekilde yararlanmak için geçişin kendisinin Çevik bir zihniyet gerektirdiğini keşfetti. Ve daha da önemlisi, sürekli iyileştirme taahhüdüyle yaptığı değişiklik, nihayetinde Essential SAFe'nin temelini oluşturan Yalın-Agile ilkelerine hizmet etti. Çözümü, şirkete sahip olmadığı birleşik vizyonu verdi ve ekiplerin aynı öncelikler doğrultusunda birlikte çalışmasına izin verdi.

Geleceğe Uyum Sağlayın

Ölçekte çalışan herhangi bir çerçeve zorluklarla gelecektir. Hareketli parçaların sayısı ve rekabet eden çıkarlar çok büyük. Ancak getiriler eşit derecede büyüktür ve iyi yürütülen bir geçiş, ekiplere ortak hedeflere doğru çalışmak için ihtiyaç duydukları araçları sağlayacaktır. Bu kadar büyük ölçekli bir uygulamada karşılaşacağınız engeller tahmin edilemez olacak ve Çevik bir zihniyet Villena, Anicin ve Marouane'nin beklenmedik zorluklara uyum sağlamasına yardımcı oldu. Sonuçta, sürekli teslimat bunun içindir: öngörülemeyenlere uyum sağlamak için sürecinizi araçlarla güçlendirmek.

Scaled Agile ayrıca yeni teknolojilere ve gelişen endüstri standartlarına uyum sağlayarak gerektiğinde yeni araçlar ve yetenekler sunar. Herkesin çevik kalması ve beklenmedik durumlara hazırlıklı olması gerekiyor. Leffingwell, "Kristal küremiz yok" diyor. "Hızlı koşuyoruz, sıkı liderlik ediyoruz ve sıkı takip ediyoruz - ve elimizden geldiğince hızlı yazıyoruz."