Başarıya Farklı Bir Bakış

Başarı günümüz modern dünyasında çok sık karşımıza çıkan bir kavram. Bu kavramı daha önce proje perspektifi ile ele almıştık (İlgili Makaleler:Projelerde Başarı Etkenleri, Başarılı Proje Ekibinin Soruları, Öğrenilmiş Çaresizlik).

Bu yazıda genel olarak başarıdan bahsetmek istiyorum. Okulda başarı, sınavlarda başarı, spor müsabakalarında başarı ve iş hayatında başarı ise biraz daha öne çıkan kavramlar. Kimi için okuldan atılmamak başarı iken, kimi için okuldan dereceyle mezun olmak başarı. Kiminin sınavdan geçer not alması başarılı kabul edilirken, kiminin sınavdan tek bir yanlış cevabı başarısızlık olarak görülüyor. Kiminin olimpiyatlara katılabilmesi başarı iken, kiminin olimpiyatlarda gümüş madalya alması hayal kırıklığı olabiliyor. Kiminin iş bulabilmesi başarı olarak nitelenirken, kiminin genel müdür olamaması başarısızlık olarak algılanabiliyor. Peki çok farklı şekilde kullanılabilen başarı kavramı nedir? Türk Dil Kurumu’nun başarı tanımı bir işi istenen şekilde sonuçlandırmak. Burada başarıyı göreceli hale getiren “istenen şekilde” kısmı. İstenen ve elde edilen karşılaştırılınca başarı ve başarısızlık arasındaki çizgi belirleniyor. Örneğin olimpiyatlarda altın madalya istenirken gümüş madalya almak başarısızlık olabiliyor.

Başarılı olmayı veya istenen sonuca ulaşabilmeyi neler etkiliyor? Ben dört temel faktör olduğunu düşünüyorum:

• Sahip Olunanlar: Genetik miras, maddi miras gibi doğuştan gelen ve etkileme imkanımız olmayan koşulları bu başlıkta düşünebiliriz. Bu koşulları değiştirme şansımız bulunmuyor. Bunları sabit kabul edebiliriz. Herkesin doğuştan gelen bir yeteneği, bir yatkınlığı, bir üstünlüğü bulunduğunu düşünüyorum. Eğer yeteneğimiz/yatkınlığımız/üstünlüğümüz olan bir alanda başarılı olmak istiyorsak avantajlıyız diyebilirim.
• Çevresel Koşullar: İçinde bulunduğumuz çağ, ülke, kültür, toplum, kurumlar, ailemiz, arkadaşlarımız, yaşadığımız çevre, okuduklarımız, dinlediklerimiz, okullarımız, işyerlerimiz, yediklerimiz, içtiklerimiz vb. yani yaşamımızın bütün değişkenlerini bu başlıkta düşünebiliriz. Bunların bir kısmını değiştirme imkanımız varken bazılarını değiştirme imkanımız olmaz ve bunlarda oluşan değişim dalgaları bizi de etkiler ve başarılı olma veya olmama durumunu belirleyebilir.
• Hedef: Başarı tanımımızda yer alan istenen sonuç yani hedef başarı durumumuzu belirler. Bu nedenle doğru hedef seçmek çok önemlidir. Ulaşılması imkansız hedefler belirlemek motivasyonu düşürdüğü gibi çok kolay ulaşılabilecek hedefler de gelişimi ve ilerlemeyi örseler.
• Çaba: Tamamen bize bağlı olan, başarı ve başarısızlık arasında en çok fark yaratabileceğimiz faktörün bu olduğunu düşünüyorum.

Yukarıdaki faktörleri birleştirince herhangi bir alandaki başarıyı şu şekilde formülüze edebileceğimizi düşünüyorum:

• Sonuç = Sahip Olunanlar + Çevresel Koşullar + Çaba
•  Sonuç >= Hedef (Başarı)

Bu denklemde öncelikle bir Sonuç elde etmek için sonuca etki edecek tüm parametreler toplanıyor. Sonucun Hedef'ten büyük veya eşit olması durumunda başarı tanımındaki “istenen sonuç” ortaya çıkıyor ve başarılı kabul ediyoruz. Çaba ve Hedef bizim en çok belirleyici olduğumuz alanlar. Eğer Hedef yüksekse buna uygun Çaba harcamadan başarıya ulaşılamaz. Başarı faktörlerini grafikle de gösterebiliriz. Grafiklerde konunun daha net görülebilmesi için her bir faktöre rakam verdim. Bu faktörleri ve etkilerini rakamlara dökmek başlı başına bir bilimsel çalışma olabilir. İlk grafikte elde edilen Sonuç, Hedef'in altında kalıyor. Sonucun Hedef'i geçebilmesi için izlenecek ilk yol ikinci grafikteki gibi Hedef küçültmek olabilir. Bu sayede başarı yakalanabilir. Ancak bu daha fazla Çaba harcamamak için yapılan bir kandırmacadır. Üçüncü grafikteki yaklaşımda ise Çaba artırılmış ve istenen sonuca ulaşılmıştır.

Sahip Olunanlar ve Çevresel Koşullar’ın uygun olduğu bir alan seçilmesi durumunda yeterli Çaba da gösterilirse büyük ve etkileyici başarılara ulaşılabilir. Örneğin doğuştan müzik yeteneği olan bir çocuğun, uygun müzik eğitimlerini alması ve yeterli Çaba'yı göstermesi ile tanınan bir sanatçı haline gelmesi mümkündür. Eğer müzik yeteneğini yokken veya uygun eğitimleri almadan, sadece Çaba gösterilirse ilerleme kaydedilir ancak tanınan bir sanatçı olmaya yetecek başarıya ulaşılamaz.

Bir başka konu da her alanda Sahip Olunanlar ve Çevresel Koşullar'ın aynı oranda etki etmediği gerçeği. Bazı alanlarda Sahip Olunanlar'ın etkisinin yüksek olabildiği, bazı alanlarda Çevresel Koşullar'ın daha belirleyici olduğunu hepimiz biliyoruz. Her ne kadar bu iki faktörün etkisi yüksek de olsa Çaba ile en zor alanlarda bile değişim sağlanabiliyor. Örneğin insanın zeka tiplerinden en çok bilineni ve en çok ölçüleni IQ'nun genetik olduğunu düşünürüz ve Çaba ile değişmeyeceği kanaati hakimdir. Bunun tam tersini söyleyen araştırmalar bulunmakta yani Çaba ile IQ'nun artabildiği veya tembellik ile azalabildiği yönünde. Yani IQ'nuzu 5 puan artırmak gibi bir Hedef belirlerseniz, bunu yeterli Çaba ile başarmanız mümkün. 

Yukarıda anlattıklarımdan hareketle iki temel prensibin başarı için önemli olduğunu düşünüyorum:

• Sahip Olunanlar ve Çevresel Koşullar’ın uygun olduğu bir alan ve gelişimi zorlayıcı akıllı bir Hedef seçilmesi
• Yeterli Çaba’nın harcanması

Bu iki prensip bir araya geldiğinde etkileyici başarılardan söz etmek mümkün olabilir.

Çevik Yöntemlerde Performans Ölçümü

Çevik yöntemlerle ilgili çeşitli güncel başlıklara daha önce değinmiştik (İlgili Makaleler: Çevik Yöntemlerde Sık Yapılan Hatalar, Çevik Yöntemler ve Teknik Mükemmellik, Çevik Yöntemlerdeki Rollere Uygun Profiller). Çevik yöntemler ve ölçme yan yana düşünül(e)meyen kavramlar gibi görünüyor, bir araya gelebilirler mi? Bildiğimiz performans ölçümü yaklaşımları çevik projelerde işimize yarar mı? Bu yazıda bu sorulara yanıt arayacağız ve performans ölçümünün çevik dünyadaki yerini aktarmaya çalışacağız. 

Çevik yöntemlere dönüşümün başarılı olabilmesi için organizasyonel, süreçsel, yönetsel ve kültürel dönüşümün birlikte olması gerekliliği bilinen bir gerçek (İlgili Makale:Çevik Yöntemlere Dönüşüm). Bu parçalardan birinin dönüşmemesi, çevik dönüşümün tamamını zedeleyebiliyor. Hangi parçanın ne kadar dönüştüğü ve ne kadar geliştiği ise performans ölçümü ile ortaya çıkarılabiliyor. Dahası performans ölçümü ile elde edilen sonuçlar geri bildirim olarak kulllanılarak hangi alanda ne kadar yol katedildiği, hangi alanların gelişime açık olduğu belirlenebiliyor. Bu sayede çevik yöntemlerin daha etkin kullanılmasına da olanak sağlanıyor.  

Çevik projeleri klasik performans ölçüm yaklaşımı ile değerlendirmek yeterli olmuyor. Örneğin klasik yaklaşımda proje başarısı “başta belirlenen tüm kapsamın”, belirlenen bütçe ve zaman limitleri dahilinde gerçekleştirilmesidir. Çevik yaklaşımlarda “tüm kapsamın” tamamlanması bir amaç değildir. Kapsam, Ürün Talep Listesi’ne (Product Backlog) eklenen ve çıkarılan her bir madde ile sürekli değişebildiği için “başta belirlenen tüm kapsam” maddesinden çevik yaklaşımlar otomatik olarak sınıfta kalacaktır. Çevik dünyada kapsam yerine müşteriye sunulan "değer" ön plana çıkarılıyor. Değeri sağlamak için tüm kapsamı yapmak gerekmiyor, öncelikli ve çalışan parçaları mümkün olduğu kadar erken ve sık teslim etmek tercih ediliyor.

