Yazılım Üreten Organizasyonlarda Merkezileşme

Organizasyonel anlamda merkezileşme'den kastım daha çok karar mekanizmaları bağlamında; onlarca, yüzlerce insanın her gün yaptığı işi etkileyen kararların 2-3 kişi tarafından alınması. Konu(Organizasyon, yönetim vs.) hakkında derinlemesine bilgi sahibi birisi değilim, bahsedeceğim bazı yönetimsel kavramları tam anlamıyla açıklayamayabilirim, ancak yazılım üreten şirketlerdeki bu çeşit politikalar, yazılım üreten insanlara ve yazılım projelerine bakış açıma çok uymuyor, dolayısı ile ben konuya merkeze insanı koyarak neden merkezileşmemeliyiz bakış açısıyla bakmaya çalışacağım, biraz beyin fırtınası tarzında olacak.

Belkide yönetimin teorisi hakkında biraz daha gerilere gitmek gerekiyor, bugün çoğumuzun maruz kaldığı bakış açısını anlayabilmek için. 20.yy başları, sanayi devriminin iyice oturması, kapitalizm'in alt kademe insanlar için acımasız şartları, sosyalizm'i doğuran şartlar...

Frederick Winslow Taylor fabrikalarda farklı seviyelerde(işci, başmühendis) çalıştıktan sonra ekonomik verimlilik konusuna kafa yoruyor. Ve Bilimsel Yönetim adı altında bazı pratikler geliştiriyor ve bunları 1911 yılında bir kitap ile yayınlıyor. Taylor'ın bakış açısı tamamen ekonomik verimlilik üzerine, bunu sağlamak için her yol mübah gibi bir bakış açısı var, yani insan ikinci planda. Ve insana/işcilere bakış açısı genellemeci; işçiler sorumsuzdur, onları sürekli kontrol etmezsen işi savsaklarlar, onlar işlerini nasıl daha etkin yapabileceklerini bilmezler, hepsinin ödül/ceza motivasyonu aynıdır vs. şeklinde. Bunları aşabilmek için önerdiği yöntem; işleri planlayan, işçileri sürekli kontrol eden, onlara ne yapacaklarını, nasıl yapacaklarını sürekli anlatan, işcilerin performansını ölçen birileri olmalı, bir üst akıl, daha dogrusu bir üst akıllılar grubu olmalı. Ancak bu birileri işçilerin yaptıkları işin en iyi, en verimli nasıl yapılabileceğini bilebilir, uygulatabilir.

Taylor'un yöntemleri kullanılıyor elbet, ancak 1930'lar ile birlikte insana olan bu bakış açısı yavaş yavaş terk ediliyor. Taylor bu çalışmalarıyla, endüstri mühendisliğinin babası olarak biliniyor.

Douglas McGregor 1960'larda bir iş yerinde yöneticinin çalışanlarına bakış açısını gösteren, bir birine zıt 2 teori geliştiriyor; Theory X ve Theory Y.

Theory X'e göre insanlar tembel ve yaptıkları işten mutsuzdurlar, sorumluluktan kaçarlar. Dolayısı ile bu insanların verilen işi yapabilmeleri için otoriter bir yönetim stili gereklidir. Bu insanları yakın mesafeden kontrol etmek ve gerekiyorsa ceza vermek gereklidir.

Theory Y'e göre insanlar çalışarak bir şeyler başarmayı isterler ve bundan bir haz alırlar. Gerekli şartlar sağlandığında her insan sorumluluk almayı ister, motive olup, kendi kendini kontrol edebilir.

Her iki teoriden birisine uyan insanlarla beraber çalışıyor olabilirsiniz, tüm insanlar X'dir veya tüm insanlar Y'dir diye bir ön kabullenme yok. Aslında önemli olan bu iki yaklaşımın da bu iki insan tipinin de farkında olmak ve ona göre davranmak. X olan bir insanı Y bakış açınızla yönetemezsiniz, Y olanı da X bakış açısıyla.

