Herkese merhaba, bu yazıda sizlere sektör veya uzmanlık farketmeksizin iki günde uçtan uca nasıl "Agile" olursunuz anlatmayacağım.

Aksine bir argüman baz alarak konuya tersten bakmaya çalışacağım.

Önyargılarla süslenmiş nacizane argümanım:

Bilhassa Türkiye'de, "Agile" dönüşümlerinde uygulanan metodoloji yanlış anlaşılıp / yorumlanıp süreçlerin, özellikle ve en çok geliştiricilerin kötü etkilenmesine neden oluyor.

Böyle bir argümanın arkasında neler var peki?
"Metodoloji yanlış uygulanırsa ne olur?" öğrenimini edinmek, kişisel deneyimler ve AgileTurkey'den araştırma sonuçları.

Not: Şunu önden belirtmekte fayda olduğunu düşünüyorum, bu yazıyı çıkarırken yararlandığım kaynakların "The Manifesto for Agile Software Development" yazarları olmasına özen göstermeye çalıştım.

# Biraz başa saralım

# Teori

Yönetim teorilerindeki en önemli gelişmeler 20. yüzyılda gerçekleşmiştir. Günümüzdeki insan yönetim biçimlerine dair bilgimizin ve uygulamalarımızın çoğu bu dönemin teorisyenleri tarafından üretilmiştir.

Bu yüzyılın ilk teorisyenlerinden birisi olan Frederick Winslow Taylor, "Bilimsel Yönetim Hareketi" adı altında iş arkadaşlarını toplayarak çalışma sürecini bilimsel olarak inceleyen ilk topluluğun liderliğini yapmıştır.

1909 yılında yayınladığı "Bilimsel Yönetimin Prensipleri" (The Principles of Scientific Management) kitabında Taylor, işler sadeleştirilerek optimize edildiğinde verimliliğin artacağını savunmuştur. Ayrıca bu argümanını çalışanlar ve yöneticilerin sürekli iletişimde / iş birliği içinde olması gerektiği ile genişletmiştir. Bunları şimdi okuduğumuzda çok normal gelebilir fakat o dönemde bir fabrika yöneticisi ile çalışanın arasındaki iletişim oldukça kısıtlıydı.

Bir Makine Mühendisi ve verimlilik konusuna kafayı takmış olan Taylor kariyerinin ilerleyen dönemlerinde de geliştirdiği bilimsel metodolojiyi uygulamış ve bir işi tamamlamanın en iyi yolunu o iş için kullanılan çeşitli elementler üzerinde harcanan zamanı hesaplayarak bulunabileceğini savunmuştur. Bunlara bağlı olarak bazı prensipler geliştirmiştir ve bugün "Taylorizm" (Taylorism) olarak bilinen aşağıdaki prensipler ortaya çıkmıştır:

• Görevleri en verimli şekilde yerine getirebilmek için eski alışılmış ya da "göz kararı" usuller bir kenara bırakılarak bilimsel yöntemler geliştirilmeye çalışılmalıdır.
• İşlere çalışanları rastgele yerleştirmek yerine motivasyon ve yeterlilikleri göz önünde bulundurularak bu işler dağıtılmalıdır. Bu çalışanlar maksimum verimliliği korumak adına sürekli eğitilmelidir.
• Çalışanların iş yapışları gözlemlenmeli, uygulanabilecek en verimli yolları kullandıklarından emin olunmalı, aksi takdirde gerekli eğitim ve bilgi sağlanmalıdır.

Bilimsel Yönetim Teorisi bugün bizim bahsedeceğimiz konularla buraya kadar tamamen ilgili. Fakat biz takım çalışmasından da bahsedeceğimiz için Taylor'dan bu noktada ayrılacağız, çünkü Taylorizm işlerin bireylere indirgenecek küçüklükte parçalara bölünerek değerlendirmesi gerektiğini savunmuştur.

Günümüzde "Agile" konusunda bir şeyler bildiğini savunan herkesin Frederick Taylor ve teorisi hakkında en az buraya kadar aktardıklarımızı bilmesini beklemek oldukça doğal, çünkü Manifesto yazarlarından biri olan Martin Fowler'ın da bahsettiği üzere "Agile Hareketi" içerisinde bu teorinin etkisi oldukça görülür.

# 1. Manifesto & Metodoloji

- The Manifesto for Agile Software Development, it says on the website what it's called but that's not what people called it, people called it The Agile Manifesto and this is the root of all the evil that has followed...
GOTO 2015 • Agile is Dead • Pragmatic Dave Thomas

Benim kötü çevirimden geçmiş hali:

- "Çevik Yazılım Geliştirme Manifestosu", web sitesinde böyle diyor, fakat insanlar bu şekilde kullanmadı, insanlar "Çevik Manifesto" demeyi tercih etti ve bu o zamandan beri yaşanan bütün kötülüğün asıl nedeni...