Klasik “başarı” ölçümü yaklaşımı bir hedef belirlemek ve sonucu bu hedefle kıyaslamaktan geçiyor. Bu her zaman “başarılı” ve “başarısız”ı doğru olarak ölçebilir mi? Bir örnek vermek gerekirse, bir sınava gireceğinizi ve hedefinizin 10 üzerinden 7 almak olduğunu düşünün, eğer 7 alırsanız, sonuç hedefinize uygun olduğu için performansınız “başarılı” olacaktır. Eğer aynı sınavdan 9 almayı hedeflediyseniz ve 8 aldıysanız klasik performans ölçümü yaklaşımı ile hedefe ulaşamadığınız için “başarısız” olarak niteleneceksiniz. Peki sınavdan 7 almak mı yoksa 8 almak mı daha büyük bir başarı? 

Çevik dünyada sürdürülebilir gelişim ve iyiye doğru devamlı ilerleme teşvik ediliyor. Örneğin 3 sınavdan sırasıyla 9,8,7 (ortalaması 8) almak mı yoksa 6,7,8 (ortalaması 7) almak mı daha iyi? Sınavın ortalama puanına göre ilk durum daha iyi gibi görünüyor. Ancak artan bir performans çevik dünyanın felsefesine daha uygun.

Yukarıdaki yaklaşımlardan yola çıkarak çevik yöntemlerde 2 boyutlu bir performans ölçümü öneriliyor. İlki ürünün müşteriye sağladığı katkı yani değer (business value). Bunu ölçmenin en temel yolu ürünün sağladığı ekonomik katkının, Yatırım Geri Dönüşü (ROI-Return on Investment, ilgili makale: Proje için Finans) gibi parametrelerle belirlenmesinden geçiyor.  İkinci boyut ise ürünün ortaya çıkarılmasındaki performansın ölçülmesi,  bunlardan başlıcaları:

• Üretkenlik: Yapılan iş/fonksiyonalite miktarının (tamamlanan kullanıcı hikayesi, use case, özellik vb.) belirlenmesi. Bu ölçümün trend olarak izlenmesi, çevik takımın kendi gelişimini de görmesine yardımcı olacaktır. Gelişimin izlenmesi için Epic Burn-up Chart veya Product Burn-down Chart kullanılabilir.

•  Verimlilik: Birim zamanda üretilen iş miktarının ölçülmesi ile çevik takımın verimliliğini izlemek mümkün olacaktır. Örneğin çevik takımın bir döngüde (iterasyon) üretebildiği iş miktarının belirlenmesi ile sonraki döngülerde taahhüt edeceği iş miktarını da buna uygun seçme imkanı olacaktır. 

• Güvenilirlik: Sunulan ürünün sağlamlığı, güvenilir oluşu bu başlıkta izleniyor. Bu amaçla farklı metrikler tasarlanabilir. Örneğin yazılım projelerinde kod satır sayısı başına düşen hata oranı ile ürünün teknik kalitesi ve güvenilirliği ortaya konabilir. Ürünü teknik yönden kararlı olmasını sağlayan tüm metrikler de bu başlık altında düşünülüyor. 

Yukarıdaki başlıklar altında tasarlanacak performans metrikleri ile çevik takımın kendi içindeki gelişimini izlemesi, iyileşme potansiyelini fark edip artan bir performans grafiği yakalaması bekleniyor. Her çevik döngü sonunda yapılan retrospektiflerde (İlgili Makale:Çevik Yöntemlerde Retrospektif) bu amaca hizmet edilerek bir sonraki döngü için bir gelişim teması belirleniyor. 

Çevik yöntemlere dönüşümü hedefleyen kurumlarda daha en başından itibaren mevcut durumun belirlenmesi, gelişimin ölçülmesi ve trendinin izlenmesi, çevik yaklaşımların kattığı değerin net olarak görülebilmesi için çok büyük önem taşıyor. Burada da üç boyutlu :bir yaklaşım öneriliyor:

• İlki dönüşüme konu ekiplerin kendi içindeki gelişimin trend analizi.
• İkincisi dönüşüme konu olan ve olmayan ürünlerin kıyaslamasının trend analizi. Bunu dikkatli yönetmek gerekiyor. Takım bazında değil, ürün bazında yapmak lazım. Takımlar kıyaslanmamalı.
• Üçüncüsü şirketin toplamında yaratılan değişimin trend analizi.

İster çevik yöntemlere dönüşüm yolunda olsun, ister çevik metodolojileri daha iyi kullanabilme yolunda olsun, gelişimi izleyebilmek ve iyileşme fırsatlarını görebilmek için ölçmek gerekiyor. Son söz olarak ölçmeden yönetemeyeceğimizi unutmamak gerekiyor.

Çevik Yöntemlerde Sık Yapılan Hatalar

Ülkemizde giderek daha fazla ilgi çeken çevik yöntemlerle ilgili çeşitli yazıları (İlgili Makaleler: Çevik Yöntemlere Yolculuk, Çevik Yöntemler ve Teknik Mükemmellik, Büyük Ekipler Çevik Yöntemleri Uygulayabilir mi? ) daha önce kaleme almıştık. Bu yöntemleri uygulamaya çalışan bazı kurumlar istenen sonucu alamıyor ve bir süre sonra pes ederek eski alışkanlıklarına dönüyor. Bu başarısız dönüşüm çabalarından sonra çevik yaklaşımın kendi kurumlarına göre olmadığını belirtenlerin sayısı da azımsanmayacak kadar yüksek. Aslında çevik yöntemlerdeki uygulama hataları da bu başarısız dönüşüm çabalarında önemli yer tutuyor. Bu yazıda sık yapılan uygulama hatalarını ele alacağız:

• Yanlış Çevik Metodoloji Seçimi: Yapılan çalışmaya, ekibe ve projeye uygun olmayan bir yaklaşımla çalışılması doğal olarak başarı getirmeyecektir. Örneğin Kanban kullanmanın uygun olabileceği yerlerde herkes Scrum kullanıyor diye bu yaklaşımın kullanılması, ekibin motivasyonunu da verimliliğini de olumsuz etkileyecektir. Doğru çevik yaklaşımın belirlenmesinin proje, ürün ve ekip özelindeki dinamiklerin incelenmesi ile mümkün olacağını unutmamak gerekiyor.
• Yetkin Olmayan Ekipler: Tüm çevik yaklaşımlarda ortak olan konulardan bir tanesi çevik takımın kendini organize edebilmesi, işi küçük parçalara ayırabilmesi ve bunları kendini içinde planlayarak yapabilmesidir. Bu kabiliyetleri olmayan, dahası yönlendirmeye gereksinim duyan, direktifsiz çalışamayan ekiplerle çevik takım kurmak ve bu takımlardan üretim beklemek haksızlık olacaktır. Hem organizasyonel becerileri, hem iletişim becerileri hem de teknik yetkinlikleri yüksek olan takımların çevik yöntemleri hakkıyla uygulayabileceğini unutmamak gerekiyor.
• Dokümantasyon Yapılmaması: Çevik çalışmayı hiçbir dokümantasyon yapmadan çalışma olarak algılayan ekipler de var. Bu yaklaşım doğru değil, çevik metodolojilerle çalışırken gerekli olan dokümantasyonun mutlaka yapılması gerekiyor. Ürün kalitesine, sürdürülebilirliğe katkı yapacağı için bunu atlamamak gerekiyor. Burada en önemli prensip asgari yeter (barely sufficient) prensibine uygun olarak gerekli dokümantasyonu asgari yeter seviyede yapmak, ötesine geçmemek gerekiyor. Eğer süreçler gereği kullanılmayan dokümanlar üretiliyorsa, bunu kendiliğinden yapmamak yerine süreçlerden kaldıracak girişimlerde bulunmak da doğru bir yaklaşım olacaktır.
• Kısmı Uygulama: Çevik manifestonun ve arkasındaki prensiplerinin işine gelen kısmını uygulamak işine gelmeyenlerini göz ardı etmek, seçilen metodolojinin bazı kısımlarını yok saymak gibi yanlışlar ne yazık ki yapılıyor. Bu da istenen sonuçların alınmasını engelliyor.
• Sadece Mühendislik Ekipleri ile Sınırlama: Genellikle çevik yaklaşımların sadece mühendislik ekiplerinin çalışmalarını düzenlediğini düşünen ve kendini bu çemberin dışında gören ekipler ve paydaşlar da oluyor. Örneğin müşterinin, üst yönetimin, kalite ekiplerinin de çevik yaklaşımlara uygun olarak kendi çalışma yaklaşımlarını değiştirmeleri ve uygulanan çevik metodolojiye uygun hale getirmeleri gerekiyor.
• Şampiyon (CEO vb.) Olmaması: Çevik çalışmaların arkasında duracak, bu dönüşümün
  sponsoru olacak, eskiye dönüş konusunda gelecek baskıları durdurabilecek güçte bir kişinin 
  yani şampiyonun desteği mutlaka gerekiyor. Özellikle CEO’ların bu şampiyon olması tercih
  edilen bir durum.
  