Aynı bağlamda Peter Drucker'ın 1959'larda ortaya attığı knowledge worker diye bir kavram var. Türkçeye bilgi çalışanı olarak çevrilebiliyor. Bu insanlar hayatlarını düşünerek kazanan insanlar, en azından ağırlıklı olarak, doktorlar, mühendisler, bilim adamları, mimarlar gibi. Bu insanlar sürekli belli bir rutinde iş yapmazlar, problem çözerler, farklı bakış açılarını, yaklaşımları düşünmek işlerinin bir parçasıdır.

Drucker bu tip insanlarla çalışıyorsanız, bunların kendi işlerinin eğitimini aldıklarını ve yaptıkları işi en iyi kendilerinin bildiğini kabul etmek zorundasınız diyor. Bilgi çalışanlarının yöneticilerinin de bilgi çalışanı olması veya geçmişte bilgi çalışanı olmuş olması gerekir. Bu insanların motivasyon faktörlerini genelleyemezsiniz, bireysel olarak bu insanlarla ilgilenmek zorundasınız, bireysel farkındalık ile bu insanları motive edebilirsiniz.

Drucker 21.yy'da kurumların en değerli varlıkları bilgi çalışanları ve onların verimlilikleri olacak şeklinde bir öngörüde de bulunmuş.

Benim bakış açıma göre biz yazılım/bilgisayar mühendisleri kesinlikle bir bilgi çalışanıyız dolayısı ile bilgimize, tecrübemize, iş yapış şeklimize saygı duyarak, değer vererek yönetilmeliyiz diye düşünüyorum. Ancak çoğu zaman Taylor'un çalışanlara bakış mantalitesi ile yönetildiğimizi düşünüyorum.

Yönetilme şeklimizin odağında insan olmalı. Eğer yönetilme şeklimizin odağında ekonomik verimlilik, süreçler, ürün, proje vs. olursa bunları sağlamak çok zor ancak yönetilme şeklimizin odağında insan olursa ekonomik verimlilik, düzgün süreçler, düzgün ürünler hepsi bunun bir çıktısı olacaktır.

Tabi bu tek başına yeterli bir bakış açısı olmayabiliyor, doğru insan diye bir kavram işin içine giriyor. Siz doğru insanlarla çalışmıyorsanız, bu insanları Theory X'e göre yöneterek zar zor bir çıktı alabiliyor olabilirsiniz, aynı insanları knowledge worker mantığı ile yönetirseniz kaos üretiyor olabilirsiniz.

Peki doğru insanı nasıl bulacağız, işin içine insan girince, kesin ifadeler tanımlar çok gercekci olmayabiliyor ancak öncelikle Theory Y'deki tanıma uygun insanları seçmeye çalışmanız gerekiyor. İki anahtar kelime öne çıkıyor, iletişim ve merak. Yazılım mühendisleri için birinci yetenek çoğu zaman zor ama belli bir kriterin üzerinde olmasını beklemeliyiz, mükemmel teknik yetenekleri olan ama iletişim anlamında özürlü olan birisi ile bir noktaya kadar çalışabiliyorsunuz, gerçek başarıların bir takım çalışmasından çıktığına inanıyorsanız bu insanlarla uzun vadeli çalışamıyorsunuz.

Eğer yazılım üretirken bilgi çalışanı insanlarla çalışıyorsanız onları standartlaştırmaya çalışmanız, onlardan bağımsız süreçler tasarlamaya çalışmanız size çok bir fayda vermeyecektir. Yıllarca yazılım üreten bir bilgi çalışanına, hayatında iki satır kod yazmamış birilerinin, sırf teorik bilgiye dayanarak, nasıl çalışacağını tarif etmeye çalışması ne organizasyona ne de çalışana faydası olan bir yöntem. Bilgi çalışanlarının iş yapma şekilleri üzerine olan fikirlerinin üzeri, sırf bilgi çalışanı olmayan yöneticilerinin kafasına uymuyor diye çiziliyorsa, işi yapan yani gerçek yazılımı üreten kendisi olmadığı halde ortalıkta sürekli en iyi ben bilirim kafası ile dolaşanlar varsa, o organizasyondan sağlıklı çıktılar beklemek de çok gerçekçi değil.

