Agile Teslimat Akışı: 3 adımda her zaman zamanında teslimat

Çoğu yöneticiye “psikolojik güvenlik” veya “vizyon” (daha fazlası için: Psikolojik güvenlik ) konusundaki görüşleri sorulduğunda, bu şeylerin önemli olduğu konusunda hemfikir olurlar, ancak… Müşteri aciliyet sinyali verdiğinde veya son teslim tarihi yaklaştığında, bu “daha yumuşak” değişkenlerin tümü tipik olarak geri plana itilir. Yöneticiler öncelikle çevik ekiplerinin öngörülebilir şekilde çalışan bir çevik teslimat akışıyla ilgilenirler.

Eğer Echometer blogumuza bir göz atarsanız ( blogumuza ) içinde gezindiyseniz, içeriğimizin daha çok ekiplerin ve kuruluşların “yumuşak becerilerini” geliştirmeye odaklandığını bilirsiniz. Bunlar, karar vericiler tarafından genellikle hafife alınır. Ancak Scrum Master’ları ve Agile Koçları tarafından değil.

Bana göre Scrum Master’ların ve Agile Koçlarının hafife aldığı şey ise, teslimat akışını iyileştirmeye odaklanmak; temelde yöneticilerin istediği şey. Bugünkü yazımda, tekrar tekrar zamanında ve bütçeye uygun teslimat yapma olasılığını önemli ölçüde artırmak için basit bir teknik açıklayacağım.

Agile Teslimat Akışınızla ilgili ilk adım

Görevlerinizin Agile teslimat akışını izlemekten bahsediyorum. Sadece birkaç şeyi doğru yaparsanız, çok daha öngörülebilir sonuçlar elde edebilirsiniz. Döngü süresi dağılım grafikleriniz veya proje tahminlerini hesaplamak için kullandığınız Monte Carlo simülasyonunuz bile sonunda tamamen yanlış olmak yerine geçerli tahminlere işaret edebilir (daha fazlasını okuyun: 9 Agile Karar vericiler için metrikler ).

Mücadele edilmesi gereken ilk belirti, “Planlandı “dan “Tamamlandı “ya sadece birkaç gün süren görevler ve bir aydan fazla süren görevler olmasıdır. Bunu önlemek için, bir görevin her zaman istenen özelliğin mümkün olan en küçük teslim edilebilir sürümünü içerdiğinden emin olmalısınız. Müşterinin temel talebi için gerekli olmayan ziller ve ıslıklar olmadan. Temel olarak bir MVT, Minimum Uygulanabilir Görev. Bu, her görevi küçük yapacağı anlamına gelmez. Ancak görevlerin aylar yerine en fazla birkaç hafta sürdüğü bir aşamaya ulaşmanıza yardımcı olmalıdır.

Agile Teslimat Akışınızla ilgili ikinci adım: Hız yerine WIP

Birçok Scrum Master veya Kanban Koçu, hız vb.‘nin geçerli bir şekilde ölçülmesi için, tüm iş öğelerinin लगभग aynı boyutta olduğu görevlerin veya iş öğelerinin “doğru boyutlandırılması”nın önemli olduğuna inanır. Yalnızca o zaman, hikaye puanları (hızı ölçmek için gereken) hızın ölçülmesinde kullanılabilir olur, çünkü daha çok karşılaştırılabilir bir zaman birimi gibi görünürler. 

Ancak bu yanlıştır: görevlerin benzer boyutta olması bile gerekmez. Bunu varsaymamalısınız, çünkü Story Point tahminlerini kontrol etmek çok zordur. Kontrol edebileceğiniz tek şey kaç tane yeni görev başlattığınızdır.

Öyleyse, öngörülebilir olmak için aşağıdakileri yapın: “Yeni başlanan görevler” oranını “tamamlanan görevler” oranıyla karşılaştırarak izleyin. Bu ikisi dengede olmalıdır. Başka bir deyişle, görevlerin “giriş” ve “çıkış oranı” birbirine mümkün olduğunca yakın olmalı, ideal olarak aynı olmalıdır.

Bir örnek: Yazılım geliştirme ekiplerindeki tipik davranış, bir görev engellenir engellenmez yeni bir iş öğesinin başlatılmasıdır. Bu durum birçok görevin açık ancak tamamlanmamış olmasına yol açar ve bu da hepsinin engelini kaldırmayı çok daha karmaşık hale getirir. 

Bunun yerine, başlanan her görev için tamamlanan bir görev olduğundan emin olursanız, günlük toplantıda birkaç odaklanmış görevin kilidini açmak daha iyi olacaktır. Genel performansınız daha hesaplanabilir hale gelecek ve amiriniz ve müşterileriniz daha mutlu olduğu için ekip daha memnun olacaktır.

Sağlıklı bir çevik Agile Teslimat Akışının bazı “olumlu belirtileri”

Uygulamada bu durum aşağıdaki davranışlara yol açacaktır:

• • Hâlâ devam eden birçok iş varken yeni görevlere başlamayız. 

• • Yeni şeylere başlamadan önce başladığımız işi bitirmeye odaklanıyoruz.

• • Görevlerin yaşı hiçbir zaman birkaç haftayı geçmez.

• • İyi bir neden yoksa, her zaman en eski görev üzerinde çalışırız.

WIP (devam eden iş) sınırları da bu konuda yardımcı olur, ancak genellikle yeterli değildir. Ekip, yeni görevlere başlamak yerine görevleri bitirmeye odaklanmayı öğrendiğinde, çoğu ekipten daha iyi olacaksınız.

