Agile Kültürün Yapıtaşları
Agile dönüşümden bahsederken zihniyet ve kültür değişiminden bahsetmemek imkansız. Verimsizlik ve memnuniyetsizlik ile ifade edilebilen mevcut problemlerin büyük çoğunluğu, tüm çalışanlara, süreçlere ve yazılımın her parçasına sirayet eden yerleşik şirket/bölüm/takım kültüründen kaynaklanıyor. Yerleşik kültür bazen öylesine kaotik oluyor ki, çalışanlar değer yaratmaktan çok süreçlerin içinde hayatta kalma savaşı veriyor. Bu nedenle, verimli çalışanlar, sürdürülebilir süreçler, sürekli değer kazanan ve gelişen bir organizasyon istendiğinde doğrudan şirket kültürüne odaklanmak gerekiyor.
Malum bu ülkenin çalışanları olarak Türk milletinin bir ferdiyiz ve Türk eğitim sisteminde yetiştik. Hem eğitim sistemi ve aile yapısından gelen, hem de miras olarak nesilden nesile geçen bazı özelliklere sahibiz. Zaman zaman "agile kavramları yabancı kültürlerde ortaya çıkmış ve bizim kültürümüze tam oturmayan kavramlar" ya da "ne yaparsak yapalım olmuyor, sanki agile bizim kültürümüze uymuyor" dendiğine şahit olmam biraz da bundan.
Agile kültürün getirmeye çalıştığı kavramlar ve değerler, her kültürde rahatlıkla uygulanabilen, genel değer yargıları ile ters düşmeyen, aklın ve kalbin rahatlıkla kabul edebileceği kavram ve değerler. Biz aslında mevcut alışkanlıklarımızdan kopmakta zorlanıyoruz ve rahat bölgeden (comfort zone) çıkmaktan ölesiye korkuyoruz. Tutku ve disiplini iş ve süreçlerimizde hep ikinci plana atıyoruz. Farkındalık yaratmak yerine sıradan olmayı yeğliyoruz. Bu nedenle, başarmaya çalıştığımız kültürel değişim çoğu zaman çok zor ya da imkansızmış gibi görünüyor.
Agile kavramlar, değerler, ritüeller ve pratikler ile başarmak istediğimiz yegane şey, belirli bir kültürü inşa etmek. İnşa etmeye çalıştığımız bu kültürün yapıtaşlarını elimden geldiğince, dilim döndüğünce anlatmaya çalışacağım.
1) Sorunlardan şikayet etmek yerine sorunu çözen olmak
Şikayet etmeyi genel olarak çok severiz. Hergün birçok konuyu eleştirir, aslında ne yapılması gerektiğinden sıkça bahsederiz. Hararetli tartışmalardan sonra "ülkeyi kurtarmaya ramak kalmıştı" dememiz de benzer sebepten. Hep birilerinden harekete geçmesini bekleriz.
Örneğin, toplantı odalarında tahta kalemi eksikliğinden şikayetçi olduğuzu varsayalım. Beyaz tahtaya bişiler çizeceksiniz ancak ya kalem yok ya da olanlar yazmıyor. Yapacağımız şey tabi ki şikayet etmek. Sonra toplantınız biter, bir başkası odaya gelir ve ne görsün, tahta kalemi yok. Şikayet etme sırası onlara geçmiştir artık. Tüm gün şikayet edilir ancak kimse harekete geçmez.
Oluşturmaya çalıştığımız kültür gereği, sizin kalkıp kırtasiye ile ilgili kişiyi -gerekirse sorup soruşturup- bulup kalem sorununu ona anlatmanız ve ondan yeni kalemler temin etmeniz gerek.
Durum gözlenmeli, sorun tespit edilmeli, çözüm yolu bulunup uygulanmalı ve durum iyileştirilmeli. Al sana "inspect & adapt".
Bu kültürü oluşturabilmek adına, düzenli olarak özdeğerlendirme toplantıları yapılmasını öneriliyor. Scrum'da buna "retrospective meeting" deniyor. Bu toplantılarda sorunlar gün ışığına çıkarılıyor ve çözüm önerileri listeleniyor. Sonra da en makul bir-iki çözüm önerisi belirlenip yapılacaklar listesine ekleniyor. Tabi burada hizmetkar lider olarak Scrum Master önemli bir yere sahip. Asli görevi sorunları çözmek ve takımına hizmet etmek olan Scrum Master, tüm bu kültürel değişimin başarısında da önemli bir yere sahip.
2) Görevin size verilmesini beklemek yerine, görev almak isteyen olmak
"Ben bana verilen işi yaparım, iş verilmiyorsa beklerim" zihniyeti organizasyonları ve projeleri büyük çıkmazlara sürükler. Birilerinin size iş ataması demek, işi atayacak mercinin üzerine çok büyük bir yük vermek demektir. Bu büyüklükte bir sorumluluk hataları da beraberinde getirir.
Ayrıca size iş atanmasını beklemek demek, sorumluluk almak istememek anlamına da gelir. Bir sorun yaşandığında "işi bana yapamayacağımı bile bile o atadı" mazereti sunulabilir. "İşi o verdi" demekle "sorumlusu ben değilim" demek aynı şeydir ve böyle yürüyen bir proje asla başarılı olamaz.
Scrum'da her sabah yapılan "ayakta günlük toplantılar (daily standup meetings)"da takım elemanları üzerilerine iş alırlar. Aslında takımda iş atayacak bir merci bulunmadığından, iş almak zorunda kalırlar. Scrum Master'ın iş ataması durumu nadiren karşılaşılan bir durumdur ve mutlaka müdahale edilip düzeltilmesi gerekir.
3) Sorunları hasıraltı etmek yerine, sorun bulan olmak
Bu madde, birinci madde ile doğrudan ilişkili. Ancak anlatmak istediği şey biraz daha farklı. Eğer şirketinizde sorun bulanlar cezalandırılıyorsa, ya da "sorun buldum, çözüm önerdim, iş üstüme kaldı" diyorsanız, sorunları hasıraltı etmeniz normal. Çünkü olacaklardan korkuyorsunuz ve zor durumda kalmak istemiyorsunuz.
Altuğ Altıntaş'ın Kanban konusundaki konuşmasında değindiği gibi, ulaşmaya çalıştığımız kültür "sorun bulunca sevinen" bireyler yaratmak üzerine olmalı. Çünkü sorun varsa çözüm de var, ve çözüm varsa ilerleme var demektir. Sorun biz istesek de istemesek de hep var. O zaman "sorun ilerlemenin başlangıcıdır" kavramı üzerine bir kültür inşa etmeliyiz.
4) Hataya ceza vermek yerine, bir kez daha karşılaşmamak için önlem almak
Sunucudaki veritabanından gigabaytlarca veriyi yanlışlıkla sildikten sonra, takım liderim bana şunu söylemişti: "En iyi sistem yöneticisi hayatında bir kez "sudo rm -rf /" yapmış sistem yöneticisidir. Sen artık o aşamayı geçtin. Aramıza hoş geldin." O günkü şaşkınlığımı anlatamam. Sonrasına aynı hatanın bir kez daha oluşmaması için önlemlerimizi fazlasıyla aldık tabiki. Ancak soruna ve çalışana karşı bu ince tavra hayran kalmıştık.
Şikayet etmek yerine çözmek, üstüne bir kez daha olmaması için önlem almak sürekli iyileştirmenin ana kavramları arasındadır.
5) Yalnız çalışmak yerine, takımca çalışmak
Biz yazılımcılar yanlız çalışmayı çok severiz. O yüzdendir ki çoğunlukla geceleri tek başına çalıştığımızda daha verimli olduğunuzu düşünürüz. Bu takım çalışmasına uygun olmadığımız anlamına gelmesin. Agile kültüründe takım bir organizma olarak ele alınır. Takım olarak tasarım yapılır, takım olarak yazılım geliştirilir, işi bitirmek için ne gerekiyorsa takımca yapılır. Herkesin ayrı ayrı takılıyorsa, buna takım değil grup demek daha uygun. Takım, bilginin ve geribildirimin kişiler arası geçtiği, kendi dinamikleri olan bir bütün olarak ele alınmalıdır.
Takım olmak sorunları beraber bulmak, beraber çözmek, iş paylaşımı yapmak, birbirlerine yardım etmek, işi ve sorumluluğu beraber almak demektir. Eğer takımınıza sizin yaptığınız işten sorumlu birileri varsa takım olmamışsınız demektir. Tüm takım işin tümünden sorumludur (empowered teams). Başarı ve başarısızlık kişilere değil takımın tümüne aittir. Bu nedenle gerçek takımlarda arkada kalanlara el uzatılır, önde gidenler yol gösterir, takım kendi kararlarını kendi alır.
Bir şirketin en değerli varlığı değer yaratan çalışanlarıdır. O nedenle tüm yönetici ve liderler proje takımları gibi değer üreten gruplara hizmet etmekte, onların sorunlarına yardımcı olmakta yarışmalıdırlar.
6) Bilgiyi saklamak yerine, bilgiyi paylaşmak
Hergün onlarca bilgi öğreniyoruz ve bir kısmını işlerimize doğrudan tecrübe ediyoruz. Ancak kendi çabalarımız ile ulaşabileceğimiz nokta çok uzak değil. Bilginin paylaşıldığı ortamlarda sinerji artar ve benim bilgim ona, onun bilgisi de bana geçince tahmin edilemeyecek boyutta bir gelişim kaydedilir.
Bilgi paylaşımı ortamı sağlamak aslında hiç de zor değil. Eşli programlama, kod gözden geçirme (code review) gibi pratikler yanında iç eğitimler de sizin bu kültürü oturtmanıza yardımcı olacaktır. İç eğitimlerden kastım şu: Takımınızdan herkes, bilgi sahibi olduğu en az bir konuyu arkadaşları ile paylaşmalı ve bunu düzenli olarak yapmalısınız. Devamlılık ve gönüllülük paylaşımın ana kaidelerindendir.
Bilgi paylaşımı yöneticilerden çalışanlara da doğru olmalı. Projelerin durumu, geleceği, şirkette neler yaşandığı, şirketin vizyonu ve daha birçok konuda yöneticiler çalışanlara düzenli olarak bilgi vermeli.
Ayrıca müşteriden de hiçbirşey saklanmamalı, gidişatta haberdar, hatta projenin tam içinde olmalılar.
7) İşi ve durumu anlaşılmaz halde tutmak yerine, görselleştirip anlaşılır hale getirmek
Bir proje üzerinde çalışıyorsunuz, ya da bir önemli bir hatayı çözüyorsunuz, ya da işler birikti ve teslim tarihi yaplaştı... Tüm bu durumlarda proje yöneticinizin / takım liderinizin / yöneticinizin sizden sürekli "son durum nedir"i öğrenmek istemesi sıklıkla karşılaşılan bir durum. Bu hem konsntrasyonunuzun bozulması anlamına gelir, hem de hesap vermekten iş yapamaz hale gelmenize bile yolaçabilir. "Müsade edin ki işimi yapayım" serzenişlerinizi duyar gibiyim.
Yöneticilerimizin son surum hakkında fikir sahibi olmak istemeleri hakları, onların da hesap verecekleri başka merciler var. Ancak takımı da sıkboğaz etmeden bunu nasıl başarabilirler?
Tabi ki yapılan işleri ve durumlarını görselleştirerek. Sütunlara sahip beyaz tahtalar ve burndown çizelgeleri gibi çizelgeler kullanmak hep bu yüzden. Kanban tahtası, elektronik ortamda araçlar hep bu yüzden. Eğer yapılan işi görselleştirmeyi başarırsanız, tüm süreç şeffaflaşır ve hiç kimse son durum hakkında sizleri rahatsız etmek zorunda kalmaz.
8) Mevcut işe saplanmak yerine, iş dışı alanlarda da kişisel gelişme kaydetmek
Ben buna "sermayeden yemek" diyorum. Yani hergün yapageldiğimiz iş ile alakalı teknik bilgi ve becerilerimizin yanında farklı teknik bilgi ve beceriler kazanmıyorsak, bilgi sermayemizden yiyoruz demektir. Dünya bir yere giderken siz yerinizde kalıyorsunuz demektir.
Bunu kırabilmek ve inovasyon getirebilmek adına Google ve Atlassian %20 zaman uygulaması yapıyorlar. Sizin şirketinizde buna imkan olmayabilir, ancak iş dışı zamanınızda kendinizi geliştirmeli ve vizyonunuzu farklı alanlara doğru genişletebilmelisiniz.
9) Elle çalışan sistemler kullanmak yerine olabildiğince otomatikleştirmek
Manuel testler kaçınılmazdır. Her durum ve şartta bir çift gözün yapılan değişiklikleri ve olası hataları gözlemlemesi gerekir. Ancak bu ihtiyacın minimum olması şartıyla. Eğer çevik olmak, müşterinin ihtiyaçlarına ve değişen gereksinimlere karşı anında cevap verebilmek isteniyorsa, mutlaka ara süreçler otomatikleştirmeye çalışılmalıdır. Sürekli bütünleştirme (continous integration), sürekli yükleme (continous deplopyment / delivery) ve kod analizi (sonar gibi) gibi pratikler hep süreçleri daha verimli hale getirebilmek adına yapılan otomatikleşmiş uygulamalardır.
10) Güvensizliğe dayalı sistemler oluşturmak yerine güvenmek
Kuşku ve güvensizlik asit gibidir. İçine girdiği organizasyonu eritir, delip geçer, parçalanmasına neden olur. Önce kişiler birbirine güvenmez, sonra takımlar birbirine güvenmez, sonra da departmanlar birbirine güvenmez. Şirkette güven kaybolursa başarısızlık ardı ardına gelmeye başlar.
Güven duymak ve güvene dayalı süreçler kullanmak şarttır. Kişiler birbirine, çalışanlar yöneticilerine, yöneticileri çalışanlara, takımlar birbirlerine mutlaka güvenmek zorundadır. Güven zor inşa edilen, ancak kolay parçalanan sırma bir yapıdır. Güvenin zedelenmesine yol açacak hiçbir olaya izin verilmemelidir.
Güven duymak, şeffaf olmayı, yalan söylememeyi, gizli saklı iş yapmamayı, arkadaş arkasından iş çevirmemeyi, daima sorumluluk bilincinde olmayı gerektirir. İşi yapacağını taahhüt eden (commitment) takım, müşteriye söz veren yönetici ve yazılımı finanse eden müşteri dahil yazılımın tüm iştirakçilerinin güven üzerine iletişim kurabilmeleri için gerekenler çekinilmeden yapılmalıdır.
11) Sonradan paylaşmak yerine, anında geribildirim vermek
Geribildirim kavramı deyince aklıma üç konu geliyor: Performans görüşmeleri, takım için geribildirimler ve müşteri geribildirimleri.
Kabul edelim performans görüşmeleri hiç bir işe yaramıyor. Araştırmalar gösteriyor ki, yılda birkaç kez yapılan görüşmeler genel olarak görüşülen üzerinde yapıcı bir etki bırakmıyor, aksine kişiyi demotive ediyor. Kişinin yaptığı hata hakkına geribildirimi 5 ay sonra dinlemesi ona birşey ifade etmiyor.
Agile kültürde anında geribildirim şarttır. Her gün takımca paylaşılan fikirler, her 2 haftada bir farklı toplantılarla yenilenir. Kod gözden geçirilerek programlama hakkında anında geribildirim alırsınız. Değişik anketlerle farklı noktalara odaklanırsınız. Yani kısacası Agile kültürde yıllık performans görüşmelerinin etkisi en aza indirgenmiştir (hatta dünyada yıllık performans görüşmelerini yapmayı bırakan yüzlerce şirket vardır). Tabi öncelikle takım içinde güven ortamının oluşturulması ve iletişim yollarının açık olması şarttır.
Müşteriler ile yazılımın son durumunu düzenli olarak paylaşmak esastır. Ancak paylaşacağımız şey çalışan yazılım olmalıdır ki müşteri sürecin en az riskle ilerlediğini görebilsin ve kullanarak geribildirim verebilsin. Çalışan yazılım üzerinden geribildirim, yazılımın tasarımını ve geliştirilme süreçlerini olumlu etkilediği için de önemlidir.
12) Sürekli mesai yapmak yerine sürdürülebilir bir tempoda çalışmak
İş yoğunluğuna göre fazla mesai yapmak tabi ki normal karşılanabilecek bir durum. Ancak bunun çok nadir olması gerekir. Fazla mesai "proje yönetiminde ciddi bir zaaf olduğunun" göstergesidir ve yönetimce ciddi olarak ele alınması gereken bir problemdir. Extreme Programming değerleri fazla mesaiyi reddeder. Zaten kendimizi geliştirebilmek adına iş dışı anlara ihtiyaç duyan biz yazılımcılardan bu zamanı istemek, hem de el koyarcasına sürekli istemek, haksızlıktır. Sürdürülebilir tempoda çalışmak (sustainable pace) Agile kültürünün ana değerlerindendir.
Tabi ki kültürel değişimin ve gelişimin bir anda olması beklenemez. Adım adım planlanmalı, sürekli gözlenmeli ve "inspect & adapt" felsefesi ışığında hatalardan ders alınıp tekrar denenmelidir. Burada belirtmeye çalıştığım ve belirtemediğim tüm noktaları ayrıntılarıyla düşünmek ve disiplinden kopmamak gerekir. Çalışanların desteğini almış bir dönüşüm eninde sonunda başarıya kavuşacaktır.