Bilgi çalışanlarının olduğu bir organizasyonda sürekli merkezi kararlar alıp bunu dayatmak, yeni bilgi çalışanlarının gelişmesini engellediği gibi, insanların bu kararlara taahhüt vermelerini(commitment, buy-in) de engelliyor. Sonuç olarak asıl amacı yazılım üretmek olan firmada, yazılım üretmesi gereken bilgi çalışanları yazılım üretmek dışındaki her şeye odaklanmak zorunda kalıyorlar. Dolayısı ile yazılım üretilmiyor, yönetimin teşhisi çok farklı noktalara oluyor, daha fazla mikro yönetim, daha fazla kontrol devreye giriyor, ve daha kaotik bir sona doğru gidiliyor.

Bahsettiğim bakış açısı değişikliği ve insanların buna doğru tepki vermesi tabiki bir anda olabilecek bir şey değil. Yıllar boyunca insanlarda oturmuş bir yönetme ve yönetilme kültürü var, sadece şuna dikkat çekmek istiyorum; yöneticilerin ciddi bir beyin gücüyle çalıştıklarının farkında olmaları ve bu beyin gücünü kullanabilmek için ne gerekiyorsa ona yapmaları gerekiyor. Nihayetinde bu bir vizyon meselesi yani yöneticinin bakış açısında, hedefinde bu olmalı ve attığı her adımda bu hedefi gözetmeli. Çalışanlarına, bu işi siz yapıyorsunuz, bu işin sorumlusu da yetkilisi de sizsiniz bakış açısını vermeli, yöneticinin bu bakış açısının farkında olan ve bu profile uymayan çalışanlar zaten uzun vadede orada tutunamayacaklardır.

Burada denetimsiz bir şekilde her şeyin çalışanlara delegasyonu anlaşılmasın, süreclerinizde elbette farklı seviyelerde raporlamalarınız, ölçümleriniz olacak. Bunlara göre şartlar değişmiş ise sürekli planlama yapmanız gerekecek. Denetim konusunda yapıcı mıyız yoksa yıkıcı/cezalandırıcı mıyız sorusunun sorulması gerekiyor.

Bu işi tarihsel bir süreçte halletmiş ve nihayetinde çok iyi noktalara gelmiş örnekler var; TPS(Toyota Production System) gibi, tabi biz japon değiliz, araba da üretmiyoruz. Ancak Japonlar bu mantalitelerini farklı ülkelerde kurdukları fabrikalarda da uygulayabiliyorlar, önemli olan nasıl bir değer ve prensipler kümenizin olduğu, pratikler sektörden sektöre, ülkeden ülkeye değişebilir.

Önemli olan insana ve yaptığımız işe bakış açımızın bize ne kattığını ne katmadığını ciddi anlamda sorgulamak, odağı doğru yere yani insana yani yazılım geliştirme döngüsündeki en önemli varlığa ve onların beraber çalışabilmesine(ekip ruhuna) çevirmek. Yazılım geliştirme işini yapan çalışanlara, sanat ve fikir eseri geliştiren bir çalışanmış bir ustaymış gibi bakmak gerekiyor. Bu kültürü oturtmak ve insanları da bu kültür içinde yetiştirmek gerekiyor. İnsanlara zaten karşılığında parasını alıyorlar eş...k gibi yapacaklar sığ düşüncesinden ziyade sanki onları oraya gönüllü toplamışsınız da bir şeyler yaptırmaya çalışıyormussunuz gibi yaklaşmak gerekiyor. Ama bunu bizim insanımız suistimal eder, hic bir şey üretemeyiz karşı çıkışlarını yapanlar acaba hayatlarında hiç bunu denediler mi merak ediyorum. Suistimal edenler çıkabilir ancak bunu genelleyemezsiniz, suistimal edenlerden kurtulursunuz yolunuza doğru insanlarla devam edersiniz.