• Hatalı Yönetim Tarzı: Direktif verici ve kontrol edici yönetim tarzının (command and control) çevik dünyaya uygun olmadığı bir gerçek. Çevik takımların kendi işlerini organize edebilen, bu işleri kimsenin talimatına ihtiyaç duymadan yapabilen takımlar olduğu gerçeğinden yola çıkınca direktif veren bir yöneticinin böyle bir takımın harmonisini nasıl bozacağını tahmin etmek zor olmayacaktır. Çevik dünyada istenen yönetim tarzı ise hizmet eden liderlik (İlgili Makaleler: Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerdeki Rollere Uygun Profiller) anlayışını barındırmalıdır.
• Ekibin Başına Buyruk Davranması: Çevik takımların kendini organize edebilme yeteneğini kötüye kullanarak, müşteriyi, ürün sahibini ve diğer paydaşları dikkate almadan çalışması da çevik yöntemlerden istenen sonuçların alınmasını engelleyen bir durum olarak karşımıza çıkıyor. Özellikle gelişmeleri görmek isteyen müşterinin reddedilmesi, geri bildiriminin yeterince alınmaması “çalışan ama işe yaramayan” ürünlerin ortaya çıkmasına sebep olmaktadır.
• Liderlerin İlgisiz Davranışları: Çevik takımlardaki ürün sahibi veya yönetici rolündeki (scrum master vb.) kişilerin geliştirme takımlarının yaşadıkları sorun ve karşılaştıkları engellere duyarsız kalmaları ve “siz kendiniz çözün” gibi yanıtlar vererek takımın önünü açmamaları da çevik yöntemlerde yaşanabilen bir hatadır.  Bu tür durumlarda çevik takımlar, ilerlemek için harcayacakları enerjiyi sorunların takibi ve çözümü gibi konulara kaydırmak durumunda kalıyor.
• İş Biriminin/Müşterinin Yetersiz Katılımı: Müşterinin veya iş birimlerinin projeye tam olarak dahil olmaması, gerekli yönlendirmeleri yapmaması, zamanda karar alamaması ile çevik takımların önü tıkanıyor. Bu da sık yaşanabilen ve çevik yöntemleri kullanan takımların istenen üretkenliğe ulaşmasını engelleyen bir durumdur.
• Kovboy Kodlaması: Çevik yazılım yapmayı kuralsız çalışmak olarak algılayan kişiler ne yazık ki bulunuyor. Bu da çevik yaklaşımların ortak prensiplerinden olan sürdürebilirlik ve teknik mükemmeliyet başlıkları ile çelişiyor.

Yukarıdaki tespitlere başka maddeler de eklemek mümkün. Çevik yöntemlerin başarılı olabilmesi için bu sık yapılan hataları tekrarlamamakta fayda var. Ayrıca çevik yöntemlerden istenen sonuç alınamıyorsa, bunun faturasını çevik yönteme kesmek yerine uygulama biçimini gözden geçirmek, doğru uygulamanın yollarını bulmak ve en iyi örnekleri incelemekte de yarar görüyorum. 

Büyük Ekipler Çevik Yöntemleri Uygulayabilir mi?

Daha önce çevik yöntemlere dönüşümle ilgili yazılar kaleme almıştık (İlgili Makaleler: Çevik Yöntemlere Yolculuk, Çevik Yöntemlere Dönüşüm). Çevik yöntemlere dönüşümde hemen herkesin aklına küçük ekiplerin bir arada çalıştığı üretken ortamlar geliyor. Dahası çevik yöntemlerin küçük firmalar ve aynı yerde çalışan ekipler için uygun olduğu düşünülüyor. Peki, büyük ekipler, farklı yerlerde çalışan takımlar ve kurumsal şirketler çevik yöntemlere geçebilir mi? Örneğin 500 çalışanı olan bir ar-ge bölümü, çevik yöntemlerle çalışabilir mi? Ya da dünya çapında 5 farklı ülkede ofisi olan bir firmada çevik yaklaşımlar uygulanabilir mi?

Ekipteki kişi sayısı arttıkça, takımlar farklı yerlerde (farklı ülke, şehir veya ofis) çalıştıkça, kurumsallık yükseldikçe çevik yöntemleri oldukları gibi uygulamak giderek zorlaşıyor. Ya kurumdaki rolleri ve süreçleri eğip bükerek çevikleştirme yoluna gidiliyor, ya da çevik yöntemleri eğip bükerek kurumlara özgü “çevik ama ...” yöntemler türetiliyor. Hangisi yapılırsa yapılsın, bir şeyler yerli yerine oturmuyor ve bir süre sonra eski alışkanlıklara dönüş eğilimi başlıyor. Bütün bunları aşarak gerçekten uygulamayı başarabilen kurumlarda ise arka planda çevik şövalyeleri diyebileceğimiz insanların olağanüstü gayretleri oluyor. Bu insanların motivasyonlarını yitirmeleri veya kurumdan ayrılmaları durumunda geçmişe dönüş hemen başlıyor.

Büyük ekiplerin çevik yöntemlerle çalışmasındaki zorluklar dünyada epeyce kafa yorulan bir alan. Buna yanıtlardan birisi son birkaç yıldır duyulan LeSS (Large Scale Scrum). Craig  Larman ve Bas Vodde’nin öncülüğü yaptığı bu yöntem Scrum’ın temel felsefesine bağlı kalarak, büyük ve çok büyük ekipler için iki farklı çatı öneriyor.  İlk çatıda 10’a kadar Scrum takımının aynı ürün üzerinde çalışabileceği bir sistematik öneriliyor. İkinci çatıda daha kalabalık ekiplerin örneğin birkaç bin kişinin çalışabileceği bir yapı sunuluyor. Her iki çatıda da tek bir Ürün Sahibi (Product Owner), tek Ürün İş Listesi (Product Backlog) ve sabit süreli Sprintler yer alıyor. Scrum’in temel prensipleri korunmak kaydıyla birinci çatının bildiğimiz Scrum’dan farklı olduğu noktalar:

•  Sprint planlamanın iki aşamalı olması: İlkine her takımdan ikişer kişinin katılıyor ve ürün sahibi ile birlikte hangi takımın hangi işi seçeceği konuşuluyor. Burada kritik nokta takımların farklı yazılım katmanlarında uzmanlaşmış olmak yerine uçtan uca geliştirme yapabilecek şekilde oluşturulmuş olması bekleniyor. Bu sayede bütün takımlar gözle görülür çıktılar üreterek demo yapabiliyorlar. İkincisini ise takımlar kendi içlerinde yapıyorlar, farklı takımlardan kişiler diğer takımlardaki planlamayı izlemek isterlerse kapılar sonuna kadar açılıyor.
•  Günlük Toplantılar, Scrum’la aynı olmakla birlikte takımlar birbirlerinin toplantılarını izleyebiliyorlar.
• Takımlar-arası Koordinasyon Toplantıları: haftada en az bir kez, SoS (Scrum of Scrums) ya da benzeri bir toplantı ile takımların birbirlerindeki gelişmelerden haberdar olması sağlanıyor.
• İş Listesi Sadeleştirme (Product Backlog Refinement) toplantıları da iki aşamalı yani takımlararası ve takım içi olarak yapılıyor.
• Sprint Gözden Geçirme (Sprint Review) ise tüm takımların katıldığı ve daha çok bir teknoloji fuarı havasında geçen, tüm takımların kendi demolarını yapabileceği bir ortamda gerçekleştiriliyor.
• Retrospektifler (İlgili Makale: Çevik Yöntemlerde Retrospektif) de yine iki aşamalı olarak yapılıyor.

İkinci çatıda ise bir ürün sahibinin tüm takımlara yetişemeyeceği ve ofislerin farklı yerlerde olabileceği varsayımıyla Yerel Ürün Sahipleri (Local Product Owner) görev yapıyor. Ürün İş Listesi tek olduğu için takımların çalışmaları tek yerden takip edilebiliyor. Toplantı ve iş akışları ise yukarıdaki yaklaşıma uygun gerçekleşiyor.

Büyük ölçekli ekiplerin uyumlu çalışmasındaki temel konu koordinasyonun sağlıklı yapılabilmesi. Bu amaçla LeSS içinde alttaki yaklaşımlar öneriliyor:

• Devamlı ve kesintisiz entegrasyon
• Takımların tamamına açık kodlar ve standart kodlama yaklaşımı
• Uçtan uca geliştirme yapabilen dikey takımların kurulması
• Pratik Toplulukları (Communities of Practice) ile takımlar arası mimari, standartlar, kullanıcı deneyimi gibi konuların yönetimi
• Takımların yönettiği yazılım derleme sistemi
• Ve tabi ki daha fazla iletişim ve konuşma :)

Biz birinci çatıyı 4 takımla İzmir ve Ankara'da kullanıyoruz. Tek Ürün İş Listesi ve tek Ürün Sahibi'nin bu 4 takımı beslediği bir yapı kurduk. Haftalık SoS de yaparak iletişimi artırmaya gayret ediyoruz. Sprint sonu gözden geçirmelerini her takımın sunum ve demo yaptığı çalıştaylar olarak bir araya gelerek yapıyoruz. Kodlama standartları ve uçtan uca geliştirme yapabilen dikey takımların oldukça yararlı olduğunu gözlüyoruz. 10 ayımızı tamamladık. Özellikle büyük ekipler ve farklı şehirlerde yer alan takımlar için yararlı olabileceğini düşünüyoruz.

