Kurumsal Çeviklik Karşısındaki 7 Engel
Çevik olmaya Scrum ile başlayan büyük şirketlerle çalışırım. Her kurum farklı bir iş sektöründeyken, farklı teknoloji kullanırken ve farklı yönetim kültürlerine sahipken hepsi ortak bir soruna sahiptir, bir çeşit devlik. Bu makale büyük organizasyonlarda çeviklik karşısındaki yaygın engelleri listeler ve devlik semptomlarının tamamıyla önlenebilir olması olasılığını inceler.
İlk bakışta bir organizasyonun karşılaştığı zorluklar yapılacak çok iş olması, yeterince kaynak olmaması ya da iş ortamındaki havanın değişmesi olarak ortaya çıkacaktır. Yakından incelersek, kök nedenler kötü alışkanlıklar, geliştirilmemiş refleksler ve yanlış anlamalar olduğu çıkar.
Ünlü bir şirketin 1997’nin başarı hikayesi olarak bahsettiği bir Scrum öncüsü 2009 yılında Danube Technologies, Inc.’ye yardım için eldi. Çünkü pazardaki güçleri rakiplerinden daha az çevik olduklarını gösterdi. 1997 yılında başlatılan Scrum girişimi açıkça geniş ölçekli çeviklik önündeki engellere on yıl dayanamadı. Ne yazık ki, büyük kurumlardaki Scrum’ın benimsenmesi girişimlerinin çoğu dayanıklı ve devam eden bir şekilde sonuçlanmaz. Scrum’ın benimsenmesinin karşısındaki engeller genellikle iş başarısının karşısındaki engellerdir, engellerin yerleştiği kurumlar bunlardan vazgeçmekte isteksizdirler.
Engel #1 : Bilinçsiz Kaynak Yönetimi
PMOK Klavuzu, çoğu kez daha az zaman içinde aynı miktar işi tamamlayabilmek adına ek kaynaklar eklemek için bütçenin arttırılmasına ihtiyaç olduğunu söyler. Daha spesifik olarak yazılım için Fred Brooks(The Mythical Man-Month’ta) açıkça karşıt bir iddiada bulunur: Gecikmiş bir yazılım projesine insangücü eklemek projeyi daha da geciktirir. Bu paradoksu çözmek için hadi kaynak tanımını inceleyelim.
İş yeni bir ürün geliştirilmesi olduğunda ilgili kaynaklar soyuttur: görevlerin eritilmesi, öğrenmek, kişilerarası iletişim ve yenilik. Scrum Takımları, bireysel ve grup akışı durumu yaratarak bunları maksimize etme girişimindedir. Psikolog Mihaly Csikszentmihalyi’e göre [Akış içinde] tümüyle dahil olursunuz ve yeteneklerinizi son dereceye kadar kullanırsınız.
Scrum geliştirme takımı üyeleri, amaçlar doğrultusunda ürünler geliştirmek için yoğun bir işbirliği içindedirler. Takım, gerçekleştireceği işin kararlarını vermekten sorumlu Product Owner ile tekrar tekrar pazarlık eder. Sonuçlar, belirli uzunluktaki her sprint sonunda gösterilir.(Örneğin her iki haftada). Sprintin koşulması sırasında ortak amaçlar doğrultusunda takım üyeleri içsel bir ilgi geliştirirler ve amaçlara ulaşmak için birbirlerini yönlendirmeyi öğrenirler. İdeal şartlarda bile(takım odası dahil) uygun adıma geçmesi üyeliğin kararlı-sabit- olması birkaç sprint alır ve bir yıl yada yakın bir zamanda potansiyeline ulaşır. Bu organik sürecin popüler tanımı şudur: Bruce Tuckman’ının forming, storming, norming, performing modeli.
İnsanları kaynak olarak düşünmek bilinçsizliktir. İnsanları bir takıma eklemek soyut kaynakları güvenilir bir şekilde arttırmayacaktır –ve bu kaynakları eksiltebilir. Bir yıl Scrum yapılmasının ardından, müşterilerimden biri şunu söyledi, Bir defa bir takım şekillendiğinde bir takım üyesinin katılması yerine kaybetmeyi yeğleriz!. Diğer bir durumda Scrum takımı işe alım kararını kendisi verdiği zaman takıma yeni bir üyenin katılması iyi sonuçlanır. Takıma işe alma özerkliği verildiğinde bile takımın yedi kişiden daha fazla olması tavsiye edilmez.
Eğer soyut kaynaklar konusunda endişeliysek bazı şartlar altında yeni takımlar eklemek daha çok ilerlemeyle sonuçlanabilir.
Engel #2 : Fonksiyonel Uzmanlık İle Düzenlenen Takımlar
Scrum Takımı, her sprintte, uygun bir şekilde test edilmiş ürün artımı geliştirilmesini başarmaya çalışan, kademeli olarak bir özellik ekleyen, çapraz fonksiyonel bir gruptur. Scrum hakkındaki en popüler kitap, potansiyel olarak kullanılabilir ürün artımı ifadesini 18 defa kullanır. Başlarda analiz sprintleri yada tasarım sprintleri koşarken, entegrasyonu ve test etmeyi sona bırakan ve her faz için farklı takımları sorumlu tutan ve buna rağmen, Scrum yaptıklarını iddia eden insanlarla tanıştım! Bu waterfall alışkanlıkları cevap vermek için çok geç oluncaya kadar riskleri gizler.
Scrum, her Sprintte bir geliştirme işi karışımına(analiz, geliştirme, test, entegrasyon) ihtiyaç duyar. Sürekli gereksinim analizi, sürekli tasarım, sürekli entegrasyon ve sürekli test etme hepsi birbirini besler.
Engel #3 : Mimari Bileşenler İle Düzenlenen Takımlar
Tek bileşen takımlar, ürün yeteneklerini yeniden önceliklendirme için iş yeteneğini azaltır, müdürler ve Product Owner’lar(ürün sahipleri) arasında koordinasyon darboğazını (bottleneck) arttırır ve entegrasyon risklerini ortaya çıkarır.
Eğer yeni ürün geliştirilmesi, imalatın tahmin edilebilir olduğu kadar tahmin edilebilir olsaydı, bileşen takım yaklaşımı verimli olurdu. Pratikte öncelikler değişir ve tahminlerin yanlış olduğu ortaya çıkar bu nedenle bir çok bileşeni etkileyen yetenekleri geliştirmek için doğru zamanda doğru insanlardan uygun odak noktasını elde etmek zordur.
Bileşen takımının tersi özellik takımıdır. Özellik takımı hem bileşeni ve hem disiplini içerir ve bu nedenle küçük, tamamıyla test edilmiş dikey parçalar içinde iş değeri olan özelliklerin geliştirilmesi yeteneğine sahiptir. Son yüz yılın rasyonel düşüncesi özellik takımı yaklaşımının takım özerkliği, sahiplik ve sorumluluk konseptiyle yer değiştirir. Özellik takımlarının Product Backlog’ları(ürün gereksinimleri) iş değeri ile kontrol edilir, teknoloji bağımlılığı ile değil. Eğer hala Gantt Şeması ile yaşıyorsanız muhtemelen hala özellik takımlarına sahip değilsiniz.
Özellik takımları oluşturmak maliyetiyle gelir: geliştiriciler, onları başlarda yavaşlatacak yeni yetenekler öğrenmelidir. Neyseki birçok geliştirici yeni yetenekler öğrenmekten hoşlanır. Takımlar öğrenirken, her bir alan için bileşen koruyucusu belirleme gibi teknikler mimarisel bütünlüğü korumaya yardımcı olur. Herhangi geliştirme gibi sürekli entegrasyon(günde bir seferden çok daha fazla olarak koşulan otomatikleştirilmiş testler) da belirlenmemiş regresyon hatalarını önlemek için çok önemlidir.
Bir kurum özellik takımlarına sahip olduğunda bir sonraki adım özellik alanları için azaltılmış yakınlık ile genel amaçlı özellik takımları olabilir. Böyle bir adım yıllarca uzakta olabilir, bu yüzyıl öğrenen organizasyonların olacaktır.
Engel #4 : Dikkatin Dağınıklığı
Tipik büyük bir kurum gereksiz görev değişikliklerine milyonlarca dolar harcar. Odağı olmayan takımların, kendi kendini yöneten duruma gelmeleri için sürekli üyeliğin istikrarı ve aylarca yüksek performans ve kalite gerektirir. Bazı insanlar sürekli olarak kendilerini aynı anda birkaç kritik yolda bulurlar, ciddi olarak toplam üretkenliği kısıtlar. Verimli bir artış için, bu kişiler işi gerçekleştiren kişilerden çok mentorlara dönüşmelidirler. Etkilerini arttırmak için kontrolü bırakmalıdırlar.
Geleneksel yönetim pratikleri uzmanlaşmayı güçlendirir, bu sorunu kötüleştirecektir. Yapılacak iş, Scrum Takımına Sprint Planlama Toplantısı aracılığıyla sunulmalıdır. Müdür, bu işi birine atayarak verdiğinde, kritik becerilerde diğerlerine mentorluk yapabilmesi daha düşük bir olasılıktır. Son zamanlarda şunu gözlemledim, Sprint Planlama Toplantısı’nda ilk soru Bu sprintte kimler var?. Bir grup insanın bir anda bireysel çalışmaya çekilmesi Scrum Takımı’nın beklediği iş birlikçi öğrenme ile örtüşmeyecektir.
Yüksek rütbelerde, kontrolden vazgeçerek aynı anda birden fazla iş yapma, dikkat dağınıklığı, sıkıntı ve yetkin olmamanın problemleri daha da kötüdür. Aynı toplantıda, Product Owner yüzünde ürkek bir duruş ile neredeyse bir saat geç kaldığı toplantıya koşturarak içeri girdi. 10 dakika sonra yine koşturarak çıktı; bana bunun bir rutin olduğu söylendi.
Bu öğleden sonra, yönetici 60 çalışanıyla yaptığı toplantıya odaklanamıyordu çünkü aynı anda BlackBerry’si üzerinden başka bir durumu idare etmeye çalışıyordu. Bu sahnelerin sıradan bir gözlemcisi, bu çılgınca olayın kölelerinin uzun menzilli stratejilerden sorumlu olduğunu tahmin edemezdi.
Scrum Takımları arasında verimli yan iletişim Product Owner’ların sakince işi önceliklendirme ve gereksinim sorularında son sözü söyleyen olma gibi sorumluklarına odaklanmasına yardım eder.
Engel #5 : Sürekli Düzeltme, Önceliklendirme ve Yeniden Değerlendirmeye İsteksizlik
Ürün geliştirmede yeni kapsam keşfi çoğunlukla hızı(velocity) geçer. Bu gerçekliği yönetebilmek için Product Owner’lar her sprintte Product Backlog’un düzeltilmesi(Grooming) toplantıları yapmalıdır. Büyük PBI’lar(yada destanlar) ortaya çıkartıldığı gibi, onların yüksek değerli yönlerini bulunabilir ve onlar daha küçük, ayrı maddelere bölünebilir(tipik kullanıcı hikayeleri). Product Owner hangi maddelerin release projectiona sığacağına karar vererek, velocityinin geçmişteki yönelimine ve kapsamın keşfine bakarak kapsamı kontrol eder.
Engel #6 : Coşmuş Teknik Borç
Kurumun yönetim sorunları nihayetinde kaynak kodda görülebilir. Bu teknik borç üretim ortamı problemlerine ve yüksek maliyetli değişikliklere neden olur. Regresyon testleri, uzmanlaşmayı pekiştiren tescilli bir araç kullanılmasındansa production ortamında geliştirilen ürünle aynı programlama dili kullanılarak otomatikleştirilir. Test Driven Development(TDD) gibi yetkinlikler 20.yüzyılda değerini kanıtlamıştır. 21.yüzyıl içinde agile mühendislik becerileri her developerdan beklenecektir. Bu becerilere sahip olmayan takımlar başlarda daha küçük dikey parça işler almalıdırlar ta ki bu becerilere sahip olana kadar.
Engel #7 : Dönüşüm İçin Verilen Sözün Eksikliği
Scrum, engellerin ortaya çıkarılması ve bu engellerin üstesinden gelmek için her takıma bir kişi(Scrum Master) tam zamanlı olarak-bunun gibi engeller– tahsis eder. Bu cesaret, hayal gücü ve yönetimden destek gerektirir. Çok az Scrum Master bunun için gerekli özeni gösterir ve yönetim, bu özeni gösterenleri genelde desteklemekte başarısız olur.
Yapılacak çok iş olması, yeterince kaynak olmaması yada iş ortamındaki havanın değişmesi, agile pratiklerini göz ardı etmek için iyi bahaneler değillerdir. Değişimin temsilcileri, kök nedenler olan kötü alışkanlıkları, geliştirilmemiş refleksleri ve yanlış anlamaları farkederek bu engellerin üstesinden gelmede daha donanımlı olacaklardır.
Referans
http://scrumreferencecard.com/7-obstacles-to-enterprise-agility/#comment-2339
Yorumlar