Gerçekten mükemmel ürünler/projeler üretmek istiyorsak mükemmel insanlara ihtiyacımız var, mükemmel insanları çekmek ve onların bizimle kalmasını sağlamak için de mükemmel organizasyonlara ihtiyacımız var.

İnsanlara şunu söylettirebilmektir bence bir organizasyon için gerçek başarı; "Her sabah uyanıp işe giderken şunu biliyorum ki mükemmel insanlarla mükemmel bir ortamda çalışacağım ve anlamlı bir şeyler yapacağım/başaracağım..."

Büyüdükçe merkezileşen, merkezileşme gereği duyan bir organizasyon bence düzgün büyünmediğinin önemli bir göstergesidir.

Kendisini "management exorcist" olarak tanımlayan Niels Pflaeging'i Agile Turkey Submit 2014 konferansında dinlemiştim, bakış açısı hoşuma gitmişti. Organize for Complexity isimli bir kitabı var, kitap biraz sunum tadında, içinde epey görsel var ama vermeye çalıştığı mesajı gayet iyi veriyor.

Sprint Sonunda Retrospective Nasıl Yapılabilir?

Agile yazılım geliştirme yaklaşımının öne çıkan özelliklerinden ikisi, değişime cevap verebilme ve değişen şartlara adaptasyondur. Bunu sağlayabilmek için yapılması gerekenlerden birisi de sürekli olarak nerede olunduğunun, nereye gidilmeye çalışıldığının değerlendirilmesi ve alınması gereken aksiyonların alınmasıdır.

Agile manifesto'da bununla ilgili olan prensip; "Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler."

"Her zaman iyileştirilebilecek bir şeyler vardır.", "Hiç bir şey mükemmel değildir ama her şey mükemmelleştirilebilir.", "Agile bir hedef değil yolculuktur." gibi yaklaşımlar bu değerlendirme/iyileştirme toplantılarının sürekli olarak yapılmasını gerekli kılar.

Bu prensip farklı isimlerle anılabilir; Inspect&Adapt, Continuous Improvement, Kaizen, Retrospective gibi. Scrum kapsamında bu prensip retrospective toplantısı adı altında bir pratiğe dönüştürülmüş. Retrospective toplantıları her sprint'in sonunda ekibin yaptığı, scrum master, product owner, takım gibi roller dışında yönetici gibi diğer rollerin de katılabileceği bir toplantıdır. 2haftalık sprintler icin 1-1.5saat civarı olması tavsiye ediliyor.

Retrospective toplantılarının yapılmamasının nedenleri genelde şunlar oluyor;

• İnsanlar iş yapış şekilleri, projeler, süreçler vs. üzerine yeterince kafa yormadığı için iyileştirecek bir şey ortaya koyamıyorlar, diğer bir deyişle umursamıyorlar.
• Retrospective toplantılarında çıkan aksiyonlar takip edilmiyor, yani iyileştirilmesi gereken yerler iyileştirilmiyor, dolayısı ile her toplantıda aynı sorunlar tekrar tekrar konuşuluyor, bu durum bir süre sonra toplantının gereksiz olduğu düşüncesi ile sonuçlanıyor.
• Toplantıda konuşulan konular bireyselleştiriliyor ve çatışmalar çıkıyor. Bir ekip bilinci/ruhu yok ise bu çatışmalar çok kolay tetiklenebiliyor, özellikle test/development çatışmaları.

Yukarıdaki gibi sorunlar yüzünden retrospective toplantıları yapamıyorsanız ama yapmanız gerektiğini, bir şeyleri iyileştirmeniz gerektiğini düşünüyorsanız, ki her zaman iyileştirecek bir şeyler vardır, bu sorunları çözmek birinci derecede scrum master rolünü üstlenen kişiye kalıyor.

Retrospective toplantılarını ferah, insanların rahat edebileceği, beyaz tahtası olan bir toplantı odasında yapmak sağlıklı sonuçlar almanıza yardımcı olacaktır.

Retrospective toplantılarında insanları konuşturabilmek onlardan geri bildirim alabilmek için kullanılan farklı yöntemler var. Biz şu pratikleri kullanıyoruz;

