Çevik Metodolojilerin Uygulanması

Bir ekip iki haftalık sprintlerle çalışıyor, her sabah on beş dakikalık daily yapıyor, backlog'u Jira'da düzenli tutuyor. Ama bir özelliğin fikirden müşteriye ulaşması dört ay sürüyor, çünkü her sprint sonunda çıkan şey bir sonraki kurulun onayını bekliyor ve test ayrı bir ekibin takvimine bağlı. Takvim çevik; iş değil.

Çevik yazılım geliştirme bildirgesi 2001'de yazıldı ve dört değer önerdi: süreçlerden çok insanlar ve etkileşim, kapsamlı dokümantasyondan çok çalışan yazılım, sözleşme pazarlığından çok müşteriyle işbirliği, plana uymaktan çok değişime yanıt. Bu cümleler bugün çoğu ekipte bir ritüel setine indirgenmiş durumda. Bu yazı, o ritüellerin altında yatan mantığı ve onu yok eden alışkanlıkları ele alıyor; kurumsal ölçekte çevik yönetişim (strateji 88) ayrı bir konu.

Ne zaman ihtiyacınız var?

Sinyaller: proje bittiğinde ihtiyaç değişmiş oluyor. Geliştirme ile iş birimi arasında “teslim ettik ama istediğimiz bu değildi” tartışması sürekli. Büyük bir sürüm, uzun bir kod dondurma ve riskli bir yayın gününe bağlı. Ekip, önceliklerin her hafta değiştiğinden şikâyet ediyor ama aslında önceliği kimin belirlediği net değil. Rakipler küçük ve sık yayın yapıp müşteriden daha hızlı öğreniyor.

Henüz erkense: işin gerçekten belirsizliği yoksa. Örneğin yasal bir uyum projesinde ya da fiziksel bir inşaatta ihtiyaç ve çıktı önceden bellidir; bu durumda plan odaklı bir yaklaşım daha mantıklı olabilir. Ayrıca iki kişilik bir kurucu ekibin sprint ritüeline ihtiyacı yoktur; orada yeterli olan, haftalık net bir öncelik ve açık iletişimdir.

Çoğu ekibin atladığı nokta

Çevik, bir takvim ve bir dizi toplantı olarak öğretilir ama özünde iki şeydir: geri bildirimin hızı ve karar yetkisinin yeri.

Geri bildirim hızı şu demek: yaptığınız şeyin doğru olup olmadığını ne kadar çabuk öğreniyorsunuz? Sprint sonunda çıkan ve kimsenin kullanmadığı bir özellik, takvim açısından başarıdır, öğrenme açısından kayıp. Çevik bir ekibin ölçütü teslim edilen iş değil, gerçek kullanıcıdan alınan sinyaldir.

Çevik olmak, plana ne kadar iyi uyduğunuzla değil, planın yanlış olduğunu ne kadar erken fark ettiğinizle ölçülür.

Karar yetkisi ise daha az konuşulan ama daha önemli taraf. Ekip her küçük karar için üst onay bekliyorsa, sprint ritmi yalnızca bekleme süresini düzenli hale getirir. Çevik ekip, müşteriye en yakın kişilerin ürün kararlarını verebildiği ve bunun sonuçlarına katlandığı bir ekiptir. Ürün sahibinin yalnızca backlog sekreteri olduğu bir yapı çevik değildir.

Üçüncü yanılgı, hız ile esnekliği karıştırmaktır. Çevik olmak daha hızlı yazmak değil, daha küçük adımlarla ilerleyip yön değiştirebilmektir. Bunu sağlayan şey teknik pratiklerdir: otomatik test, sürekli entegrasyon, küçük ve sık yayınlar. Bunlar olmadan sprint, aynı büyük işi iki haftalık dilimlere bölmekten ibaret kalır.

Uygulama planı

1. Önce problemi tanıyın

Ekibin bugün nerede yavaşladığını bulun: fikirden müşteriye kadar bir işin geçtiği adımları ve her adımdaki bekleme süresini çıkarın. Çoğu zaman gecikme kodlamada değil, onayda, testte, yayın penceresinde ya da bir bağımlı ekipte ortaya çıkar. Hangi çevik uygulamanın gerektiğini bu harita belirler.