Kaynakça:

1. less.works
2. Larman C., Vodde B., 2013 Scaling Agile Development, CrossTalk.
3. Larman C., Vodde B., 2010 Practices for Scaling Lean & Agile Development, Addison-Wesley.

Çevik Yöntemler ve Teknik Mükemmellik

Önceki yazılarımızda çevik yöntemlerde roller (İlgili Makaleler: Roller, Rollere Uygun Profiller, Liderlik), çevik yöntemlere geçiş (İlgili Makaleler: Dönüşüm, Uygulayabilmek) ve diğer önemli başlıklara (İlgili Makaleler: Başarının Anahtarları, Toplantılar, Güven, Analiz, Test Yönetimi) temas etmiştik. Çevik yöntemlere geçen birçok ekip öncelikle rollere, proje yönetim prensiplerine, toplantılara, dokümanlara ve iş listelerine odaklanıyor. Roller benimsenip, proje yapıları ve toplantı rutinleri oturunca, dokümanlar sadeleştirilip iş listeleri de işler hale geldiğinde çevik dönüşümün tamamlandığı gibi bir yanılsama ortaya çıkıyor. Eğer bir de bu adımlar üretim hızını artırırsa çevik dönüşümle istenen sonucun alındığı düşünülüyor. Üretim hızı kadar yapılan işin teknik yönden sağlam ve aynı zamanda esnek olması gereklliliği genelde göz ardı ediliyor. Sağlamlığı ve esnekliği de bünyesinde barındıran “Teknik Mükemmellik” kavramı hak ettiği yeri alamıyor. Bu yazımızda Çevik Manifesto’nun ardındanki 12 prensipten biri olan Teknik Mükemmellik başlığını ele alacağız.

Bu prensip çevik manifestoda tam olarak şu şekilde ifade ediliyor: “Continuous attention to technical excellence and good design enhances agility”, türkçesi “Teknik mükemmellik ve iyi tasarım konusundaki sürekli özen/dikkat çevikliği artırır.” Bu prensibi sondan başa doğru ele almakta yarar görüyorum. Öncelikle sürekli özene değinmek istiyorum. Hepimizin bildiği üzere çevik dünyada hep bir adım ileri gitme ve gelişimi sürekli kılma ön planda yer alıyor. Hatta bu gelişimi takımın kendi dinamikleri içinde başarabilmesi bekleniyor. Retrospektiflerin (İlgili Makale: Retrospektif) amacı tam da  bu gelişimi devamlı kılmak, hep bir adım ileriye gidebilmek. Tüm başlıklarda olduğu gibi tasarım ve teknik çerçevedeki ilerleme konusundaki sürekli özen de teşvik ediliyor. Hep daha iyisinin olabileceği düşünülüyor, hep bir adım ötesi hedefleniyor.

Teknik Mükemmellik kavramı ile genelde iyi tasarım birbiriyle özdeşleştiriliyor. İyi tasarım bu prensipteki hedeflerden bir tanesi. Bununla birlikte prensipte Teknik Mükemmellik özellikle ve ilk başta ifade ediliyor. İyi tasarım, Teknik Mükemmellik için gerekli ama tek başına yeterli değil. Çok iyi bir tasarım yaptıktan sonra bunu nasıl gerçekleştirdiğiniz ve nasıl test ettiğiniz de bir o kadar önemli. Tasarımı hayata geçirirken hangi alt parçalara ayırdığınız, bu parçaları hangi sıra ile ele aldığınız, aralarındaki bağımlılıkları nasıl yönettiğiniz,  her birini nasıl gerçekleştirdiğiniz, birim testini nasıl yaptığınız, nasıl entegre ettiğiniz, oluşan son ürünü nasıl kontrol ettiğiniz; bütün bunlar üretilen son çıktının kalitesine etki edecektir ve dolayısıyla Teknik Mükemmellik konusudur. Son ürünün kalitesini artıracak, sağlamlık ve esneklik getirecek tüm aksiyonlar Teknik Mükemmellik içinde değerlendirilebilir.

Teknik Mükemmellik için önemli bir adımı da ölçme ve değerlendirme oluşturuyor. Çevik dünyaya yolculuğa çıkarken teknik olarak kurumun bulunduğu durumun fotoğrafını çekmek, hangi noktalarda zayıflıklar olduğunu tespit etmek ve öncelikle bunlara odaklanmak önem taşıyor. Ayrıca çevik yöntemlerle ilerlerken teknik yönden gelişimin izlenmesi ve hedeften ne kadar uzakta olunduğunun tespit edilmesi de gerekiyor. Teknik seviyenin belirlenmesini metrik ölçümlere dayandırmak ve subjektif değerlendirmelere engel olmak da gelişimin daha şeffaf izlenebilmesini sağlıyor. Bu sayede doğru değerlendirmeler yapmak ve isabetli adımlar atarak Teknik Mükemmelik yolunda gelişimi sürdürmek mümkün olabiliyor.

Çevik dünyada teknik pratikler ve iyi uygulamalar söz konusu olduğunda eXtreme Programming (İlgili Makale: XP) ve Test Güdümlü Geliştirme  (İlgili Makale: TDD) gibi teknik yaklaşımlar ön plana çıkıyor. Bunların Teknik Mükemmeliyete önemli katkıları olduğu şüphe götürmez. Bunların dışında kurumunuza özgü ihtiyaçlar için farklı yaklaşımların da benimsenmesi mümkün. Hangi yaklaşım benimsenirse benimsensin önemli olan onu takımların özümsemesini sağlamak ve kalıcı hale getirebilmek. Dahası sürekli özenle Teknik Mükemmelliği ön planda tutabilmek. Unutmamak gerekiyor ki, çevik yöntemler bürokrasiyi azaltıp, işleri daha kolay yapabilmek için zemin hazırlarken, takımlardan daha kararlı ve daha kaliteli ürünler bekliyor.

Çevik Yöntemlere Yolculuk

Proje Yönetim Dünyası Dergisi'nin Ağustos sayısında yayınlanan yazımı altta sizlerle paylaşıyorum. 

Son yıllarda çokça duyulan ve popüler olan yaklaşımlardan biri de çevik yöntemler (agile methodologies). Çevik yöntemler aslında ihtiyaçtan ortaya çıkıyor. Büyük harcamalara rağmen istenen sonucun alınamadığı; bürokrasinin ve hiyerarişinin işleri yavaşlattığı; müşterinin yeterince önemsenmediği; ciltlerle dokümantasyona rağmen son ürünün çalışmadığı projeler bu ihtiyacı doğuruyor. Kökleri 1950'lere dayanan bu yaklaşım 1960'larda 1-2 haftalık iterasyonlar ve kısmi çözümlerle hızlı sonuçlar alınması şeklinde uygulanmaya başlıyor. 1980'lerde Hirotaka Takeuchi ve Ikujiro Nonaka isimli iki Japon bilim insanı yayınladıkları makale ile Scrum yönteminin temelini atıyorlar. Burada rugby oyunundaki toplu hücum toplu savunma anlayışından esinlenilerek takım olarak tüm işin sahiplenilmesi ve yapılması temel felsefeyi oluşturuyor. 1990'larda XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), Scrum, FDD (Feature Driven Development), Crystal, LSD (Lean Software Development), Kanban ve benzeri yöntemler ortaya çıkarak çeşitli projelerde kullanılmaya başlıyorlar. Her ne kadar isimleri ve detayları farklı olsa da temel prensipleri aynı olan bu yöntemlerin temsilcisi 17 kişi, 2001 yılında bir araya gelerek ünlü Çevik Manifesto ile ortak paydalarını ilan ediyorlar. Çevik Manifesto özetle:

• süreçler ve araçlardan ziyade bireyler ve etkileşimlere 
• kapsamlı dökümantasyondan ziyade çalışan yazılıma 
• sözleşme ve pazarlıklarından ziyade müşteri ile işbirliğine 
• bir plana bağlı kalmaktan ziyade değişime karşılık vermeye 

değer verilmesini salık veriyor. 

Çevik yöntemler yazılım ve bilişim projelerinde özellikle 2000’li yıllarla birlikte dünya genelinde oldukça yaygınlaşıyor. Ülkemizde de yaygınlaşma ivmesi 2010’dan sonra gözle görünür biçimde artıyor. Birçok büyük kurum ve kuruluş çevik yöntemlere geçişi başlattı veya planlıyor. Her ne kadar yazılım projelerinde yaygın olsa da çevik yaklaşımlar ve sağladığı yararlar aslında tüm ürünlere ve projelere uyarlanabilir. Bu sebeple çevik yöntemlere yolculuğu da geniş perspektiften ele alıyoruz.

Çevik yöntemlere yolculuk esas itibariyle işe, ekibe ve müşteriye bakış açısını değiştirmeyi gerektiriyor. İşi, ürün perspektifinden ve bütünsel ele almayı, kısa aralıklarla yeni kabiliyetler eklemeyi ve çalışan ürünü temel başarı göstergesi olarak görmeyi gerektiriyor. Ekibi takıma dönüştürmeyi, takıma güvenmeyi, takımın kendini organize edebilmesini, hiyerarşinin ortadan kalkmasını, kollektif sahiplenmeyi ve sorumluluğu gerektiyor. Müşterinin masanın karşısından kalkıp proje takımının yanına oturmasını, proje çalışmalarına dahil olmasını, geri bildirimlerini hemen verebilmesini, değişiklik taleplerini proje boyunca iletebilmesini mümkün kılıyor. Bu paradigma değişikliklerini üst yönetime, müşteriye ve tüm proje paydaşlarına benimsetmek çevik yöntemlerle sağlanacak başarının anahtarı oluyor. 

