Telefon : +90 212 275 71 06  
Çevikliği Unutmak ve Yeniden  Öğrenmek

Çevikliği Unutmak ve Yeniden Öğrenmek

Bugün karşılaştığım birçok ekip çeviklik konusuna yabancı değil.

 

Ama çok azı bunun gerçekten işe yaradığını görüyor. Çevikliği öğrenmede sorun yok. Asıl zorluk, çevikliğin yıllardır çeşitli iş ortamlarında nasıl uygulandığını unutmak.

 

41 yıllık arkadaşım ve yazılım geliştirme konusunda yirmi yıllık deneyimi (bunun on yılı üç işte “Çeviklik” olgusunu gerçekleştirerek ve bir yılı danışmanlık yaparak geçmiştir) olan arkadaşım Dave, deneyimini şu şekilde açıklıyor: Pazarda sık varlık gösterin. Hızlı öğrenin. Kaliteye dikkat edin. Çapraz işlevli ekipler ve otonom bir organizasyon yapısı oluşturun. Bu her zaman sezgisel olarak mantıklı gelmiştir ama görünüşe göre bunu hiçbir zaman olması gerektiği gibi kullanamadık. Bana göre yalnızca yüzeyi biraz kazıdık. Ve bu kadar yıldan sonra artık bu konuda şüpheliyim.

 Dave’ i şüpheci yapan şey neydi? Neden çeviklik vaat ettiği şeyi bize sunamadı? Yine Dave’ in sözleri….

Dürtüldük, teşvik edildik, mikro yönetim modellerine tabi tutulduk ve her hareketimiz ölçüldü. Daha hızlı olmak için sürekli bir baskı vardı ve çalışmamızla gurur duymak o kadar da kolay olmuyordu. İş, temelde bizi sipariş alma görevlisi yerine koyuyordu. Eski alışkanlıklar ve engelleyici şeyler, yeni bir formda ve yeni adlarla aynen yerinde kaldı. Zaman cetveli ve tahminler mi?.. Hikayenin özü! Proje Müdürleri?.. Scrum Master’lar ve PO! Teslim zamanları?.. Depar taahhütleri. Durum kontrolleri?.. Tam bir komedi. Bu pislikle yıllardır boğuşuyorum.  Süreç benden çok şey aldı, ama karşılığında çok az şey verdi.

Dave akıllı biri. Bir yapının tasarımı ile çeşitli işlerinin ve ekiplerinin amacı/bağlamı arasındaki farkı ayırt edebilir. Ama bir çeviklik tarihçisi değil (Çevikliğin tarihini takip eden birçok arkadaşımın oldukça sorun yaşadığı bir perspektif).

Hikaye’nin öne çıkan noktalarını isteğe bağlı şeyler olduğunu açıkladığımda, şaşırdı. Çeviklik ekipleri ile ilgili bazı deneyimlerimi (deparları elemek, daha deneysel odaklı olmak, proje üretimini azaltmak, Scrum Master rolünü paylaşmak, faydalara/sonuçlara daha fazla dikkat etmek, daha az transfer, bağlamı açıklayan ve sonra yoldan çekilen bir ürün müdürü .) paylaştığımda, gerçekten de aydınlanmış göründü. “Bu tarz bir şeyin mümkün olmadığını düşünüyordum!”

Benim açımdan beklenmedik olan şey, Dave’ in ekibinin kullandığı bir dolu gelişmiş teknik uygulamayı açıklamaya devam etmesi oldu. “Ama bu tam olarak çevik değil, değil mi? Bu daha çok deneyimle ilgili, diğer şeyler de biraz DevOps odaklı görünüyor.”Ah! Keşke Ron Jeffries ya da Kent Beck burada olsaydı.

Buradan ortaya çıkan sonuç şu ki dünyanın geri kalanı yapılar ve yöntemler üzerinde eğlenceyi de kapsayacak şekilde bir akıl yürütme sürecine girmiyor, “tarihi” okumuyor ve her gün bu konuda düşünmüyor! Kendime not alayım.

Lafı şuraya getireceğim.

Twitter’ da çevikliğin perspektifini ve “açık” yorumlarını karşı karşıya getiren bir dolu tartışmaya dahil oldum. Ama son zamanlarda anlıyorum ki, benim karşımdaki zorluk, biraz ön yargılı olsa da, ekiplerin çeviklik konusundaki işe yaramaz deneyimlerinden oluşan geçmişlerini (ve yığınla şüpheyi) unutmalarına yardım etmek. “Yeni” ekiplerde deneyim yok, ama aynı zamanda sırtlarında geçmişin yükü de yok. Kazanç artık yeni nesil büyük yenilikçiler için artıyor. Bu benim dünyam değil.

Koçlar hemen “iyi de Dave’ in deneyimi gerçek çeviklik değilmiş ki!” diyecektir. Ve bir dereceye kadar haklılar. Ama kullanıcı (Dave) açısından bakıldığında, deneyim ile deneyime konu olan içeriği gerçekten birbirinden ayırabilir misiniz? Dave’ i şüpheci olduğu için suçlayabilir misiniz? O, çevikliğin suçlanamayacağını biliyor, ama yine de ağzında kötü bir tat bırakıyor.  Peki “Gerçek çeviklik” nedir? Gerçek çeviklik, Çeviklik ile olan deneyimimiz değil mi? Her zaman düzenleyeni ve kullanıcıyı suçlayamayız.

Bu açıkça görülüyor, ama görünüşe göre bu iki sorunu ayırt etmiyoruz. 2018’de benim tahminime göre bu yolda yapabileceğimi düşündüğüm kadar sapmayacağım. Diğer taraftan çeviklik de hareketli bir hedef. Çeviklik, hali hazırda pratikler, ekipler, konferanslar, kitaplar, organizasyonlar, Meetup, YouTube videolarında vb. yer alıyor. Çeviklik Manifestosunun ilk satırında söylendiği gibi:

Yazılım geliştirmenin daha iyi yollarını, bunu yaparak ve başkalarının bunu yapmasına yardım ederek öğreniyoruz.

Yani sonuç olarak şunu demek istiyorum. “çevikliğin” unutulması ve insanların çevikliğin daha yararlı bir versiyonunu benimsemesine yardım etme sorununa nasıl bir yaklaşımda bulunacağız? “Destek tekerleklerine” ihtiyacımız var mı? Organizasyonların “yeni yol” yerine “eski yolu” aşılamasına nasıl engel olacağız? İki günlük sertifikalar işe yarayacak mı? Çünkü aslında önümüzdeki zorluk bu değil.


Yazının orijinali için tıklayabilirsiniz.