• Sprint puanı
• Mutluluk Indexi
• Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim Çalışması
• Nokta Puanlama
• Tartışma

Retrospective toplantısına liderlik eden bir kişi oluyor, bizde genellikle bu kişi scrum master oluyor ama bu zorunlu değil, hatta ekib dışından birisinin retrospective toplantısına liderlik etmesi de tavsiye edilen bir pratik.

Toplantının başında toplantının nasıl ilerleyeceği her bölüme ne kadar süre ayrıldığı ile ilgili ekibe bilgilendirme yapılıyor ve sonrasında pratiklere geçiliyor.

İlk iki pratik için ekibe küçük(5x5cm) kağıtlar dağıtıyorum. Bu kağıdın bir tarafı ilk pratik için diğer tarafı da ikinci pratik için kullanılacak.

Sprint puanı ilgili sprint hakkında ekibin genel hissiyatını öğrenmek için kullanılan bir pratik. Bu pratik geçen sprint ile ilgili ne hissediyorsun sorusuna kişinin aklına gelen ilk cevabı aslında, bu cevabı farklı formatlarda alabiliyorsunuz biz puan formatında alıyoruz. Herkes aldığı kağıdın bir yüzüne sprint'e 10 üzerinden kaç puan verdiğini genel hissiyatına göre yazıyor, sonra herkesin verdiği puanlar toplanıp ortalama puan bilgisi bulunup ekip ile paylaşılıyor. Bu puan size üst seviyede, geçirdiğiniz sprint'i diğer sprintleriniz ile de karşılaştırma imkanı veriyor.

Mutluluk Indexi, ilk başta biraz garip geliyor isim olarak, bireysel bir geri bildirim alıyorsunuz ekip arkadaşlarınızdan. Bu pratik her ekip üyesinin özel olarak 3 farklı soruya verdiği cevaptan oluşuyor;

• Genel olarak burada çalışmaktan ne kadar mutlusun? (5 üzerinden puan)
• İleriye dönük olarak mutlu olacağına/kalacağına inanıyor musun? (5 üzerinden puan)
• Seni mutlu edeceğine inandığın 3-5 kelime yazar mısın?

 Herkes verilen kağıdın bir yüzünü 3'e bölerek bu 3 soruya cevabını bölmelere yazıyor. Bu pratik için kimin ne yazdığının scrum master tarafından bilinmesi gerekiyor, dolayısı ile bu kağıtlara ekip üyeleri isimlerini de yazıyor.

Scrum master, veya ekip lideri, bu kağıtları toplayıp daha sonra, mümkünse diğer sprint'in retrospective toplantısına kadar, her bir ekip arkadaşıyla kağıda yazdığı bağlamda konuşuyor. Çözülmesi gereken problemleri çözüyor veya çözülmesi için girişimlerde bulunuyor. 

Bu pratik size her bir ekip arkadaşınızın ne kadar mutlu olduğu, ne kadar umutlu olduğu, neleri istediği veya istemediği ile ilgili bilgi veriyor. Ekip arkadaşlarınızın hangi seviyede olduğu hakkında bilginiz oluyor, mesela birisinin iş yerinde maaş/kariyer gibi problemleri var ise o kişiden kendini geliştirmesini, ekip ile teknik anlamda bir şeyler paylaşmasını beklemek çok gerçekçi olmayabiliyor. Normalde çok iyi iş çıkaran bir ekip arkadaşınızın performansındaki düşüşün nedenini anlayabiliyorsunuz. Bu tür konuları bu şekilde formal bir girdi alarak yapmak bu işin tek yolu değil elbet, ekip arkadaşları ile düzenli olarak konuşan bir lider bu şekilde bir girdi almadan bu süreci iyi bir şekilde yönetebilir. Yazılı iletişim ile bir ön çalışma sonra onun üzerine sözlü iletişim ile yazılanları açma olan bu yöntem bana daha kolay ve etkin geliyor.

Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim çalışması için renkli post-it'ler kullanıyoruz. Her kategorinin bir rengi oluyor, bunları tahtaya kategori isimlerinin altına yapıştırıyorum. Daha sonra 5dakika boyunca her ekip üyesi bu kategoriler ile ilgili olarak geçen sprint için düşüncelerini post-it'lere yazıyor. Kategorilerin anlamları şu şekilde;