Çevik yöntemlerle birlikte projeye bakış açısının da değişmesi gerekiyor. Birçoğumuzun bildiği proje başarı üçgeninde köşelerde takvim, maliyet ve kapsamın olduğu; ortada kalitenin yer aldığı varsayılıyor. Takvim, maliyet ve kapsamın plana uygun gerçekleşmesinin projenin temel başarı kriterleri olduğu belirtiliyor. Gerçek hayatta ise genellikle hedeflenen kapsama erişebilmek için takvimin ve maliyetin aşıldığı, kaliteden de çoğu zaman tavizler verildiği bulgulanıyor. Bu gerçeklik karşısında çevik yöntemler, kapsamın serbest bırakılmasını, takvim ve maliyetin sabit olmasını, kaliteden ise taviz verilmemesini tercih ediyor. Elbette kapsamın serbest bırakılması kontrolsüz gerçekleşmiyor. Bilakis kapsam yönetimi Ürün İş Listesi (Product Backlog) ile yakından takip ediliyor, projedeki tüm gereksinimler bu listeye ekleniyor. Listedeki öncelikli gereksinimleri yapmak ve proje tamamlandığı noktada geriye önceliği düşük işlerin kalması temel yaklaşımı oluşturuyor. Müşterinin, Ürün İş Listesi’ne proje boyunca yeni gereksinimlerini eklemesine izin veriliyor. Bu sayede kapsam değişikliklerine fırsat tanınıyor. Gereksinimlerin önceliğini de müşteri belirliyor ve istediği noktada değiştirebiliyor. Bunun tek istisnası proje takımının üzerinde çalıştığı iş paketleri, bunlara dokunamıyor. Proje bittiği noktada, Ürün İş Listesi içinde kalan gereksinimler müşteri tarafından önceliği diğerlerine düşük olarak belirlendiği için, müşteri nezdinde de soruna yol açmıyor.

Çevik yöntemlere geçişle birlikte takımların çalışma prensipleri de değişiyor. Öncelikle takımın projeye dedike olması, başka iş ve projelerde görevlendirilmemesi gerekiyor. Burada temel gerekçe insanın bir tek konuya odaklandığında daha kaliteli ve hızlı üretebilmesi. Bunun arkasındaki sebep de insanoğlunun çoklu düşünme kabiliyetine sahip olmaması, aynı anda çok şeyi düşündüğümüzü sandığımız anlarda bile beynimizin düşünceleri teker teker ancak aralarında çok kısa aralıklar bırakarak işleme aldığı, bunun bize aynı anda çok şeyi düşünüyormuş yanılgısı yarattığı gerçeği.

Takımla ilgili ikinci önemli konu, aynı yerde birlikte çalışma, yüzyüze iletişim kurma şeklinde karşımıza çıkıyor. Mümkünse proje için ayrılmış bir odada, Takım Odası’nda tüm takımın birlikte çalışması, ekibin takıma dönüşebilmesi için büyük önem taşıyor. Takım Odası’nda projeye, ürüne ve gereksinimlere ait durumların rahat izlenebilmesi için duvarlara birşeyler asılması da ürüne odaklanmaya önemli katkı sağlıyor. Takım Odası’nda müşteri tarafından karar verebilecek bir kişinin de takımla çalışması ayrıca katkı sağlıyor. Bunun yapılamadığı durumlarda en azından müşteri ile sık aralıklarla bir araya gelmek ve yapılan çalışmaların gösterilmesini sağlamak yarar sağlıyor.

Takımla ilgili üçüncü konu işlerin planlanmasındaki ve paylaşılmasındaki değişiklik olarak kendini gösteriyor. Çalışmaları artırımlı iterasyonlar olarak planlamak, iterasyonlar sonunda müşteriye değerli ve çalışan bir teslimat sunmak hedefleniyor. İterasyonlarda kabaca nelerin yapılacağı, başta planlansa da tam olarak Ürün İş Listesi’nden hangi gereksinimlerin yapılacağına iterasyon başında takım olarak karar veriliyor. Seçilen gereksinimlerin müşteri tarafından en öncelikli olarak belirlenenlerden oluşması gerekiyor. Bu sayede müşteri için en değerli olan çalışmalara öncelik verilmiş oluyor. Takım üyeleri gereksinimler veya onlarla ilgili alt aktiviteleri kendi üzerlerine alarak paylaşıyorlar. Kimse iş ataması yapmıyor. Bu sayede bireysel sorumluluk ve takım içi güven teşvik ediliyor.

Takımla ilgili dördüncü konu rollerdeki farklılıklar olarak karşımıza çıkıyor. Üç temel rol, Ürün Sahibi (Product Owner), Çevik Proje Yöneticisi (Agile PM), Geliştirme Takımı (Develoment Team) olarak uygulanıyor. Bu rollerin farklı çevik yaklaşımlarda farklı isimleri de olabiliyor. Takım içinde farklı yetkinliklerde insanlar olması teşvik ediliyor. Bununla birlikte takım içinde yönetici veya hiyerarşi taşıyan rollere sıcak bakılmıyor. Bunun takım ruhunu örseleyeceği düşünülüyor.

Yukarıda temel bazı noktalarına değindiğimiz çevik yöntemlere yolculukta, aslında en önemli konu bakış açısını değiştirmek, farklı düşünebilmek. Buna paralel olarak Kuantum Kuramı’nı geliştiren ünlü bilim adamı Max Planck, “bakış açımızı değiştirdiğimiz zaman gördüğümüz şeylerin de değişeceğini” söylüyor. Bakış açısını değiştirmenin ilk ve en temel adımı çevik yöntemlere geçiş için gereken paradigma değişikliğine istekli olunması. Dahası bu yolculuğu sürdürebilmek için azim ve kararlılık gerektiğinin de altını çizmemiz gerekiyor.

Kaynakça:

Adkins L. (2010) Coaching Agile Teams, Addison-Wesley.

Shore J. ve Warden S. (2008) The Art of Agile Development, O’Reilly Press.

Sliger M. ve Broderick S. (2008) The Software Project Manager’s Bridge to Agility, Addison-Wesley.

http://www.yeniprojeyonetimi.blogspot.com

Çevik Yöntemlere Dönüşüm

Çevik yöntemleri son dönemde sıkça duyuyorsunuz, hatta etrafınızdaki şirketlerden dönüşüm yapanları veya deneyenleri görüyorsunuz. Çevik yöntemlerin kendi kurumunuza da faydalı olacağını düşünüyorsunuz, ancak endişeleriniz var. Aklınızda sorular uçuşuyor:

•  “Dönüşüme nereden başlamalıyım?”
• “Neleri değiştirmeliyim?”
• “Kimleri dahil etmeliyim?”
• “Nasıl yaygınlaştırmalıyım?”
• “Eski alışkanlıklara dönüşü nasıl engellemeliyim? Dönüşümü nasıl kalıcı hale getirebilirim?”
• “Nerede durmalıyım?”
• “Sözde çevik noktasında kalır mıyım?”“Özde çevik olabilecek miyim?”
• “Dönüşümün faydasını ne zaman görürüm?”

Çevik yöntemlere dönüşüm genellikle “hızlı kod yazmaya” başlamak olarak algılanıyor ve IT ekipleri ile sınırlı kalıyor. Özellikle üst yönetim, müşteri ve diğer paydaşlara yeterince anlatılmadığı için yeterince anlaşılamıyor.Dolayısıyla destek alamadığı ve istenen sonuçların ortaya çıkmadığı durumlara çok sık rastlanıyor. Halbuki dönüşüm için müşteri ve üst yönetimin tam desteği olmazsa olmaz. Onlara nelerin nasıl değişeceğini ve sonuçlarının nasıl olacağını anlatmak ve de tam desteklerini almak dönüşümün ilk adımlarından birisi olmalı.

Dönüşümler genellikle kurum çapında geniş katılımlı eğitimlerle başlıyor, eğitimlerde ideal yapılar anlatılıyor. Eğitimden sonra insanlar çevik yaklaşımları beğeniyorlar ancak kendi çalışmalarına nasıl uygulayabileceklerini göremiyorlar. Aradan zaman geçince ve uygulama fırsatı bulamayınca eğitimdeki bilgileri de unutuyorlar.Her ekibin farklı dönüşüm deneyimi oluyor. Kimi tam dönüşemeden iki arada bir derede kalıyor. Yöntemlerini anlatırken de şöyle cümleler kullanıyorlar “çevik ama...”. 

Okuduklarımdan, gözlemlediklerimden ve deneyimlerimden derlediğim birkaç dönüşüm tavsiyesine bu yazıda yer vermek isterim:

• Çevik yöntemlere dönüşümün de bir proje olması ve hatta çevik bir proje olması. Dönüşüm için bir takım kurulması ve yaşayan bir iş listesi (product backlog) oluşturulması.
• Uygulamanın pilot ekiplerle başlatılması ve kademeli olarak yaygınlaştırılması.
• Çevik yöntemlerdeki rollerin iyi anlatılması ve doğru role doğru kişinin getirilmesi (İlgili Makale:Çevik Yöntemlerdeki Rollere Uygun Profiller).
• Planlanan eğitimlerin iki aşamalı olması. İlk aşamada genel çevik yöntemleri içeren bir program, ikinci aşamada ise kurumdaki çevik uygulamanın nasıl olacağının anlatıldığı bir program. Pilot seçilen ekiplerin iki eğitimi de alması ve ardından ekibe dahil edilecek koç ile uygulamanın başlatılması.
•  Farklı takımların deneyimlerini birbiri ile paylaşabilmesi için ortamlar yaratılması.
•  Retrospektiflerin mutlaka etkin yapılması, ekiplerin de gelişim fırsatlarını görmelerinin sağlanması (İlgili Makale:Çevik Yöntemlerde Retrospektif).
•  Tüm ekiplerin çevik yöntemlere geçişinin zorlanmaması. İsteyen, gönüllü olan, müşterileri ve işleri uygun olan takımlardan başlanması süreci kolaylaştırabilir.
• Sabırlı olunması, dönüşümün en az 2 yıla yayılması. Özellikle verimliliğin artması, üretim hızının yükselmesi için acele edilmemesi gerekiyor.
•  Dönüştükten sonra durulmaması, çevik yöntemleri daha etkin kullanabilmenin yollarının araştırılması. Bu noktada Kai-zen felsefesi ve bu felsefede olan “mükemmel yoktur, daha iyisi vardır” yaklaşımı benimsenebilir.

Bunlardan başka  önemli noktalar da muhakkak var. Bence en önemli olan zorlukları görünce pes etmemek, dönüşüme azimle devam etmek ve de gerçekten uygulayabilmek (İlgili Makale:Çevik Yöntemleri Uygulayabilmek).

Savuşturmacı Kültür

Alttaki türden yanıtları sıkça duyuyor musunuz?

• “Bakarız”
• “Sonra yapalım”
•  “Daha zaman var”
• “Daha acil işler var”
•  “Yönetime sormak lazım”
•  “Bu konudan ben sorumlu değilim”
• "Buna ne gerek var”

Bu liste uzayıp gidebilir. Bu yanıtları alınca içinizden ne geçiyor, ne düşünüyosunuz? Karşımızdakinin bir şeyi yapabilecekken yapmadığını, işten kaçındığını veya ötelediğini, değil mi? Hatta bazen karşımızdakinin zamanının olduğunu, yetkisinin uygun olduğunu ve dahası kendi işi olduğunu bilsek bile bu yanıtı alıp şaşırdığımız oluyor. O kadar yaygın ki aile içi ilişkilerde, arkadaşlar arasında bile bu durumlara çok sık rastlanıyor. Esas itibariyle hem iş hayatında hem de günlük hayatımızda çokça karşılaştığımız durumlar bunlar. Literatürde tarayabildiğim kadarıyla bir sınıflamasını bulamadım ve Savuşturmacı Kültür adınının uygun olabileceğini düşündüm. Eğer bir yerde geçiyorsa ve atlamışsam kusura bakmayın ve lütfen beni de bilgilendirin.

Savuşturmacı Kültür’ün iki stratejisinin olduğunu düşünüyorum, ilki yukarıda örneklerini vermeye çalıştığım, “işi yapmama veya öteleme”, ikincisi ise “yapılmış gibi, olmuş gibi, doğruymuş gibi gösterme”. İkinci stratejide işle veya durumla ilgili sorulara gerçek dışı yanıtlar verme, olduğundan farklı ve iyi gösterecek bilgilendirmeler yapma esastır. Bir çalışanınıza işin durumunu sorduğunuzda aldığınız şu tür yanıtlar bu duruma örnek gösterilebilir:

•  “Bitmek üzere”
•  “Sorun yok”
•  “Risk yok
•  “Hallediyoruz”
•  “Yetişir”

Bu güzel bilgilendirmeler sonunda yönetici konumundaysanız içinize su serpilir, rahatlarsınız. Ama işin aslı öyle değildir ve nitekim işin sonunda beklenen sonuç ortaya çıkmaz, sorun olduğu da ancak duvara çarptıktan sonra ortaya çıkar.

 

İşin bitmemesi, gecikmesi veya hatalı olması durumunda da iyi bir bahane bulunması veya günah keçisi tespit edilip tüm sorumluluğun ona yüklenmesi  Savuşturmacı Kültür’ün tamamlayıcı savunma stratejisidir. Hatta çalışma boyunca “işi nasıl iyi ve zamanında yaparım?” sorusu değil “nasıl ikna edici bir bahane bulurum?”, “başarısızlığın sorumluluğunu neye bağlayabilirim?”,“kimi günah keçisi yapabilirim?” türünde sorular da zihinleri meşgul eder. İşin sonunda sorunun kaynağını sorduğunuzda hep başka birisi hatalıdır veya başka bir kurum işini iyi yapmamıştır.

Bir kurumda Savuşturmacı Kültür ne kadar hakimse verimlilik ve etkinlik o kadar düşüktür. Kuruma sonradan katılanlar da ister istemez bu kültürün etki alanına girerler. Kimsenin iş yapmak istemediği, bunu da farklı bahanelerin arkasına saklanarak dolaylı dile getirdiği bir ortam oluşur. Yürüyen işler gereği gibi şeffaf raporlanmaz, tüm işlerin sorunsuz ilerlediği yanılgısı oluşturulur. Bu sorunsuz(!) işlerin sonuçlarındaki başarısızlıklar da hep başka bir etkene bağlanır veya yanlış kişilere fatura kesilir. Başarısızlığın sebeplerinin yanlış teşhis edilmesi sonucu ortaya çıkar ve yanlış tedaviler uygulanır. Bu tedavilerde istenen sonuçlar alınamaz ancak Savuşturmacı Kültür bu noktada da devreye girerek kök sebebe inilmesine izin vermez.

Bir çok kurumda Savuşturmacı Kültür’ün hakimiyeti bulunuyor ve maalesef farkına varılamıyor. Savuşturmacı Kültür’ün panzehirinin alttaki adımlardan geçtiğini düşünüyorum:

• Bahane üretme yerine Sorumluluk Alma: İşin yapılmaması için bahane üreten kişilerin teşvik edilmediği; sorumluluk alarak işleri yapma motivasyonu taşıyan kişilerin ödüllendirildiği bir çalışma ortamının oluşturulması.
• Yanlış raporlamalar ve manipülasyon yerine Şeffaflık: Yanlış, eksik veya yanlı raporlamaların, bilgilendirmelerin kabul edilmediği; sorunların/risklerin tespit edildiği anda şeffaf olarak aktarıldığı durumların kabul gördüğü iletişim ortamının sağlanması.
• Başkasını suçlama yerine Özeleştiri Yapabilme: Hatayı hep dışarıda aramanın, başkalarını suçlamanın uygun bulunmadığı; iğneyi kendine de batırmanın öneminin vurgulandığı özeleştiri alışkanlığının kazandırılması.

Çevik Yöntemlerdeki Rollere Uygun Profiller

Çevik yöntemlerdeki rollerden daha önce bahsetmiştik (İlgili Makale: Çevik Yöntemlerde Roller). Bu rollere uygun profiller neler? Kim hangi role daha uygun? Ürün Sahibi ve Çevik Proje Yöneticisi rollerinin altından kim kalkabilir? Herkes Geliştirme Takımı'nda yer alabilir mi? Bu yazıda bunlara değineceğiz.

• Geliştirme Geliştirme Takımı Üyesi Profili:

• Temel Çevik Yöntem Bilgisi: Çevik yöntemlerin bütün süreçlerini bilmesinde fayda var, ancak uzman seviyesinde olması beklenmiyor.
• İşbirliğine Yatkın ve Uyumlu: Takım içinde birlikte çalışmaya yatkın, takımın kalanı ile uyumlu ve ılımlı geçinebilmesi takımın ahengi için olmazsa olmaz bir özellik.
• Organize: Kendini organize edebilen bir takım kurabilmek için kişilerin de işlerini organize yürütebilmesi ve başkalarının arkalarını toplamasını beklememeleri gerekiyor.
• Pro-aktif: Harekete geçmek için bir sorun/engel oluşmasını beklemeyen veya motivasyon için başkasına ihtiyaç duymayan kişilikte olması gerekiyor.
• Yeterli Teknik Uzmanlık:  Çevik yöntemlerde teknik mükemmeliyet ön planda tutuluyor.  Hem sağlam ve esnek tasarım hem de hızlı üretim için teknik yeterlilik en temel ihtiyaç. Uzmanlık bazen hafife alınan bir kavram ne yazık ki. Bir konuda uzman olabilmek için o konuda yeterli bilgi ve tecrübe sahibi, konuyu farklı yönleriyle incelemiş, alternatifleri bilen, derinlemesine bilgi sahibi bir profilden bahsediyoruz.  Uzmanın sadece yapabilen değil, aynı zamanda en iyisini yapabilen olması gerekiyor.
• Takım oyuncusu: Çevik yöntemlerde bireysel başarıdan ziyade takım başarısı ön planda, tıpkı spor müsabakaları gibi takımın başarılı olmadığı durumlarda bireysel başarıdan da söz etmek mümkün değil. Dolayısıyla iyi takım oyuncusu olan profiller çevik yöntemlere daha yatkın olacaktır.
• Sorumluluk sahibi: Çevik yöntemlerde kimse takım üyelerine iş atamıyor, bilakis kendileri iş listesinden yapabileceklerini seçip sorumlu olduklarını o iterasyonda tamamlamaya çalışıyorlar. Dolayısıyla her takım üyesinin sorumluluk sahibi olması çok önemli.

