Theseus mitolojinin önemli karakterlerinden biri, Atina’nın kurucu krallarından sayılıyor, tahmin edileceği gibi arkasında bir dolu kahramanlık hikayesi bırakmış.

Theseus’un bir de zaferlerine eşlik eden gemisi var. Literatürde Theseus’un Gemisi diye geçen başlık ise bir düşünce deneyi. Aslına sadık kalarak hikayeleştirmeye çalışalım.

Gemimiz, yıllarca süren savaşların sonunda zaferlerle şehre dönüyor ve şehrin meydanında sergileniyor. Zaman içinde ahşap geminin bazı parçaları çürüyor ve değiştiriliyor. Biraz daha zaman geçiyor yelken direği kırılıyor, tamir ediliyor. Yunan felsefeci Plutarhos, yaklaşık iki bin yıl önce şu soruyu soruyor: Bu geminin parçalarının hepsi zaman içinde değiştiğinde, bizim meydanda baktığımız gemi hâlâ Theseus’un o zaferler kazandıran gemisi ile aynı mıdır? Paradoksu biraz daha ileriye götüren Thomas Hobbes ise Plutarhos’tan bin beş yüz yıl sonra, “gemiden çıkarılan parçaları yan tarafta biriktirsek ve zaman içinde onlardan yeni bir gemi yapsak artık iki tane gemimiz mi olacak” diye problemi zenginleştiriyor.

Bugünlerde bizler çokça teknoloji tarafında kullansak da değişim, felsefenin çok ilgisini çekmiş tarih boyunca. Bu düşünce deneyinde değişime “aynı olma” kavramı eklenmiş.

Gözümüzün önünde sürekli değişen bir yapı var ve biz onun hep sabit kaldığını düşünüyoruz. Çalıştığımız kurumları, ailemizi hatta kendimizi bu gözle değerlendirebiliriz ama ben algıda seçicilik yaparak yazılım takımlarına beraber bakmayı öneriyorum.

Çevik yazılım danışmanlığı için bizimle çalışmak isteyen kurumlarla yaptığımız görüşmeler kabaca ikiye ayrılıyor. İlkinde, yazılım geliştirme yöntemlerinin eski kaldığını ve verimsiz olduğunu düşünen yöneticiler, öngörülü bir yaklaşımla çevik yazılım pratiklerini ve uygulamalarını öğrenmek ve ekiplerini bu dönüşümden geçirmek için bizlere ulaşıyorlar.

Daha çok karşılaştığımız ise ikinci durum oluyor: Daha önce, çoğunlukla da yıllar önce çevik yazılımı denemiş, “anlamış”, belli bir ilerleme kaydetmiş ama yıllar içerisinde o eski güzel günlerinden eser kalmamış organizasyonlarında neyin yanlış gittiğini anlamak ve düzeltmek istiyorlar. “Daily yapıyoruz hâlâ, retrospektif toplantılarımız pek verimli geçmiyor ama devam ediyor arkadaşlar, evet işleri de puanlıyorlar ama istediğimiz çıktıları alamıyoruz bir türlü.”

Sorduğumuzda ve konuştuğumuzda öğreniyoruz: Takımın o zamanki halinden belki üç kişi kalmış, diğerleri gitmiş; kalanlar denemekten yorulmuş, bugün takımın sorumluluk alanı ve uğraştığı problemler yıllar öncesine göre ciddi artmış, içlerinde yer aldıkları organizasyonun faaliyet alanları hatta bazen vizyon / misyon metinleri bile değişmiş.

Onlara zaferler kazandıran Thesus’un gemisini arıyorlar kısacası. Peki bu takım hâlâ o takım mı?

Kodlama standartlarının olup olmadığını, unit test yazılıp yazılmadığını veya işe alım ve buna eşlik eden yerleştirme (onboarding) süreçlerini sorduğumuzda ise, yanlış yere geldik galiba diyen gözlerle karşılaşıyoruz: “Biz Scrum için gelmiştik, ekip de sprint review yapıyor daha önce söylediğimiz gibi”. Aslında bizim sorularımız da benzer sorular, biz de o organizasyon içerisinde aynı gemiyi bulmaya çalışıyoruz.

“Gemi aynı gemi mi?” sorusuna felsefeciler farklı alanlardan yanıt veriyorlar. Bunlar arasında üzerinde durdukları iki ana kavram “identity” (benlik / kimlik) ve “purpose” (amaç). Geminin maddi varlığının dışında ona eşlik eden bir kimliği ve amacı var. Bugün Yunanistan’da bir müzeye gitseniz ve oradan bir Theseus’un Gemisi anahtarlığı alsanız, beraberinizde getirdiğiniz o kimlik ve amaç oluyor; bunlar varsa aldığınız anahtarlık hâlâ aynı gemi.

“Kodlama standartlarınız var mı, test yaklaşımınız nasıl?” soruları aslında takımın kimliğini bulma soruları. İleri mühendislik pratiklerini benimseyen takımların bir kültürü (kimlik) oluştuğunu ve bu kültürün takıma eşlik ettiğini biliyoruz. Geliştirici ekip “kodcular” olarak görüldüğünde ise maalesef başka bir kültür ortaya çıkıyor.

Günlük toplantılarını yoklama şeklinde yapmayıp “biz birbirimizle iletişim kuran bir takımız” diyen, retrospektiflerinde iyileştirme aksiyonu olmadığında içten içe üzülen takımlar yine aynı kültürü insanlar üzerinden tanımlıyorlar; bunu çok önemli buluyoruz.

Metriklerini, “kalite ekibinin baktığı sayılar” diye görmeyip faydalı çıktı üretmenin sinyalleri olarak yorumlayan ekipler sürekli olarak birbirlerine “amaç”larını hatırlatıyor.

Çeviklik dönüşümünü bu yüzden organizasyonlara kültürü kazandırma ve amacı tanımlama süreçleri olarak görmekte sonsuz fayda var. Dönüşümle bunlar hedefleniyorsa, Theseus’un gemisi aynı gemidir diyebileceğiz. Hedeflenmiyorsa, o gemi tahminen yüzemeyecek.

Çevik Yazılım Geliştirme Manifestosu’nu bundan yirmi yıl önce yazanlar, bu yüzden ilk maddede “süreç ve araçlardan ziyade bireyler ve etkileşimleri”ni daha değerli bulduklarını not ediyor. Scrum yapan takımlarınız sadece bir araya gelmiş 8-10 kişilik gruplar mı? Yoksa kimliği ve amacı olan, bireylerinin etkileşimlerinin olduğu gerçek takımlar mı? Basit sorular, zor yanıtlar…