# 1.1. Koca bir sektör (Agile Indu$trial Complex)

Bizdeki karşılığı “Çevik Yazılım Geliştirme” olan bu felsefenin hızlıca yayılması haliyle yeni bir iş alanı doğurdu. Scrum Alliance önderliğinde verilen eğitimlerle bugün piyasada mesleği Agile Coach/Trainer olan binlerce insan var. Hatta bana sorarsanız yoga antrenörleri ile yarışır sayıdalar.

Eylül 2016 sonuçlarına göre sektörde 388.000 sertifikalı Scrum Master ve 82,000 sertifikalı Product Owner bulunuyor. (Bu sayılar da takımların %80'inin sertifikalı bir eğitim almamış Product Owner'a sahip olduğunu gösteriyor.)

Bu noktada birkaç şeye değinmek gerekiyor. İçerisinde her biri birbirinden farklı geliştiricileri bulunduran, birbirinden farklı dinamikleri olan yazılımları geliştiren, birbirinden farklı yazılım geliştirme takımlarına her şeye uyacak tek bir çözüm sunamazsınız. "Bakın Agile yaklaşımı böyle böyle yaparak uygulanır, hadi gidin oynayın şimdi!" diyemezsiniz. Belki bir takım "Daily Scrum" aktivitesini sadece yazışarak gerçekleştirdiğinde tam verimini alıyordur. Bence verilen eğitim yaklaşımı en dış hatlarıyla aktarmaktan öteye geçmemelidir.

# 1.2. Şirketlerin yüzü gülüyor

Bu eğitimlerin çoğu ülkemizde merdiven altına düşmüş yabancı dil eğitimleri gibi değil, gerçek anlamda iyi. Bu yönde gelişmeyi amaçlamış çoğu organizasyon/şirket uygulanan eğitim ve metotlar ne kadar yetersiz ya da başarız olursa olsun günün sonunda gelişme kaydedecektir.

AgileTurkey'in Türkiye 5. Çeviklik Raporu sonuçlarına göre yazılım geliştirme yaklaşımı olarak ülkemizde ilk üç kullanım aşağıdaki şekilde:

1. Scrum
2. Waterfall
3. Kanban

Daha önce yayınlanan raporlardaki sonuçları incelersek öncelikle Waterfall'dan Scrum ve Kanban'a doğru bir geçiş olduğunu gözlemleyebiliriz.

Aynı raporda agile metodolojilerini uygulayan şirketlerin getiriler bölümündeki sonuçlardan ilk ikisi şu şekilde:
(bu yüzdelerin belirttiği durum önceki sisteme göre belirtilen şeyin daha iyi bir boyutta olması)

1. Değişen öncelikleri yönetme kabiliyeti kazanma (Gaining ability to manage changing priorities)
2. Verimlilik artışı (Increasing productivity)

# 1.3. Geliştiricilerin* yüzü gülüyor mu?

* Yazı boyunca kullandığım geliştiriciler kelimesi sadece yazılımcılar için bir kullanım değil, metodolojideki "development team" karşılığında kullandım.

AgileTurkey'in Türkiye 5. Çeviklik Raporu çıktılarını incelediğimde "Challenges and Kaizen Points" başlığı dikkatimi çekti.

"Varolan Agile Takımlarınızda Geliştirmeyi Düşündüğünüz Alanlar" kısmında ilk üç sonuca bakalım:

1. Kalite (Quality)
2. Takım çalışması (Team work)
3. Verimlilik (Productivity)

Birinci ve üçüncü sonucu direkt olarak etkileyen takım üyelerinin geliştiriciler olduğunu düşünürsek ilerleyişte bir sıkıntı var.

Konuya şirketlerde faaliyet gösteren geliştiriciler tarafından bakalım. Uygulanan bir agile metodolojisi başarısız ya da yetersiz olduğunda genel olarak ortaya çıkan sonuçlar şunlar oluyor; gerçek anlamda iş yapma zamanının kısalması, geliştiricilerin işine daha çok karışılması ve “daha hızlı ilerlemeliyiz!” nidaları. Bunun etkisi de iyi geliştiricilerin genellikle şirketleri terk etmesi olarak sonuçlanıyor.

Bu noktada Manifesto yazarlarından Ron Jeffries şunu belirtiyor:

- So it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better.
Ron Jeffries • Dark Scrum

Kötüye çalan çevirim ile:

- Geliştiricilerin hayatını kolaylaştırmasını amaçlayarak Agile Manifesto'ya yazdığımız bu fikirlerin tersine hayatlarını kötü etkilemesi kalbimi kırıyor.

# 2. Dark Scrum

- Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place.
This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do...
Martin Fowler • State of Agile 2018

