Agile Hakkında Yanlış Bilinenler: Dokümansızlık, Plansızlık ve "Agile = Scrum"
Agile'da doküman, plan ve mimari vardır; Agile daha hızlı olmayı değil erken geri bildirimi vaat eder ve Scrum'la ya da Jira'yla eşit değildir. Yedi yaygın yanlışı manifestonun metniyle karşılaştırıyor, Fowler'ın Agile Industrial Complex eleştirisini, Dave Thomas'ın "agility" önerisini ve Dark Scrum'ı özetliyor, Bookstore'un bağlı olduğu şirketin "dönüşümü" üzerinden cargo cult Agile'ın belirtilerini listeliyoruz.
Sürüm notu: Bu yazı Agile Manifesto ve 12 prensibin (2001) metnini, Martin Fowler'ın 2018 tarihli "The State of Agile Software in 2018" konuşmasını, Dave Thomas'ın 2014 tarihli "Agile is Dead (Long Live Agility)" yazısını ve Ron Jeffries'in 2016 tarihli "Dark Scrum" yazısını esas alır.
Önce Tahmin Et
Bookstore'un bağlı olduğu şirket bir "Agile dönüşümü" başlattı. Altı ayda şunlar oldu: herkese Jira lisansı alındı, ekip liderleri Scrum Master sertifikası aldı, her ekip her sabah 09:30'da stand-up yapıyor, iki haftalık sprint'ler başladı, duvarlara manifesto posterleri asıldı. Release ise hâlâ üç ayda bir yapılıyor, geliştiriciler son kullanıcıyla hiç konuşmadı ve sprint'lerin kapsamını yönetim belirliyor.
Tahmin et: bu şirket Agile mi? Kontrol listesine bakılırsa evet: araç var, rol var, toplantı var, sprint var. Manifesto'ya bakılırsa? Bu yazı, ikisi arasındaki farkı yaratan yaygın yanlışları tek tek ele alıyor.
Yanlışlar ve Manifesto'nun Gerçekte Söyledikleri
Agile hakkındaki yanlışların çoğu, manifestonun metninden değil, o metnin üzerine yirmi beş yılda biriken anlatıdan geliyor. Her yanlışı metnin kendisiyle karşılaştırmak, tartışmayı görüşten belgeye taşıyor:
| Yanlış | Manifesto ne diyor? |
|---|---|
| Agile'da doküman yok | Çalışan yazılım kapsamlı dokümantasyona tercih edilir; sağdaki maddelerde de değer olduğu açıkça yazılı |
| Agile'da plan yok | Değişime cevap vermek bir planı izlemeye tercih edilir; plan var, ama değişebilir |
| Agile'da mimari yok | En iyi mimariler self-organizing ekiplerden çıkar ve teknik mükemmelliğe sürekli dikkat çevikliği artırır |
| Agile daha hızlıdır | Değerli yazılımın erken ve sürekli teslimi; hız değil, erken geri bildirim ve uyum |
| Agile = Jira | Bireyler ve etkileşimler süreçlere ve araçlara tercih edilir |
| Agile = Scrum | Manifesto hiçbir framework'ün adını anmaz; Scrum imzacıların temsil ettiği yöntemlerden yalnız biri |
| Agile yalnız küçük ekipler içindir | Manifesto ölçek hakkında bir şey söylemez; ölçeklendirme ayrı ve tartışmalı bir konu |
"Doküman Yok" ve "Plan Yok"
Bu ikisini serinin ilk yazısında değerler üzerinden ele aldık; burada ortak köklerine bakalım. İkisi de manifestonun değer cümlelerini sağdaki maddeleri yasaklayan kurallar gibi okumaktan geliyor. Okumanın sebebi de çoğu zaman pratik: doküman yazmak ve plan yapmak zahmetli işler ve "Agile'ız" demek onları yapmamanın meşru bir gerekçesi gibi görünüyor.
Bookstore'da bunun bedeli somut. Ödeme modülünün tek bir ADR'ı (Architecture Decision Record) yok; ekipten ayrılan geliştiriciyle birlikte "neden asenkron?" sorusunun cevabı da gitti. Çeyreklik bir hedef yok; her sprint bir önceki sprint'in bitmeyenleriyle doluyor ve Product Owner müşteriye "ne zaman?" sorusunun cevabını veremiyor. Agile'da plan, daha sık ve daha küçük yapılır; Scrum'da Sprint Planning, Product Goal ve Product Backlog bunun araçları. Tahmin ve uzun vadeli planlamanın teknikleri ilerideki Estimation ve Planning serisinin konusu.
"Mimari Yok": Emergent Design ve Big Design Up Front
Agile'ın tasarıma karşı olduğu yanlışı, XP'nin (Extreme Programming) BDUF (Big Design Up Front) eleştirisinden doğar. Eleştiri haklıdır: altı ay boyunca kod yazmadan tasarlanan bir mimari, gerçeklikle ilk karşılaştığında çoğu zaman yanlış çıkar. Ama eleştirinin alternatifi "hiç tasarım yapma" değil, emergent design: tasarımı ihtiyaç doğdukça, refactoring ve testlerin koruması altında büyütmek.
Emergent design her kararı ertelemek anlamına da gelmiyor. Bazı kararları değiştirmek pahalı: veritabanı motoru, kimlik doğrulama yaklaşımı, multi-tenancy modeli. Bunlar için önden yeterince düşünmek gerekir; serinin bir sonraki yazısı bu dengeyi architecture runway kavramıyla ele alıyor. Mimarinin ne olduğu ve hangi kararların mimari sayılacağı Mimariye Giriş serisinin "Yazılım Mimarisi Nedir? Design'dan Farkı ve Architect'in Rolü" yazısında.
"Agile Daha Hızlıdır"
Yönetim sunumlarında en sık duyulan vaat bu. Manifesto hız vaat etmez; erken ve sürekli değer teslimi ister. Fark önemli: Agile bir ekip yanlış şeyi daha erken fark eder ve daha az boşa iş yapar, ama aynı kapsamı aynı ekiple Waterfall'dan daha kısa sürede bitireceği garanti değildir.
Üstelik geçiş döneminde çoğu ekip yavaşlar. Diana Larsen ve James Shore'un Agile Fluency Model'i bunu açıkça yazar: teslim odaklı bir ekip olmak için yapılan yatırımın bir parçası, yeni beceriler öğrenilirken çıktının geçici olarak düşmesini kabul etmektir. "Agile'a geçtik, neden hızlanmadık?" sorusu, yanlış bir vaadin sonucudur.
"Agile = Jira" ve "Agile = Scrum"
Agile'ı bir araçla eşitlemek, birinci değeri tersine çevirmek demek. Jira, Azure Boards ya da GitHub Projects işi görünür kılmak için iyi araçlar; ama board'daki kartlar ekip içinde konuşmanın yerine geçtiğinde araç süreci, süreç de insanları yönetmeye başlar.
Scrum ile eşitlemek ise daha yaygın bir yanlış. Scrum en yaygın Agile framework'ü, ama manifesto onu ya da herhangi bir framework'ü anmaz. Snowbird'de XP, Scrum, DSDM (Dynamic Systems Development Method), Crystal, FDD (Feature-Driven Development) ve başka yöntemlerin temsilcileri vardı. Bugün bir destek ekibi için Kanban, Scrum'dan daha uygun olabilir; bir ekip hiçbir framework adı kullanmadan da manifestonun değerleriyle çalışabilir. Scrum'ın kendisi Scrum serisinde, akış odaklı alternatif Kanban serisinde.
Eleştiriler: Agile Industrial Complex, "Agile is Dead" ve Dark Scrum
Bu yanlışları en sert eleştirenler, manifestoyu yazanların kendisi oldu. Martin Fowler 2018'deki Agile Australia konuşmasında "Agile Industrial Complex" dediği şeyi eleştirdi: danışmanların ve araç satıcılarının ekiplere hazır bir süreci dayatması. Fowler'a göre ekipler kendi çalışma biçimlerini seçmeli ve sürekli uyarlamalı; ayrıca Agile toplantılarında teknik mükemmellik ihmal ediliyor ve ekipler projelere değil, uzun ömürlü ürünlere göre organize olmalı. Agile adını taşıyıp değerlerini taşımayan çalışmayı "faux-agile" diye anıyor.
İmzacılardan Dave Thomas 2014'te daha da ileri gitti ve "Agile" kelimesinin pazarlama tarafından ele geçirildiğini, artık bir yöntemi değil bir satış vaadini anlattığını yazdı. Önerisi sıfatı bırakıp isme, "agility"ye dönmekti ve bunu dört adımlık bir döngüyle tarif etti: nerede olduğunu anla, hedefe doğru küçük bir adım at, öğrendiğine göre anlayışını güncelle, tekrarla. Seçenekler eşit değerdeyse, gelecekteki değişikliği kolaylaştıranı seç.
Ron Jeffries ise 2016'da "Dark Scrum" adını verdiği durumu anlattı: Scrum'ın event'lerinin eski komuta-kontrol alışkanlıklarıyla doldurulması. Daily Scrum'ın bir durum sorgusuna, Sprint Planning'in ekibe iş yığmaya, Review'ın "söz verdiğinizi yapmadınız" toplantısına dönmesi. Dark Scrum ve Zombie Scrum'ın ayrıntısı Scrum serisinin "Scrum Anti-Pattern'leri: Dark Scrum, Zombie Scrum ve Mini-Waterfall Sprint'ler" yazısında.
Cargo Cult Agile'ın Belirtileri
Cargo cult, bir şeyin dış görünüşünü taklit edip işleyişini taklit etmemek demek; Richard Feynman bu benzetmeyi 1974'te bilimin biçimini taklit eden çalışmalar için kullanmıştı. Yazının başındaki şirket bunun ders kitabı örneği. Kendi ekibinde şu belirtilere bak:
- Stand-up bir durum raporu: herkes yöneticiye dönüp dün ne yaptığını anlatıyor.
- Sprint'ler var ama release takvimi değişmedi; çıktı yine çeyrekte bir kullanıcıya ulaşıyor.
- Sprint review'da çalışan yazılım değil, slayt gösteriliyor.
- Retrospective aksiyonları bir sonraki retrospective'de aynen tekrar yazılıyor.
- Velocity ekipler arasında karşılaştırılıyor ve performans değerlendirmesinde kullanılıyor.
- Geliştiriciler son kullanıcıyla hiç konuşmuyor; Product Owner bir aracı değil, bir duvar.
Her belirtinin ortak noktası, bir pratiğin biçiminin korunup amacının kaybolması.
Üretimde Dikkat
Ritüelleri amaçlarıyla birlikte tanımla. Bookstore ekibi her toplantı için tek bir soru yazdı ve toplantının sonunda bu soruya cevap verilip verilmediğine bakıyor: Daily Scrum için "Sprint Goal'a ulaşmak için bugün planı nasıl değiştiriyoruz?", Review için "kullanıcıdan ne öğrendik ve backlog'u nasıl değiştiriyoruz?". Cevap yoksa, toplantı biçimden ibaret kalmıştır.
Dönüşümü pratik değil, sonuç üzerinden ölç: release sıklığı, change lead time, kullanıcı geri bildiriminin backlog'a girme süresi. Bu metric'lerin çoğu SDLC (Software Development Life Cycle) serisinin beşinci yazısında anlatılan DORA (DevOps Research and Assessment) metric'leriyle örtüşüyor.
Sık Düşülen Tuzaklar
Ritüelleri değerlerin yerine koymak en temel tuzak. Stand-up, sprint ve board birer araç; değerleri hayata geçirmezlerse yalnız takvimde yer kaplarlar.
İkincisi, eleştirileri "Agile başarısız oldu" diye okumak. Fowler'ın, Thomas'ın ve Jeffries'in eleştirileri manifestoya değil, manifestonun adıyla satılan uygulamalara yönelik. Üçü de değerlerin hâlâ geçerli olduğunu savunuyor.
Üçüncüsü, mitlerle savaşırken ters uca düşmek: "Agile'da doküman var" diyerek 80 sayfalık tasarım dokümanlarına geri dönmek. Manifestonun cevabı bir denge, bir sarkaç değil.
Küçük Bir Deneme
★☆☆ Tablodaki yedi yanlıştan hangisini ekibinde en son duydun? Söyleyen kişiye manifestonun ilgili cümlesini göster ve tartışmanın nasıl değiştiğine bak.
★★☆ Cargo cult belirtileri listesini ekibinle birlikte gözden geçir. Kaç belirti var ve her biri için pratiğin asıl amacı neydi?
★★★ Ekibinin her tekrarlayan toplantısı için tek bir soru yaz ve sonraki iki sprint boyunca her toplantının sonunda o soruya cevap verilip verilmediğini kaydet. Hangi toplantı biçime dönüşmüş?
Yanlışları ayıkladık; geriye zor kısım kalıyor. Bir sonraki yazıda Agile'ın gerçek dünyayla karşılaştığı yerlere bakıyoruz: sabit fiyatlı sözleşmeler, değişmeyen deadline'lar ve geri alınması pahalı mimari kararlar.