• Yapmaya Başlayalım; Yapmıyoruz ancak yaparsak şu şekilde faydalar olacağını düşünüyorum, bir sonraki sprint'de bunun yapılmasını istiyorum.
• Yapmayalım; Bunu yapıyoruz ancak bu bize şu şekilde zarar veriyor o yüzden artık bunu önümüzdeki sprint'den itibaren yapmayalım istiyorum.
• Yapmaya Devam Edelim; Bunu yapıyoruz, şu şekilde faydalarını görüyoruz, o yüzden bunu yapmaya devam edelim. Sprint kapsamında bir çok şey yapıyor ve hepsinin devam etmesini istiyor olabilirsiniz, buraya yapmaya yeni başladığınız veya kritik gördüğünüz şeyleri yazabilirsiniz.

5 dakikanın sonunda, ekip üyeleri sıra ile tahtaya çıkıp post-it'ler üzerine yazdığı notları tahtada ilgili kategoriye yapıştırıyor ve yazdığı şeyi okuyor, belki 2-3 cümle ile de bir açıklama yapıyor, ama tartışılmıyor. Her ekip üyesi bunu yaptıktan sonra biz, eğer tahtada çok fazla konuşulması/tartışılması/aksiyon alınması gereken post-it var ise nokta puanlama yöntemi ile öncelikleri belirlemek için oylama yapıyoruz. Eğer post-it sayısı az ise hepsini konuşabileceksek bu oylamayı yapmıyoruz.

Nokta puanlamada her ekip üyesinin her kategoride 3 nokta'dan ibaret olan bir puanlama hakkı oluyor. Toplamda 3 kategori var, yani her ekip üyesinin elinde 9 adet noktası oluyor. Ekip üyeleri tahtaya çıkıp her kategoride kendine göre öncelikli olan post-it'lere puan veriyor, isterse tüm puanını(3nokta) tek bir post-it'e de verebilir veya dağıtadabilir. Burada amaç öncelikli olan, en çok puan alan, konuları belirleyip onlara öncelikli olarak odaklanmak.

Son olarak tahtadaki post-it'ler, toplantıya liderlik eden kişi öncülüğünde ekip ile tartışılıyor ve yeterince net değilse, farklı görüşler varsa bunlar ortaya çıkarılmaya çalışılıyor. Burada herkesin eşit süre alarak fikir beyan etmesine imkan verilmesi, faydasız çatışmaların önüne geçilmesi, konuların bireyselleştirilmesine izin verilmemesi gibi konulara dikkat etmek gerekiyor. Burada eğer alınması gereken aksiyonlar çıkar ise onları da not etmek gerekiyor.

Elbette bir ekipde bireysel sorunlar da olabilir, ekibi rahatsız eden, ekip motivasyonunu düşüren çalışanlar olabilir. Bu tip sorunların retrospective toplantılarında konuşulması çok doğru bir yaklaşım değil, çatışma çıkma veya bireysel olarak bir ekip üyesinin rencide edilme ihtimali çok yüksek olduğu için. Scrum master veya ekip liderinin bu tip sorunların farkında olması ve bu tip ekip üyeleri ile bire bir konuşması, bir birleri arasında sorun yaşayan insanların bire bir konuşmasını sağlaması gerekiyor. Bireysel sorunları ve sonuclarını net olarak ortaya koyması, çözüm üretmesi veya çözüm beklemesi gerekiyor.

Bu son pratik ile birlikte retrospective toplantısı sonlandırılıyor.

Toplantı sonrasında biz retrospective toplantısının çıktılarını(sprint puan, mutluluk indexi, Yapmaya Başlayalım/Yapmayalım/Yapmaya Devam Edelim notları, aksiyonlar) yazılı olarak online bir ortamda(JIRA) tutuyoruz. Takip edilmesi gereken aksiyonları bir kanban board üzerinden online herkesin görebileceği şekilde takip ediyoruz.