Diyelim ki ben çevirdim:

- Bugün yaşadığımız problem Agile'ı insanların uygulamayı isteyeceği bir şey yapmaktan ziyade benim faux-agile dediğim değerleri ve pratikleri uygulanmayan sadece isimde agile olarak kalmış yanlışlık.
Aslında bu agile uyguluyormuş gibi yapmaktan daha kötü bir durum, bizim uygulamaya çalıştığımız temel prensiplerin karşısında durup "agile" adını kullanmak.

Şimdiye kadarki kısımda agile metodolojilerinin başarısız ya da yetersiz uygulanmasından bahsedip durdum. Bunu biraz açalım; Scrum her zaman ideal ve amaçlanan şekilde ilerlemediğinde Ron Jeffries'in "Dark Scrum" adını verdiği hastalık ortaya çıkıyor. Peki Dark Scrum'ın semptomları nedir?

Nacizane gözlemlerim ve tamamen özgüvenime dayanarak söylüyorum, bir ekip Scrum uygulamaya başladığında az kişi eğitimini almış hatta daha da azı gerçek anlamda ne olduğunu anlamış oluyor. Buna rağmen ekipteki çoğunluk ne yaptığını bildiğini sandığında problem ortaya çıkıyor. Yani aslında böyle bir ekibin süreci yanlış götürmesi şaşırılmaması gereken bir durum.

- Dark Scrum begins when people who know their old job, but not their new Scrum job, begin to do the Scrum activities.
Ron Jeffries • Dark Scrum

Yine ben ve kötü çevirim:

- Dark Scrum kişiler Scrum aktivitelerini eski işlerinin bilinciyle yaptığında ortaya çıkar.

# 2.1 Kendi kendini organize edememek

Scrum'ın içinde geliştiricilerin kendi kendini organize etmesi (self-organising) vardır. Ne yazık ki şimdiye kadar geleneksel yazılım geliştirme yöntemleri ile çalışmış bir ekip için özellikle bu bir günde kazanılan bir yetkinlik değil, ciddi anlamda zaman alabilir.

Product Owner, takım lideri ve bazen hatta Scrum Master rollerini almış kişilerin yapması gereken neyin yapılacağını açıklayıp ekip üyelerinin kendi kendilerine organize olmasını izlemek iken bu kişiler eski yöntemlerden kopamadığında Scrum içindeki görevlerini de takımda kimin ne yapması gerektiğine karar vermek olduğunu zannediyor.

Developers do not automatically know how to produce running tested software every two weeks. They have to learn, which means they need training and coaching. That training and coaching, today, is time consuming and expensive, and very few organizations provide it. Very few organizations even give developers time to search it out on their own.
Ron Jeffries • Imposition and Dark Agile

Oysa ben diyecek olsam:

Geliştiriciler birden bire test edilmiş çalışan bir ürünü her iki haftada bir ortaya çıkaracaklarını bilemezler. Bunu nasıl yapacaklarını gerekli eğitim ve rehberliklerle öğrenmeleri gerekir. Günümüzde bu uygulamalar zaman alıcı, pahalı ve oldukça az organizasyon bunu sağlıyor. Hatta çok az organizasyon geliştiricilere bunu araştıracak zaman veriyor.

# 2.2 Scrum Aktivitelerinin yanlış ilerlemesi

# Daily

Agile kültürü altında çalışan çoğumuzun bildiği üzere “Daily Scrum” ya da “Daily Stand-up” aktivitesi ile güne başlarız. Amaç belirlenen kısa bir süre içerisinde ekip üyelerinin bir önceki gün ne yaptığı, o gün ne yapacakları ve risk taşıyan bir durum var mı aktarımıdır. İdeal bir aktivite bu şekilde ilerler. Dark Scrum’da bu durum Product Owner’ın kimin neyi yapmasını söylediği bir aktivite olmasıdır. Bu problemin ekibin yeterli eğitim ve bilince sahip olmaması gibi birkaç farklı sebebi olabilir. Geliştirici ne yapacağını kendisi belirlemediği için de bir önceki gün hiçbir zaman beklendiği gibi gitmemiş olur, bunun sonucunda ise genellikle başka şeyleri suçlama ve gerilim oluşması görülür.

# Planning

Günlük gerçekleşen bu aktivitede gördüğümüze yakın bir problem de “Sprint Planning” aktivitesinde yaşanabilir. İdealinde Product Owner’ın her Sprint başlamadan önce geliştiricilerle bir araya gelip ihtiyacı açıklaması ve geliştiricilerin bu ihtiyacı nasıl karşılayabileceğini tartıştığı bir aktivitedir. Dark Scrum’da Product Owner’ın direkt olarak ne yapılması gerektiğini söylediği, geliştiriciler bunu tartışmaya açmaya çalıştığında da eski kötü yöntemlerden olan yönetici baskısının ortaya çıktığı bir toplantıya evrilmesidir. Planlama bu şekilde tamamlanınca haliyle Sprint sonunda elde edilen çıktı beklenen olmayabilir. Sorun yok, bunun için bir aktivite var; “Sprint Review”.

