Proje Yönetimi Uzmanlarından

Çevik yaklaşımlardan beklenen faydanın sağlanması çevikliğin kurum bünyesine yayılmasına bağlıdır. Bir veya birkaç doz Scrum çevikliğin kurum bünyesine yayılmasına yetmez, özellikle geniş ve hiyerarşik yapılarda. Çünkü Scrum uygulanan yer, uzun bir  sürecin en fazla katma değer sağlayan noktası olmasına rağmen, sürecin diğer parçalarından bağımsız değildir. Pilot projelerle başlayan çevik dönüşüm çabalarında, sürecin Scrum uygulanan kısmına böyle bir bağımsızlık talep edilir ve bir miktar elde edilir de. Bu sayede proje bazlı olarak çevikliğin olumlu yansımaları hemen hissedilir. Çevik alan genişlemeye başladığında ise, proje bazlı bağımsızlığın kalıcı bir bağımsızlık olmadığı gerçeği ile yüzleşilir.

Büyük organizasyonlarda, genellikle proje bazlı olarak başlatılan çevik dönüşümleri kuşatan geleneksel bir yapı bulunmaktadır. Bu geleneksel yapı hem süreç boyutunda, hem de organizasyonel yapılanma boyutunda yürürlüktedir. Süreç açısından bakıldığında, kurum vizyonu ve stratejileri doğrultusunda belirlenen projeler önceliklendirilir, bu projeler bir master plana yerleştirilir, kaynak atamaları yapılır, atanan kaynakların devam eden projelerle çakışmamasına çalışılır, bu doğrultuda master plan revize edilir, bu arada değişen piyasa şartları ve regülasyonlar nedeniyle daha öncelikli projeler olduğu fark edilir, devam eden bazı projeler durdurulur, kaynak planlaması revize edilir, master plan revize edilir ve bu döngü büyük zaman kayıplarıyla böyle devam eder. Organizasyonel yapılanma açısından bakıldığında ise, iş tarafındaki birden fazla etkinlik alanı, bilgi teknolojileri tarafındaki birden fazla etkinlik alanı (domain) ile kesişir ve bu durum gerek proje önceliklendirmelerinde gerekse bilgi teknolojileri ekiplerinin ürün ve hizmet sunumunda kargaşaya sebep olur. Böyle bir kuşatma altında başlatılan çevik dönüşüm çabalarında farklı yöntemler denenmelidir:

Proje Bazlı Çevik Dönüşüm

Geleneksel yapının kuşatması altında olunmasına rağmen, çevik dönüşümü proje bazlı başlatmak doğru bir yöntemdir. Geliştirilecek ürün veya hizmetle ilgili son karar verici olabilecek güçlü ve dedike bir ürün sahibi ve diğer işlerden soyutlanarak sadece proje faaliyetlerine odaklanacak bir geliştirme ekibi ile yürütülecek çevik projeler, kuruma değer katacak yazılım bileşenlerinin hızlı ve sürekli olarak müşterinin kullanımına sunulmasını sağlayacak, bu sayede müşteri memnuniyetine, çalışan motivasyonuna ve kurumun finansal sonuçlarına direkt ve olumlu bir etki yapacaktır. Elde edilen bu önemli ve hızlı kazanımlar, çevik dönüşümün önündeki engelleri azaltacak, ancak geleneksel yapının kuşatmasını kaldırmayacaktır.

Proje bazlı yaklaşımın bazı dezavantajlarından da bahsetmek gerekir. Çevik yaklaşımlar süreklilik gerektirir. Proje sonunda geliştirme ekibi dağıtılıyorsa, takım olma sinerjisi içerisinde kazanılan hız ve performansın korunması, ürün ve yazılım geliştirme faaliyetleri ile ilgili olarak elde edilen bilgi ve yetkinliklerin süreklilik arzedecek bir şekilde aktarılması ve geliştirilmesi mümkün olmaz. Öte yandan, her ne kadar geliştirme ekibi diğer işlerinden soyutlansa da, ekip üyelerinin dahil olduğu domainlerden gelen ve mutlaka ilgilenilmesi gereken acil operasyon talepleri ya planları sekteye uğratır, ya da ekip üyesi ile yönetici arasında gerilim yaratır. Bu noktada daha farklı bir yöntem gündeme alınabilir:

Domain Bazlı Çevik Dönüşüm

Bilgi teknolojileri içindeki bir domaini bütünüyle çevik dönüşüme tabi tuttuğunuzda, etrafınızdaki kuşatmanın etkisi daha az hissedilecektir. Bu noktada gerek koşul, bu domainin iş tarafında çıkar çatışması yaratmayacak şekilde sınırlı sayıda müşterisinin olması ve domaindeki ekip büyüklüğünün farklı müşterilerin ürün sahipliğinde Scrum yapılanmasına olanak tanımasıdır.

Bu şartlar oluştuğunda, domain bazlı dönüşüm en sağlıklı dönüşümdür. Ürün sahipleri ve geliştirme ekipleri sabitlenmiştir. Sürekli akışa (continous flow) imkan tanıyan bir backlog yönetimi ve sürekli gelişim sağlayan bir ekip ortamı yaratılmıştır. Tek backlog içinde hem ürün özellikleri hem de bilgi teknolojileri altyapısından kaynaklanan sistem ve mimari gereksinimleri sorunsuzca geliştirilebilir. Öngörülemediği için planlanamayan acil operasyonel taleplerin planlanmış işlerin önüne geçmesi engellenebilir. 

Ölçeklenmiş Çeviklik (Scaled Agile)

Büyümeye çalışan çevik organizasyonlarda geleneksel yapının kuşatmasının yarattığı sürtünme etkileri, tüm kuruma yayılan yalın ve çevik yaklaşımlarla aşılabilir. Kurum vizyonuna ve stratejilerine uygun olarak belirlenen yatırım temaları kanban yaklaşımı içinde, WIP (work in progress) limitleri paralelinde analiz edilir ve katma değerleri doğrultusunda önceliklendirilir. Önceliklendirilen işler kurumsal backloga alınır ve bu aşamada hem üst seviye ürün özellikleri hem de kurumsal mimarinin gerek duyacağı mimari gereksinimler planlanır. Bir sonraki aşamada ürün yönetimi ekipleri kurumsal backlogda önceliklendirilen kendi takibindeki işleri alır ve bu işleri kaynak yöneticileri, mimari ekipler ve sürüm planlama ekipleri ile tartışarak bir ürün yol haritası oluşturur. Farklı ekipler tarafından yönetilen ve planlanan ürünlerin birbirleri ile ilişkileri ve bağlılıkları gözönünde bulundurularak kurumsal bir sürüm planı oluşturulur ve her bir geliştirme ekibinin takım backlogları belirlenir. Geliştirme ekipleri kurumsal sürüm planına uygun bir şekilde takım backloglarındaki işleri planlar ve teslim eder.

Bu yaklaşımda başlangıç aşamasından itibaren, üst yönetim, iş tarafı ve bilgi teknolojileri ekipleri sıkı bir iletişim içindedir. Değişiklik talepleri her zaman hoş karşılanır ve oluşturulan akışın dinamik yapısı içinde eritilir. Proje yaklaşımı yerini değer zinciri (value chain) yaklaşımına bırakmıştır. Ürün kavramı tektir ve odağında müşteri vardır. Amaç müşteri ihtiyacının en kısa akışla, kaliteli bir şekilde karşılanmasıdır ve bu doğrultuda bilgi teknolojileri ekipleri, geliştirme altyapısı ve mimarisini sürekli yeni şartlara adapte eder.

Böyle bir yapıda kuşatma kalkmıştır, her yer çeviktir.