Agile Teslimat Akışını doğru kullanırsanız

Net beklentiler yaratmak için: Bu şekilde bir görevin iki ya da üç gün sürüp sürmeyeceğini kontrol edemezsiniz. Ancak en azından ekibinizin 2-3 günlük görevlerin bir ay sürmesine neden olacak kadar çok görev üzerinde çalışmadığından emin olursunuz.

Temelde tüm teslimat yükümlülüklerinin birkaç hafta içinde yerine getirileceğini bilseydiniz ekibiniz ne kadar daha iyi olurdu? Elbette bu, yukarıda bahsedilen her şeyi uyguladığınızı varsayar: MVT’lerin belirlenmesi, katı bir WIP limiti ve başka bir görev tamamlanana kadar görevleri yeniden başlatmama taahhüdü.

Adım 3: Agile teslimat akışını iyileştirmeye başlayın

Teoride ne yapmanız gerektiğini biliyorsunuz. Pratik olarak başlamanın en iyi yolu nedir? Ekipte farkındalık ve “değişim istekliliği” yaratarak. En iyi ihtimalle öz-düşünme yoluyla.

Bu sayılar konusunda şeffaf olmanız ve başlatılan ve tamamlanan görevler arasındaki oranın dengede olup olmadığını görmek için bunları düzenli olarak kontrol etmeniz gerekir. Biraz daha derine inmek ve son döngüde rakamların neden dengede olmadığını düşünmek retrospektifinizin bir parçası olabilir. 

Bahsettiğim davranışları çevik retrospektif aracımız Echometer ile retrospektifinizde tartışmanızı tavsiye edebilirim (daha fazlasını okuyun: 7 Karşılaştırmalı Geriye Dönük Araçlar ). Hatta bu soruları düzenli olarak sorarak farkındalığı artırmak için bunu çalışma anlaşmalarınızın veya düzenli Health Check’lerinizin bir parçası haline getirebilirsiniz.

Aşağıdaki sorular, “çevik teslimat” için retrospektif şablonumuzdur (daha fazlası için: Çevik retrospektifler için 22 eğlenceli şablon ). Birkaç Health Check ifadesiyle başlıyoruz ve ekibe katılma ya da katılmama eğiliminde olup olmadıklarını soruyoruz. Bundan sonra, birkaç açık soru var:

Agile Teslimat Geçmişe Dönük

Health Check Öğeleri

Çalışma şeklimiz ne zaman optimal olmayan bir iş akışına yol açtı? (örn. net olmayan, uygunsuz veya takip edilmeyen kılavuzlar)

Tahmin edebileceğiniz gibi, sağlık kontrolünün son noktası (nedeni kontrol etme) zaten potansiyel bir önlem anlamına geliyor; size yardımcı olup olmadığını görmek için bir veya iki çevik sprint için deneyebileceğiniz bir şey: “Devam Eden İş” durumundaki görevlerin sayısını sınırlamak.

Temelin atılması: Ekip çalışması için anlaşmalar yapın

Ekibinizin bu tür bir yansıma için henüz hazır olmadığını mı düşünüyorsunuz? Bu durumda, öncelikle genel olarak “iyi iş” hakkında düşünmeli ve ardından bazı temel kurallar, yani çalışma anlaşmaları belirlemelisiniz. Aşağıdaki atölye şablonu size yardımcı olabilir. Bunu bir projenin başında özel bir retrospektif biçimi olarak veya ek bir atölye olarak gerçekleştirebilirsiniz.

Öncelikle ekibinizin örtük olarak ne kadar aynı fikirde olduğuna dair bir fikir edinmelisiniz - bunun için sağlık kontrolü öğesine bakın. Ardından bunu birkaç açık uçlu soruyla pratik olarak kontrol etmelisiniz. Her ekip üyesi (daha fazla soruya bakın) cümleyi aklına gelen mümkün olduğunca çok yanıtla bitirmelidir:

Takım Taahhütleri Geçmişe Dönük

Health Check Öğeleri

Çatışmalarla başa çıkma: ‘Ekibimizde bir çatışmanın ortaya çıktığını fark edersem, o zaman …’

Yanıtları topladıktan sonra, elbette kalıpları bulmaya çalışmalı ve gelecekte nasıl birlikte çalışacağınız konusunda somut anlaşmalara varmalısınız - en azından geçici olarak bir deney olarak.

İlginç, yaratıcı bir alternatif

Bu retrospektif yöntemleri size “çok kuru” geliyorsa, ekibinizin çıktısının kalitesini yansıtmaya odaklanan başka bir retrospektif yöntemi daha var ( Eğlenceli 54 Geriye Dönük Yöntemlere buradan ulaşabilirsiniz ): ‘Üç Küçük Domuz’ Retrospektifi. Farklı malzemelerden evler inşa eden üç küçük domuzun masalına dayanan, performansınızı yansıtmaya ve geliştirmeye başlamak için basit bir alternatiftir.

Sonuç - Çevik Teslimat Akışı

Nasıl başlarsanız başlayın, en önemli şey ilk etapta başlamaktır. Agile teslimat akışını aktif bir şekilde takip eden ekipler daha iyi ekiplerdir.

Bu arada, burada bulduğunuz fikirlerin çoğu, şiddetle tavsiye edebileceğim “Agile Bites” adlı podcast’te de iyi bir şekilde özetlenmiştir (Podcast’e buradan ulaşabilirsiniz: Agile Isırıkları). 

Ekibinizi geliştirirken iyi eğlenceler!