• Ürün Sahibi Profili:
• Çevik Yöntem Uzmanı: Çevik yöntemleri iyi bilen, hem kendi hem de takımın sorumluluklarına hakim olması çalışmayı ve ürünü doğru yönlendirmede oldukça önemli. Ürün vizyonuna nasıl ulaşılacağını çevik yöntemlerin sağladığı yollarla belirlemesi gerekiyor.
• İş Alanı Uzmanı: İlgili ürünün iş modelini yapısını çok iyi bilmesi, rakipleri tanıması gerekiyor. Müşteriler ile teması olması ve onların hedeflerine de aşina olması elzem.
• İletişim ve Müzakere Becerileri: Hem müşteri hem de geliştirme takımı ile yapacağı görüşmelerde iletişim becerilerine çok ihtiyacı olacaktır. Gerekli noktalarda müzakere yapabilmesi de ihtiyaçlardan bir diğeri. 
• Pro-aktif: Tıpkı geliştirme takımı üyeleri gibi harekete geçmek için bir sorun/engel oluşmasını beklemeyen veya motivasyon için başkasına ihtiyaç duymayan kişilikte olması gerekiyor.
• Karar Verici: Ürünü doğru yönlendirebilmek doğru ve hızlı karar verebilmek bir diğer ihtiyaç duyulan özellik. Karar verirken alternatifleri görebilen ve en faydalıyı seçen bir yaklaşıma ihtiyaç duyuluyor. 
• Pragmatik: Yaptığı çalışmalarda ürünün faydasını ön planda tutan, vizyona katkısını takip eden bir yaklaşıma her zaman ihtiyaç olacaktır.

• Çevik Proje Yöneticisi:
• Çevik Yöntem Uzmanı: Çevik yöntemleri iyi bilen, hem kendi hem de takımın sorumluluklarına hakim olması çalışmayı doğru yönlendirmede oldukça önemli.
• Hizmet Eden Liderlik: Bu çok önemli bir kavram. Klasik yönetim tarzındaki iş ver-takip et (command and control) veya direktif verici liderlik anlayışları çevik yöntemlerde istenmiyor. Bunun yerine koçluk edebilen, takımın önünü açan liderlik anlayışı ön planda tutuluyor. Takımın zaten ne yapması gerektiğini bildiği, yöneticinin detaylara karışmasına gerek olmadığı farz ediliyor.
• Problem Çözme Becerileri: Takım içinde veya takımla paydaşlar arasındaki  iletişim kazalarında devreye girebilmesi bekleniyor. Ayrıca takımın getireceği farklı problemlerde doğru çözüme ulaşılmasını sağlaması gerekiyor. Her problemi çözmesi beklenmiyor, çözümün Takım tarafından bulunmasında katalizör rolü oynaması yeterli olacaktır.
• Motivasyon Verebilen: Motivasyon çok geniş bir kavram, burada beklenti takımın çalışma boyunca motivasyonunu koruyabilmesi için gerekli önlemleri alabilmesi.
• Koçluk Yapabilen: Takıma hizmet eden liderlik çerçevesinde yöneticilikten ziyade koçluk yapması ve takım üyelerinin gelişimini sağlaması oldukça önemli. Koçluk da geniş bir kavram.
• Erişilebilir, Konuşması Kolay: İletişim becerilerinin iyi olmasının yanında, takımın rahatlıkla ulaşabildiği, konuşmaktan çekinmeyeceği bir mizaçta olması çok fayda sağlayacaktır.

Yukarıdakilere farklı özellikler de eklemek mümkün. Öte yandan bu profillerde çalışan bulmak kolay değil; bulunup bir araya getirilince mayanın tutacağının yani takım olunacağının garantisi de bulunmuyor. Bu konuda üst yönetimin desteği ve insan kaynakları politikalarının gözden geçirilmesi ile Takım Olmanın değerli kılınması kuşkusuz çok önemli. Takım olabilmek için de güven sağlanması ilk ve en önemli adım (İlgili Makale: Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği). Kişisel görüşüm bireysel başarıları destekleyen günümüz iş dünyasının zamanla değişeceği ve takım başarılarını ön plana çıkaran yaklaşımların er geç benimseneceği...

Çevik Yöntemlerde Roller

Çevik Yöntemleri farklı boyutları ile daha önce ele almıştık (İlgili Makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi, Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde Test Yönetimi, Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği, Çevik Yöntemlerde Toplantılar). Bu yazıda rollerine değinmek istiyorum. Çevik Yöntemlerle çalışan takımlarda bildiğimiz hiyerarşik ve sorumlulukların çok net ayrıştırıldığı roller bulunmuyor. Bunun yerine daha az sayıda kişiden oluşan ve kendini organize edebilen takımlar kuruluyor. Farklı Çevik Yöntemlerde isimleri farklı olsa da benzer özellikler içeren alttaki temel roller mutlaka yer alıyor:

• Müşteri Temsilcisi veya Ürün Sahibi (Product Owner): Ürünü tarif eden, öncelikleri belirleyen ve yapılanları değerlendiren kişi. Ürün Sahibi'nin özellikleri:
• 1 kişi
• Müşteri ve diğer paydaşlarla iletişim
• 'Ne’ sorusuna odaklı
• İş maddelerinde son karar verici
• Ürün İş Listesi yönetimi ve önceliklendirilmesi
• Ürün vizyonunu belirlenmesi
• İterasyon sonunda ürün ve/veya özelliklik kabulü
• Yapılan işin ekonomikliği (ROI) takibi
• Geliştirme Takımı (Development Team): Farklı becerileri
  olan kişilerden oluşan, yazılımı, entegrasyonu ve birim testi yapabilen takım. Kimseden talimat beklemeden işlerini planlayıp ilerleyebilen, destek gereken noktaları ayırt edip eskale edebilme becerisine sahip. Geliştirme Takımı'nın özellikleri:
• 4-9 kişi
• Belirlenen kalite standartlarına uyulması
• ‘Nasıl’ sorusuna odaklı
• İterasyona alınacak işlerin seçilmesi ve gerçekleştirilmesi
• Kendini organize edebilir
• Farklı yetkinlikler içerebilir
• Çevik Proje Yöneticisi (Agile Project Manager): Takımın önünü açan, işin detaylarını
  yönetmeye çalışmayan lider kişi. Bildiğimiz Proje Yöneticisi işlevlerini yapmıyor. Örneğin zaman, kapsam, takvim ve kalite yönetiminden sorumlu değil. Çevik Proje Yöneticisi'nin özellikleri:
• 1 kişi
• İşlerin kolaylaştırılması
• Takıma gelebilecek dış etkilerin giderilmesi
• Takımın önündeki engellerin kaldırılması
• Müşteri ve diğer paydaşlarla iletişim
• Sürecin doğru işletilmesine odaklı
• Takıma hizmet eden liderlik profili

Yukarıdaki rollere sahip kişiler takım olarak çalıştıkları ve başarı/başarısızlık herkese ait olduğu için klasik ekiplere kıyasla iletişim ve verimlilik anlamında fark yaratabiliyor. Bu fark için Çevik Yöntemler'e üst yönetimin de destek vermesi ve takımın önünü açması tabi ki en önemli koşul. Bir çok yönetici için bu durum çok kolay değil, çünkü ekiplerine talimat vermeleri ve işleri kontrol etmeleri Çevik Yöntemler'de pek de istenmeyen bir durum. Hatta takımların kendi içinde organize olabileceğine birçok yönetici ilk aşamada inanmıyor bile... Üst yönetimin desteğini almak içinse çoğu zaman örnek projelerle Çevik Yöntemler'in çıktılarını somut olarak göstermek en iyi ikna yöntemi oluyor. 

Çevik Yöntemlerde Toplantılar

İş hayatında toplantı yapmamış olan var mı? Bence yoktur, tüm iş ortamlarında kısa, uzun; az, çok; resmi, gayri-resmi toplantılar yapılır. Kimi zaman tüm günümüz toplantılarda geçer. Eğer yapmamız gereken başka işler varsa, toplantıya katıldığımız için keyfimiz kaçar, zaman zaman da toplantıyı düzenleyene içten içe kızarız. Hatta bir kısmımız toplantıların verimsiz ve gereksiz olduğunu düşünür. Kimi zaman da gereksiz ve detay konulara girilerek asıl amaçtan uzaklaşılır. Bazen konu uzar, istenen noktaya ulaşılamaz ve süresini aşar. Bazı rutin toplantılarda ise gündem olmasa bile toplanılır ve pek de bir sonuç alınmadan ayrılınır.

Toplantıyı niye yaparız? Fikirleri paylaşmak, bilgilenmek, bilgilendirmek, ikna etmek, ikna olmak, karar vermek... Bu amaçlara ulaşabilmek için çevik yöntemlerde de toplantı yapılır. Çevik yöntemleri daha önce farklı başlıklarda ele almıştık (İlgili Makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi, Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde Test Yönetimi, Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği). Çevik yöntemlerde çalışmaların etkin olması, gereksiz iş yapılmaması hepimizin bildiği üzere ön plandadır. Toplantılar da aynı prensiplere göre organize edilmiştir: ihtiyaç kadar, belli hedeflere dönük ve zaman sınırlı (time-boxed). Uygulanan çevik yöntemler farklı bile olsalar, temel toplantıları benzerdir ve şöyle özetlenebilir:

• Vizyon Toplantısı: Buradaki amaç, çalışmaya konu ürünle ve projeyle ilgili vizyonun konulması, bu vizyon için gidilmesi gereken yolun ana hatlarının belirlenmesidir.
• Sürüm (Release) Planlama Toplantısı: Sürüm içinde ele alınacak konuların belirlenmesi, önceliklerin değerlendirilmesi amacıyla yapılır.
• İterasyon Planlama Toplantısı: İterasyona başlarken yapılan bu toplantıda, o iterasyonda hangi işlerin, kimler tarafından yapılacağı takım olarak belirlenir. Temelde bu toplantı iki aşamalıdır. İlk bölümde "ne yapılacak" sorusuna karşılık aranır, ikinci bölümde "nasıl yapılacak" sorusuna yanıt verilir. Yarım gün veya tam gün olabilir. Süre baştan belirlenmiş olmalıdır.
• Günlük Ayaküstü (Daily Stand-up) Toplantı: 15 dakika ile sınırlı bu toplantıda, takım üyelerinin her biri kısaca "dün ne yaptım?", "bugün ne yapacağım?", "önümdeki engeller nedir?" sorularını yanıtlar. Toplantı ayaküstü ve sabah ilk iş olarak yapılır.
• İterasyon Gözden Geçirme Toplantısı: İterasyon sonunda tamamlanan çalışmaların demosunun yapılması, Müşteri veya Ürün Sahibi'nin görüşlerinin alınması amacıyla düzenlenir. Kabulü yapılan iş maddeleri kullanıma sunulmak üzere hazırlanır. Kabul edilmeyenler ise Talep Listesi'ne (Product Backlog) iade edilir.
• Retrospektifler: Hem İterasyon sonunda hem de Sürüm sonunda yapılır. Retrospektif başlığını daha önce etraflıca ele almıştık (İlgili Makale: Çevik Yöntemlerde Retrospektif).
• Talep Listesi Sadeleştirme (Product Backlog Refinement): Bu toplantıda Talep Listesi'nin üzerinden geçilerek büyük konular küçük parçalara ayrılır. İhtiyaç kalmayan talepler ayıklanır. 

Farklı çevik yöntemlerde isimler farklı olabilir. Örneğin Scrum'da iterasyonun özel adı Sprint'tir. Sprintler içindeki toplantı akışı yandaki şekilde olduğu gibi döngüseldir. Günlük Scrum Toplantısı, Sprint içinde tekrarlanır ta ki Gözden Geçirme Toplantısı'na kadar.

Tüm bu toplantılara herkes davet edilmez. Kime ihtiyaç varsa onlar davet edilir. Örneğin Retrospektifler, Takım içinde yapılır. Sürüm ve İterasyon Planlama Toplantıları'nda Ürün Sahibi, Çevik Takım olmazsa olmazdır. Çevik Proje Yöneticisi süreci takip etmek amacıyla katılır. Diğer paydaşları ihtiyaç olmadıkça toplantıya dahil etmemek verim için gereklidir. Toplantının zaman ve kapsam yönetimi konularında Çevik Proje Yöneticisi aktif rol oynar. Konuşulan içeriğe ise müdahale etmez. Dolayısıyla gereksiz detaylar ve uzayan toplantıların önüne geçilir. Toplantıların süre sınırlı olması, hedefe dönük olması, ilgisiz katılımcıların davet edilmemiş olması, hem verimi hem de toplantılarla ilgili motivasyonu arttırır.

   

Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği

Çevik yöntemlerin müşteri ve temsilcisi ile teknik ekiplerin bir arada çalışmasını beklediğini hepimiz biliyoruz. Bu temellere göre çevik bir projedesiniz ve ekiple müşteriyi bir araya getirmeyi başardınız. Eskiden kalma ön yargılar sürdüğü ve ekip kaynaşamadığı sürece yine istenen sonuca ulaşmanız mümkün olmayacaktır. Ekibin üyeleri bireysel olarak ne kadar iyi olurlarsa olsunlar, birlikte çalışamadıkları zaman başarılı olmak hayal olacaktır.  Peki nasıl birlikte çalışma ortamı yaratılabilir

Birlikte çalışabilmenin anahtarı güvendir. Güven arttıkça işbirliği artacaktır. İşbirliğinin artması demek verimliliğin artması, ekibin etkinliğinin ve hızının artması ve de işin kalitesinin yükselmesi demektir. Peki güven nasıl sağlanır?

Güven için ilk adım empatiden geçiyor. Türkçe’ye duygudaşlık olarak çevriliyor. Benim anladığım
anlamı ise kendinizi başka birisinin yerine koyabilme ve onun gözünden anlama ve hissedebilme. Özellikle projelerde farklı rollerde çalışan insanlar birbirlerinin durumunu anlamakta zorluk çekebiliyor. Eğer herhangi bir yapıcı adım da atılmazsa “biz-siz” veya “biz-diğerleri” sınıflamaları ortaya çıkıyor. Bunun sonucunda da şöyle şikayetler artıyor:

• “Biz çok çalıştık, diğerleri çalışmadı.”
• “Biz haksızlığa uğradık.”
• “Bizim dediğimiz olmalı! Yoksa kendiniz yaparsınız.”
•  “Diğerleri işini iyi yapmadığı için kalitesiz oldu.”
•  “Diğerleri hata yaptılar ondan gecikti.”
•  “Biz olmadan bu iş olmazdı.”

Biz-siz algısının en keskin olduğu noktalarda empati kurulabilmesi en çok faydayı sağlayacaktır. Peki nerelerde empati gereklidir?

İlki müşteri-programcı arasında. Müşterinin gözünde genelde  programcılar, bahaneler üreten, disiplinli çalışmayan, denileni yapmayan, çoğu zaman iyi dinlemeyen, tembel ve zaman zaman da şımarık kişiler olarak canlanıyor.  Programcılar gözünde ise genelde müşteriler, ne istediğini tam bilmeyen, devamlı fikrini değiştiren, öngörüsü yeterli olmayan, teknolojiden bihaber, şikayet etmekten memnuniyet duyan ve zaman zaman da patronluk taslayan kişiler olarak canlanıyor.

İkincisi programcı-testçi arasında. Programcı gözünde genelde testçiler, bir türlü isteneni yapamayan, en ufak zorlukta bayrak kaldıran, denileni anlamayan, katı, tembel ve genelde programcı olmayı başaramamış kişiler olarak canlanıyor. Testçiler gözünde programcılar, işi bitirmeden teste sunan, aceleci, dikkatsiz, test ekibinin zamanından kullanan ve genelde burnu havada kişiler olarak canlanıyor.

Bu ön yargıları aşıp empati oluşturabilmenin bir kaç aşaması bulunuyor:

·       İlk adım elbette bir arada çalışmaktan geçiyor. Bir arada çalışma ister istemez iletişimi artıracak ve birbirini daha iyi anlama şansı verecektir.

·       İkinci önemli adım retrospektiflerin birlikte yapılabilmesi, bu konuda daha önce bir yazım bulunuyor (İlgili Makale: Çevik Yöntemlerde Retrospektif).

·       Üçüncü önemli adım ise iki tarafın birbirine talepleri dışında projeye ilişkin yaşadıkları zorlukları ve yönetmeye çalıştıkları durumları da açık yüreklilikle anlatabilmesi. Örneğin müşterinin yeni bir talebi ortaya çıktığında bunun neden ortaya çıktığı, bunu programcının önüne getirmeden önce neler yapıldığı, nasıl basitleştirilmeye çalışıldığı da anlatılırsa programcı da durumu ve müşteriyi daha iyi anlayacağı için daha farklı yaklaşabilecektir.

·       Dördüncü adım, herkesin kendi rolüne göre hedefler konulması yerine herkesi kapsayacak proje hedefinin ön plana çıkarılması, bireysel hedeflere ulaşmanın ödüllendirmede geri plana alınmasıdır. Örneğin programcı işini iyi yapsa bile ortaya çıkan ürün başarılı olamamışsa, kendisinin de başarılı sayılamayacağının hissettirilmesi.

·       Beşinci adım, birlikte yemek. Yemeği ekibin birlikte yemesi, ekip içi iletişimde arkadaşlık imkanlarını da artıracak, birbirini anlamaya katkı yapacaktır. Ne sıklıkla olacağına ekiple karar vermek en sağlıklısı olacaktır.

·       Altıncı adım, ekip devamlılığı. Eskiden İnsan Kaynakları politikaları personel devamlılığını sağlamak üzere optimize edilirdi. Artık bu yeterli değil, ekiplerin de devamlılığının sağlanabilmesi gerekiyor. Aynı ekibin sıradaki projelerde de birlikte çalışması hem çalışılan konudaki tecrübenin artmasına hem de ekipiçi güven ve işbirliğinin güçlenmesine fayda sağlayacaktır. Önümüzdeki yıllarda bu konunun daha çok önem kazanacağını düşünüyorum.

Sonuç olarak çevik yöntemlerin meyvelerini alabilmek için birlikte çalışmayı başarabilmek, takıma dönüşmek ve takımlara özgü güven ve işbirliğini tesis etmek gerekiyor.