# Review

Her Sprint'in sonunda stakeholderlar takımın neleri tamamladığına bakıp ilerisi için yapılabilecekler hakkında öneriler sunarak rehberlik yaparlar. En azından teoride “Sprint Review” aktivitesinin bu şekilde gerçekleşmesi gerekir. Dark Scrum'da ise bu aktivite herhangi birinin takımın neyi yapmaya söz verdiğini belirterek başlar. Sonrasında çıkan sonucun ne kadar yetersiz olduğunun vurgulanması ile devam eder. Peki neden böyle oldu? Suçlu kim? Hiç sıkıntı yok, çünkü bunun için de bir aktivite var; "Sprint Retrospective".

# Retrospective

Ekibin süreçlerini iyileştirmesinde en etkili aktivite “Sprint Retrospective”dir; takımın önceki haftalarda nelerin iyi gittiğini, nelerin gitmediğini ve ilerisi için süreci nasıl iyileştirebileceği / geliştirebileceği tartışmaları üzerinden ilerler. Dark Scrum'da ise kendisini hala eski yönetici statüsünde gören kişiler takımla bu kadar yakın çalışmalarına rağmen başarısızlığın tamamen geliştiricilerin yavaşlığı üzerinde olduğunda dururlar. Hatta bazen takımın çıktılarının verimliliğini artırmak adına böyle devam etmesinin bazı "sonuçları" olacağından bahsederler, çünkü bu her zaman geliştiriciler olarak dikkatimizi vermemizi sağlar değil mi?

"Yaprak Dökümü" dramatikliğini burada bırakıyorum, Dark Scrum'ın ne olduğunu açıklamak için yeterli oldu bence.

Yazının başında da dediğim gibi uygulama Dark Scrum olduğunda en kötü etkilenen geliştiriciler oluyor. Manifesto ve Agile kültürü teoride geliştiricilerin daha rahat bir dünyaya sahip olması için ortaya koyulmuşken bu şekilde geri tepmelerin yaşanması ya da artık manifestonun yetersiz görülmesi de bazı sonuçlar çıkardı.

# 3. Craftsmanship

2009 yılında kendilerine "Yazılım Ustaları" diyen bir ekip Agile Manifesto üzerine "Çıtayı yükseltiyoruz." diyerek "Manifesto for Software Craftsmanship" adını verdikleri manifestoyu yayınladı ve katılan herkesi imzalamaya çağırdı. Şu anda 26,000 civarı imza bulunmakta.

Bu çıkışı bir kesim geliştiricilerin kendilerini agile kültüründen biraz soyutlamaya itmesi olarak görürken bir diğer kesim de manifestonun güncellenmesi olarak görüyor. Ben bu konuda biraz agnostik durmayı seçiyorum.

Bu başlığın biraz daha dibine inmek isterseniz yine sitede bir sürü kaynak bulunuyor, ben de özellikle Pete McBreen'in Software Craftsmanship kitabını okumanızı öneririm.

# 4. Agile'dan vazgeçelim!

Günün sonunda biz geliştiricileriz. Scrum, Kanban, SAFe, DAD, (şanslıysak) Extreme Programming... bu süreçlerin içerisinde yıpranmadan kalabilmemiz için isimlendirmelere takılmamız gerekiyor. Eskiden "bunlar business" diye dışladıklarımızla artık daha fazla iletişim içerisinde olduğumuz bir düzene doğru ilerliyoruz ve bir takım olmayı öğrenmeli, ürünün yazılım kısmına aşina olmalarını sağlayacak bağlantıyı kurmaya çalışmalıyız. Belki de her şeyden önce takım içi güven faktörüne önem vermeliyiz.

Yazının başındaki belirttiğim argümanımı da kırmak aslında çok zor değil; ürün dizaynını her zaman temiz tutmak, sürekli iyileştirmek ve geliştiriciler olarak herhangi bir teslim tarihine hazırlıklı olabilmek adına her zaman ürünün test edilmiş, entegre ve çalışan bir halini bulundurmak sürecin herhangi bir yerinde yıpranmamızı ya da kötü etkilenmemizi engelleyecek en büyük güç.

Yazıyı burada sonlandırırken aslında gerek sürecine yeni başlamış gerekse bir dönüşümden geçen geliştiriciler için akıl sağlığımızı korumaya yönelik hem teknik hem de business seviyede birkaç önerim olacak; Refactoring, Amazon two-pizza team, making the customer kick ass at what they do, Accelerate