2. Karar yetkisini ekibe indirin

Bir ürün sahibi ve küçük, çok yetenekli bir ekip belirleyin: geliştirici, tasarımcı, test, gerekirse veri uzmanı bir arada. Ekibin, belirli bir alanda onaysız karar verebileceği sınırı yazın: örneğin belirli bir bütçe altında ve belirli bir metriği hedefleyen her değişiklik. Yetki yazılı değilse, ekip yine bekler.

3. Hedefi çıktı değil sonuç olarak koyun

“Şu on özelliği çıkarmak” yerine “ilk haftada aktif olan kullanıcı oranını yükseltmek” gibi bir sonuç hedefi verin. Backlog bu hedefe hizmet eden hipotezlerden oluşsun. Her sprintin sonunda “ne öğrendik?” sorusuna cevap veren bir demo yapın; demoya yalnızca ekip değil, gerçek kullanıcı ya da müşteriye yakın biri katılsın.

4. İş akışını sınırlayın

Aynı anda yürüyen iş sayısını düşürün. WIP limiti koymak, tamamlanmamış işlerin yığılmasını engeller ve darboğazı görünür kılar. Bir işin bir sütunda uzun beklediğini görürseniz, sorun orada. Başlayan işi bitirmek, yeni iş başlatmaktan daha değerlidir.

5. Teknik pratikleri kurun

Otomatik test, sürekli entegrasyon, tek tıkla yayın ve geri alma. Küçük ve sık yayın yapabilmek, çevik yaklaşımın teknik temelidir. Bunlara yatırım yapmayan bir ekip, ritüel yürütür ama hız kazanmaz.

6. Retrospektifi gerçek bir karar noktasına çevirin

Her retrospektif en fazla iki somut değişiklikle bitsin; her değişikliğin sahibi ve bir sonraki kontrol tarihi olsun. Retro'da konuşulan ama hiçbir şeyi değiştirmeyen toplantı, ekibe öğrenilmiş çaresizlik öğretir.

Neyi ölçmeli?

• Döngü süresi (cycle time) (öncü): bir işin başlamasından müşteriye ulaşmasına kadar geçen medyan süre. Çevikliğin en dürüst göstergesi.
• Yayın sıklığı ve değişiklik başarısızlık oranı (öncü): DORA araştırmasının önerdiği metriklerin ikisi; hız ve kalitenin birlikte nasıl gittiğini gösterir.
• Müşteriye ulaşan işin sonuca etkisi (gecikmeli): yayınlanan değişikliklerin kaçı hedef metriği kıpırdattı?
• Plansız iş oranı (öncü): ekip kapasitesinin ne kadarının acil işlere gittiği. Yüksekse sprint planlaması sadece bir temennidir.

Tuzaklar

Çevik tiyatro. Daily, sprint planlaması, retro yapılıyor; ama karar yetkisi ve yayın sıklığı aynı kalıyor. Ritüelleri sayın değil, bekleme süresini ölçün.

Ürün sahibini sekreter yapmak. Kararı veremeyen bir ürün sahibi, ekibin önüne istek listesi koymaktan öteye gidemez. Yetki olmadan rol bir etiketten ibarettir.

Her şeyi çevik yapmak. Çevik, belirsizliğin yüksek olduğu işte değer üretir. Belirsizliği düşük, bağımlılığı yüksek bir işte (örneğin bir altyapı geçişi) planlı bir yaklaşım daha doğru olabilir.

Çerçeve tapınması. Scrum, Kanban ya da SAFe, bir araçtır. Çerçeveyi yönetmek için çerçeve eğitmeni tutmak, asıl problemi, yani yavaş geri bildirimi, çözmez.

Bu hafta başlayın

1. Son tamamlanan beş işin fikirden müşteriye kadar geçen sürelerini çıkarın ve her birinde en uzun beklemenin nerede yaşandığını işaretleyin.
2. Ürün sahibi ile bir saat oturun ve ekibin onay almadan karar verebileceği üç alanı yazılı hâle getirin.
3. Bir sonraki sprint hedefini özellik listesi yerine ölçülebilir bir kullanıcı sonucu olarak yeniden yazın ve sprint sonu demosuna bir gerçek kullanıcı çağırın.