Retrospective toplantısı sonucunda çıkan aksiyonların takip edilmesi, delegasyonu, yapılması scrum master veya ekip liderinin sorumlulugunda oluyor. Mutluluk Index'lerinde çıkan konuların ekip üyeleri ile bire bir görüşülmesi de yine aynı kapsamda.

İlk başta söylediğimizi tekrar edelim; unutmayalım her zaman iyileştirecek bir şeyler vardır.

Retrospective pratikleri ile ilgili faydalandığımız bir kitap;

• Agile Retrospectives: Making Good Teams Great, by Esther Derby, Diana Larsen

Holding Space

Türkçe karşılığını bulamadığım holding space kavramı basitce insanın kendisi veya bir başkasının bir şeyleri yapması için ona müdahalelerden, ön yargılardan uzak bir ortamı sağlaması, onun ilerlemesi bir şeyler ortaya çıkarabilmesi için desteklenmesi yani ona kendini bir şekilde ifade edebilmesi için alan açılması anlamına geliyor.

Bu kavram farklı alanlarda uygulanmakla birlikte daha çok yoga vs. gibi meditasyon teknikleri alanında karşınıza çıkıyor. Ben bu kavram ile ilk defa Lyssa Adkins’in Coaching Agile Teams kitabında karşılaştım.  Yazar kitabın master yourself bölümünde her gün güne başlarken yaptığı, bir dizi kişisel farkındalık(mindfulness) kitabının birinden rastgele bir bölümü açıp orayı okuyup, o bölümden aldığı ilgili mesajı o günkü aktivitelerine yansıtmaya çalışmak gibi bir pratikten bahsediyor. Yazarın kütüphanesindeki kitaplardan bir tanesi de holding space kavramı ile ilgili küçük küçük bölümler içeren Chris Corrigan’ın The Tao of Holding Space kitabı.

Agile dünyaya bu kavramın agile lider açısından yansıması ise ekiplerinize alan açın, onları baskılamayın, onları komutlarla kontrol etmeyin, onların yaptığı, yapacağı, yapması gereken işlere karışmayın, kendi iclerinde organize olabilen, hareket edebilen, üretebilen, problem çözebilen, öğrenebilen bir takım olmalarına izin verin. Onların yapmaları gereken, takım olarak yapmaları gerekeni onların yerine siz yapmayın, onlara güvenin ve bir şeyler yapmalarına izin verin.

Mevcut çalışma koşullarımıza, genel olarak Türkiyedeki yazılım geliştirme kültürüne baktığımızda yukarıdaki paragrafta yazanlar çok uçuk şeylermiş gibi geliyor. Bu sektörde, biraz da deneyimli olan, bir çok kişinin bu yaklaşıma nasıl tepkiler vereceği az çok tahmin edilebilir, “Yapmazlar ki!”, “Yapamazlar ki!”, “İnsanlara bu kadar güvenmek büyük risk!” vs.

Türkiyedeki yazılım geliştirme sektöründe bugüne kadar gördüğüm, deneyimli deneyimsiz insanların, genel olarak kültürlerine baktığımda da bu tepkilerin bir kısmı yersiz değil gibi. Ama bu noktaya ulaşamayız biz olduğumuz gibi devam edelim şeklinde de bir mantık doğru değil.

Bir takım kendi kendine hareket edebilen, sağlıklı bir verimlilik aralığında(verimlilik nedir çok tartışmalı bir konu bu arada) çalışan, yüksek performanslı bir ekip olabilir. Ancak elbette doğru insanlar ve doğru teşhis ve tedaviyle.

Bir ekibi hadi böyle olun, ekip liderine çok ihtiyac duymadan kendi kendinize sağlıklı bir şekilde çalışın şeklinde birden bire koyvermek, ekibin de koyvermesiyle sonuclanıyor, tecrübeyle sabittir J.