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.