Kaizen Seansları: İyileşme İçin Farkındalık (Kumbara Takımı)

*Gerçek verilerden ve deneyimlerden yola çıkılarak paylaştığım bu yazıda takım ismi bilinçli olarak değiştirilmiştir.

Kumbara Takımı

Her şeye yetişmek için kendinden ödün veren 10 kaplan gücünde bir kişiliktir kendisi. Kendi sistemini kurmak istemesinden yola çıkarak birlikte çalışmaya başladık fakat kurum içi başka önceliklerden dolayı yarıda kalan bir serüven yaşadık. Gösterdiği çabadan dolayı buradan da teşekkür etmek istedim.

Burada yazacaklarım tamamıyla dışarıdan bir bakış açısı sağlamak ve başka noktalardan da yorumlar almak. Her ne kadar yorum yapmaya çalışsam da eksik kalacaktır. Önemli olan ekibe daha iyisini konuşabilecekleri tartışabilecekleri bir ortamın kurulmasına yardımcı olabilmek; bir geri-dönüş mekanizması yaratabilmek. Bu grafikler ile takımın kendi karar verme mekanizmasını desteklemesini ve doğru kararlar alabilmesini görmek öncelikli hedeftir.

Özet

Bu rapor aşağıda belirtilen durumları irdelemek için yazılmıştır.

• Sürüme çıkış oranları ağustos – ekim arasında 3 kat nasıl artmış?
• Sürüme hazır hale gelme oranları temmuz – eylül arasında 4 kat artarken sonradan neden düşmüş?
• Müşteri gözünden bakıldığında ağustos ayında görülen dalgalanmanın sebebi ve devam etme durumu nedir?
• Çeyrek içinde görülen takım içi lead time değerlerindeki artışın sebebi nedir?
• Sistem içerisine işler halen push edilerek mi devam ediyor?

Müşteri gözünden ve takım gözünden alınan değerleri karşılaştırdığımızda sadece takım bazında yapılacak iyileştirmeler ile sistemin iyileşmeyeceğini öngörebiliriz. Sistem içerisinde bulunan takımların ya da devir noktalarının daha koordine şekilde çalışması ile iyileşme elde edilecektir.

Şu an ki birikimim ile iki türde takım oyununun var olduğuna inanıyorum;

1. Verilen görev ve sorumlulukları harfiyen ve anında yerine getirilmesi için takım olmak
2. Görev ve sorumlulukların bütün sistem içerisinde ne olması gerektiğini sorgulayarak, etkisini ölçerek ve yenilikler önererek yerine getirmek için takım olmak.

Ne yazık ki en çok gözlemlediğim takım oyunu birinci sırada bahsettiğim. Eğer yenilikçi bakış açısı ile ileriye gitmek (Kaizen) istiyorsak sanırım ikinci tipte bir takım oyunu oynamamız gerekiyor.

Metriklerin, karşılıklı konuşmanın yerine geçmeden, konuşmaları daha zenginleştiren yardımcı araçlar olarak kullanılması gerek. Metrikler iki yabancı kişi arasındaki ortak bir dil olarak kullanılmalı.

Anonim yorumlarınızı bu adresten bana gönderebilirsiniz. sayat.me/intparse

Yorum yaparken e-posta adresinizi paylaşırsanız size o sayfadan e-posta adresinizi görmeden cevap verebilirim.

Detaylar aşağıdadır. Okuduğunuz için şimdiden teşekkürler.

—
Alper Tonga

Talep Yetkinlik Yorumu (Müşteri Gözünden)

Aşağıdaki grafik bize Ocak – Kasım 2017 arasında talebe başlanan ve sürüme çıkılan işler ile ilgili değerleri göstermekte. Müşteri gözünden bakmak, bütün takımlara (Kumbara Takımı + analiz + test) bakmak demek. Kırmızılar başlanan, yeşiller sürüme çıkılan işleri temsil etmekte. Bar grafik o ay içinde kaç iş talebine başlandığını (Ready 2 Prepare) ve kaç işin sürüme çıkıldığını (Delivered) göstermekte. Örnek; mayıs ayında 4 işe başlanmış ve 1 iş sürüme çıkılmış. Çizgi grafiği oranları göstermekte. Örnek; ağustos ayında günde 0.39 işe başlanmış (yaklaşık 10 günde 4 iş) ve günde 0.10 iş sürüme çıkılmış (yaklaşık 10 günde 1 iş).

Benim bildiğim önemli etkinlikleri/günleri grafik üzerinde işaretlemeye çalıştım.

Bu grafiğin bize cevaplamamızda yardımcı olmasını istediğimiz soru; sistem gelen taleplere istenen seviyede cevap verebiliyor mu?

• Kırmızı çizgi (başlanan iş oranı) yeşil çizginin (sürüme çıkan iş oranının) bir tık üstünde (bir tık göreceli bir birim) ilerliyor ise sistem boşta kalmadan (starvation olmadan) işliyor demektir. Yeni iş hazırda bekliyor demektir.
• Eğer kırmızı çizgi (başlanan iş oranı) yeşil çizginin (sürüme çıkılan iş oranının) çok üzerinde aralarında çok fark var ise (yine göreceli bir birim) sistemin gelen iş talebi altında ezilme durumunda olabileceğini söyleyebiliriz.
• Eğer kırmızı çizgi (başlanan iş oranı) yeşil çizginin (sürüme çıkılan iş oranının) çok altında kalıyor ise, taleplerin azalmaya başladığını ya da takımın yetkinlik arttırarak daha önceden baş edemediği taleplere yetişebildiğini ya da projenin sonuna yaklaşıldığını söyleyebiliriz.

Gözlem

Verilerin mayıs ayında toplandığını göz önünde bulundurursak yorumları hazirandan itibaren yapmak iyidir. Buna göre;

• Ağustos ayı sistem içerisinde görünen en fazla talep oranına sahip; günde 0,39 iş. Yaklaşık 10 günde bir 4 iş talep edilmiş. Bu ay dışında talep edilen iş miktarlarında çok farklılık görülmediğini söyleyebiliriz.
• Ağustos – Ekim aralığında iş sürüme çıkılma oranlarında güzel bir ivmelenme görülüyor; 3 katı kadar bir artış olmuş. Günde 0,10 işten 0,32 işe artmış. Kabaca 10 günde 1 iş sürüme çıkılırken 10 günde 3 iş sürüme çıkılmaya başlanmış.
• İki noktada, ağustos ve kasım aylarında, sürüme çıkış oranlarının ivmelenme sonrası düşüşe geçtiğini görüyoruz. Ağustos’un ilk iki haftasının tatil olduğunu düşünürsek ağustos ayındaki doğal bir düşüş diyebiliriz. Kasım ayındaki düşüş bize Kumbara takımı’nın işleri için de Freeze geldiğini düşündürebilir. Takıma sormadan bilemeyeceğiz.

Gerçekleşen durumlara göre takımın nasıl önlemler aldığı bu yorumlardan daha önemlidir. Bu grafikler çıkan işlere sayı olarak bakmaktadır. İşin büyüklüğü ya da küçüklüğünden daha çok sistem içerisinde elde edilen değerin bu sayılar ile orantısı daha önemlidir. Bu değer ve yük dengelemesi/eşleşmesi yapılmadan sadece sayılardan gitmek bile Kaizen oluşturmak için bir başlangıç noktası oluşturacaktır.

Bu baktığımız durumlar tüm sistemi ilgilendiren konulardı. Acaba bu etkenler olurken takım içindeki durumlar neydi buna bir bakalım.

Talep Yetkinlik Yorumu (Takım Gözünden)

Aşağıdaki grafik bize Nisan – Kasım arasında geliştirilmesine başlanan ve teste ya da sürüme hazır hale gelen işler ile ilgili değerleri göstermekte. Kırmızılar geliştirmeye başlanan, yeşiller teste ya da sürüme hazır işleri temsil etmekte. Bar grafiği o ay içinde kaç iş talebinin geliştirilmesine başlandığını (Ready 2 Start) ve kaç işin teste ya da sürüme hazır hale getirildiğini (Ready 2 Accept) göstermekte. Örnek; ağustos ayında 9 talebin geliştirilmesine başlanmış ve 7 iş teste ya da sürüme hazır hale getirilmiş. Çizgi grafiği oranları göstermekte. Örnek; ağustos ayında günde 0.29 işin geliştirilmesine başlanmış (yaklaşık 10 günde 3 iş) ve günde 0.23 iş teste hazır hale getirilmiş (yaklaşık 10 günde 2 iş).

Gözlem

• Haziran ve ekim ayları dışında, takımın geliştirme isteklerine normal bir şekilde cevap verebildiklerini söyleyebiliriz.
• Takım gözünden 3 adet dönüm noktası olabilir. Haziran, eylül ve ekim için takımın yorumunu dinlemek iyi olabilir.
• Haziran ayından itibaren teste hazır işlerin oranı artmaya başlamış. Teste hazır hale getirilen işlerin oranı haziranda günde 0.07 (100 günde 7 iş) iken, eylülde günde 0.40 (100 günde 40) olmuş. Bu artışın sürüme çıkma oranına etkisi (müşteri gözünden bakıldığında) ağustostan sonra görülüyor. WIP sabitlemelerini (bkz. aşağıda) tebrik etmek gerek.
• Eylül ayından sonra teste gönderilen iş oranlarında dramatik bir düşüş gözlenmekte. Takım WIP grafiği, Eylül’den sonra geliştirmeye başlanan işlerde azalma olduğunu gösteriyor. Tatile çıkma ya da takım üyesinde azalma olabilir mi? Ya da pair programming gibi kalite arttırıcı/bilgi aktarıcı bir deneme yapılmış olabilir mi diye sorulabilir.

Peki böyle yaptılar da ne oldu? Gelin kalite iş taleplerine, üretilen hata ve çözülen hata kayıt oranlarına, bir bakalım.

Kalite Talep Yetkinlik Yorumu (Müşteri Gözünden)

Aşağıdaki grafik bize Ocak – Kasım arasında başlanan ve sürüme çıkılan işlerin yüzde kaçının hata (bug) kaydı olduğunu göstermekte. Kırmızılar başlanan işlerin yeşiller sürüme çıkılan işlerin yüzde kaçının hata (bug) kaydı olduğunu göstermekte.

ÖNEMLİ: Bu yüzdelerde herhangi bir artış ya da azalma olması hata kayıtlarının arttığı anlamına gelmez. Şöyle ki; bir ay başlanan 6 işten 3 tanesinin hata kaydı olması %50’lik bir oran olurken bir sonraki ayda başlanan 3 işten 2 tanesinin hata kaydı olması %66’lık bir oranı ortaya çıkarır. Böyle bir durumda Hata kayıtlarının arttığı gibi bir yorum yapmamız yanlış olur.

Gözlem

• Nisan ayında başlanan işler en çok yüzdede hata kaydı içermekte. Ayrıca, nisanda sürüme alınan işlerin hepsi -mavi çizgi %100 değerinde olduğu için- hata kaydından oluşmakta diyebiliriz.
• Haziran – Ağustos arasında sürüme alınan işlerde hata kayıtlarının yüzdesinin düştüğü görülebilir. Hata kayıtlarına olan efor azaltılarak daha çok yeni fonksiyonlara odaklanılmış diyebiliriz. Ağustos ve eylül aylarında bu oran sıfırlanmış ve ekimden itibaren tekrardan artmaya başlamış.
• Temmuz – Eylül arasında rapor edilen -kırmızı çizgi ile gösterilen- hata kayıtları sıfıra indirgenmiş. Ekimde tekrar hata kaydı raporlanmış. Takım ile görüşüp yorum almakta fayda olabilir.

Hata kayıtlarının artışa geçip geçmediğini anlayabilmek için aynı grafik içerisinde başlanan ve sürüme çıkılan işlerin günlük oranları gösterilerek yoruma zenginlik katılabilir. Aşağıdaki grafikte bu durum görselleştirilmiştir. Kesikli çizgiler ilgi alanımız.

Dengeli İş Dağılımı Yorumu

Aşağıdaki grafik bize Nisan – Kasım arasında aylık bazda sistemim süreç ve doluluk durumlarını göstermekte. Talep akışının nerede hızlandığını/yavaşladığını/durduğunu (darboğaz) (bottleneck), dengeli bir dağılım olup olmadığını bu grafikten görebiliriz.

Birbirini kesen (iş azlığı, starvation), kalınlaşan (iş fazlalığı, overburden), ya da düz çizgi (değişim yok) durumlarını görmeye çalışıyoruz.

Gözlem

• Ağustos – Ekim arasında sürüme çıkılan (koyu yeşil bölge) iş sayılarında sürekli bir artışın olduğu söylenebilir. Bu sürüm artışı Kasım’da durma noktasına gelmiş. Kasım’da freeze olmuş olabilir mi?
• Ağustos itibari ile sürüme hazır işlerin (açık yeşil bölge) artması sürüme çıkışları rahatlatmış olabilir. Bu bölgenin görünür hale gelmesi iyiye işarettir. Sürüme çıkışların daha planlı (starvation olmadan) yapılabildiği yorumu yapılabilir. Bu durum -takımın iş akışını yönetirken- başlamaktan çok bitirmeye odaklanmaya başlandığına işarettir.
• Ağustos – Eylül arasında test edilmeye hazır (mavi bölge) işlerin artmaya başladığını ve geliştirilen işlerin (turuncu bölge) azaldığını (starvation) görüyoruz. Burada test ekibinin üzerinde çok iş olduğu ve yeni geliştirme alınmadığı yorumu yapılabilir. Bu da başlamaktan çok bitirmeye odaklanıldığının bir delili olarak görülebilir. Güzel bir durum.
• Kasım ayında sürüme çıkılma (koyu yeşil bölge) oranı çok az olsa da takımın sürüme hazır (açık yeşil bölge) işlerinin olduğunu görebiliyoruz. Bilerek sürüme çıkılmamış olabilir ve bu da freeze olduğunun olasılığını arttırıyor.
• Bütün grafik boyunca analiz işlerinin (sarı bölge) sabit oranda (~5 iş gibi) iş yüküne sahip olduğunu görüyoruz.

Aylık İş Çıkış Süresi/Kapasite/Sürüm Sayısı Yorumu (Müşteri Gözünden)

Aşağıdaki grafik bize Nisan – Kasım arasında aylık bazda iş sürüme alma sürelerini (averaj/%75’lik dilim/%85’lik dilim Lead Time) ve sürüme alınan iş sayısı ile birlikte başlanmış fakat bitirilmemiş iş sayılarını (mor renk ile) göstermekte.

Yeşil, mavi ve turuncu çizgiler ile çizilen lead time değerlerinin düşmesi daha çabuk/hızlı sürüme çıkıldığını gösterir. Lead time değerlerinin birbirlerine yakın olmaları istikrarın ve öngörülebilirliğin yüksel olduğunu gösterir. Kesikli mor çizgi o ay içinde sürüme alınan iş sayısını, düz mor çizgi ise başlanan fakat bitmemiş olan iş sayılarını (WIP: work-in-progress) gösterir.

Gözlem

• Mayıs ayında 25 gün içerisinde işler sürüme çıkılırken ağustos ayına doğru süreler artmaya başlıyor. Lead time değerleri 200 ile 100 gün aralığında dağılmaya başlıyor. Eylül ayından sonra toparlanmaya başladığını söyleyebiliriz.
  Not: Bu gibi bir dağılım eskiden kalan işlerin bitirilmesi ile ortaya çıkabilir. Takım üzerindeki iş yükünden kaynaklı zaman sıkıntısı ya da yeterli öncelik verilmeyen/bekletilen işler sonuçlandırıldığında lead time süreleri uzun olacak ve grafiklerde böyle bir dağılmaya/silkelenmeye neden olacaktır. Ne kadar eski işimiz var ise bu sarsıntılar belli aralıklarla tekrarlanacaktır.
  Gözlemlenen iyileşmeler, eklenen kurallar (policy) ya da sistemin daha iyi anlaşılması sonucunda slack time oluşturulup takımın eskiden kalan işlerine odaklanması (temizlik yapılması) sağlanmış olabilir. Bu temizlik işleri ağustos, eylül ve ekim ayları boyunca devam etmiş gibi görünüyor.
• Eylül ayından sonra lead time değerlerinde iyileşmeler görülmeye başlanmış. Lead time değerleri düşerken sürüme çıkılan iş sayıları (kesikli mor çizgi) artmaya başlamış. Başlamaktan çok bitirmeye odaklanmaya başlanmış diyebiliriz. Güzel bir gelişme. (Stop starting, start finishing.)
• Kasım ayı itibari ile işlerin müşteriye ulaşma süresi yaklaşık 50 gün içerisinde gerçekleşiyor. Lead time değerlerinin gittikçe birbirine yakınlaşması daha istikrarlı ve dengeli bir sisteme doğru gidildiğinin işaretçisi olabilir.
• Kasım ayı lead time değerinin 50 gün civarlarına olması -30 günlük bir aralığa baktığımız için- halen geriden gelen işlerin yapıldığının işaretçisi olarak yorumlanabilir. Bunun sebebini anlamamızda WIP değerlerinin (mor çizgi) yardımı olacaktır. Kumbara takımının içinde bulunduğu sistemde yapılan ya da bekleyen iş sayıları 30lara kadar çıkıyor. Kasım ayına doğru bu değerler 25’e kadar düşürülüyor.
• WIP değerlerinin düşürülmeye başlanmasının etkisini tam olarak göremiyoruz. Kasım ayında freeze oldu mu sorusu burada önem kazanmaya başlıyor. Öneri: Bu sistemin aylık sürüm çıkmasından dolayı lead time hedeflerinin 30 günün altında olması gerekir. WIP değerlerinin daha da alta çekilmesi ile bunu sağlayabilirler.

Tüm bunlar yaşanırken takım içerisinde neler oluyordu bir de o gözle bakalım.

Aylık İş Çıkış Süresi/Kapasite/Sürüm Sayısı Yorumu (Takım Gözünden)

Aşağıdaki grafik bize Nisan – Kasım arasında aylık bazda işlerin sürüme hazır hale gelme sürelerini (averaj/%75’lik dilim/%85’lik dilim Lead Time) ve sürüme hazır iş sayısı ile birlikte geliştirmeye başlanmış fakat bitirilmemiş iş sayılarını (mor renk ile) göstermekte.

Bir önceki grafikte müşteri gözünden gördüklerimizi yorumlarken bu grafikte takım gözünden yorumlama yapabileceğiz.
Aradaki farklar;

• Müşteri gözünden baktığımızda lead time değerleri analize başlandıktan sürüme alındığı zamana bakarken, bu grafikte geliştirmeye başlandıktan sürüme hazır hale gelene kadar olan zamana bakıyor.
• Müşteri gözünden başlanan ve devam eden işlerin sayısı (WIP) analize başlanmasından itibaren sayılırken bu grafikte is geliştirmeye başlanan ve test aşamasına kadar gelen işler WIP olarak sayılmakta.
• Müşteri gözünden çıktı sayısı sürüme çıkılan işlerin sayısı olurken bu grafikte gösterilen çıktı sayısı (kesikli mor çizgi) sürüme hazır işlerin sayısı olarak alınmıştır.

Gözlem

• Haziran – Eylül arasında sürüme hazır hale getirilen işlerin (kesikli mor çizgi) sayısında artış olduğunu görüyoruz. Bu artış eylül sonrasında hızla düşmeye başlıyor.
• WIP değerleri (düz mor çizgi) 15 işin üzerine çıkmamış ve sonlara doğru 9 işe kadar düşmüş. Bu güzel bir durum. Daha fazla iş alıp uzun süre bitmesini beklemektense, çalışılan iş sayısını düşürüp daha kaliteli ve kısa sürede işler bitirilebilir.
• İşlerin sürüme hazırlanma sürelerinde eylül ayındaki dalgalanma dikkat çekiyor. %85’lik dilimde (yeşil çizgi) geliştirmeye başlanmasından sürüme hazır hale gelene kadar 60 gün geçmiş işler bulunmakta. Bir temizlik yapılmış olabilir. (Müşteri gözünden bakarken analizden->sürüme çıkılana kadar olan süreyi alıyorduk.)
• Kasım ayında gözlemlenen lead time değerlerinden yine bir dağılma olacağı var sayımı yapabiliriz. Dilimlerin arası açılmaya başlamış.
• Bu dalgalanma müşteri gözünden bakıldığında ağustos ayında yaşanmıştı; dilimler arasında 100 günlük farklar vardı. Fakat bu grafikte ağustos lead time değerleri güzel bir şekilde birbirine çok yakın ve en fazla 9 gün sürmüş. Bu sürüme hazır hale getirilen işler sürüme çıkmamış olabilir ya da analizi bittikten sonra çok uzun süre bekledikten/durdurulduktan sonra bu işlerin geliştirmesine başlanmış ve odaklanarak kısa sürede bu bitirilmesi ile müşteriye bu şekilde yansımış olabilir. Kişisel Görüş: Stokçuluk iyi bir şey değil, her ne kadar elimizde olmayan sebeplerden dolayı olsa bile. Depoda uzun süre bekleyen her iş sistemimizde dağılmalara dalgalanmalara sebep olacak ve ileriyi görmemizi engelleyecektir. Bu yüzden WIP limitinin sadece takım tarafından değil takım öncesi noktalarda da uygulanması gerekmektedir. Daha efektif çalışmaya bu şekilde ulaşabiliriz. Şimdi bu grafik yorumunu ben elimdeki verilere göre yapıyorum fakat asıl değer takım tarafından yapılan yorumlar sonrası çıkacaktır. Sistem içerisinde bulunan takımın/takımların görüşleri ve yorumları her şeyden daha önemli.

Son 9 Aylık Lead Time Histogram Yorumu (Müşteri Gözünden)

Yukarıdaki grafik bize son 9 ay içerisinde sürüme alınan işlerin ne kadar sürdüğünün haftalık dilimler içerisinde dağılımını göstermektedir. Örnek 1: Nisan – Aralık arasında sürüme çıkılan işlerin %74’ü 11 hafta içerisinde sürüme alınmış. Buradaki kilit kelime “içerisinde”. Sürüme çıkılan işlerin %74’ü 11 hafta sürmüş değil, en fazla 11 hafta sürmüş diyebiliriz. Örnek 2: Eğer bütün sürüme çıkılan işleri bir torbaya koysak ve rastgele bir tanesini çeksek, %74 ihtimalle sürüme alma süresi 11 hafta ya da küçük olan bir iş çekebiliriz.

Bu dağılımı kullanarak sisteme gelen yeni işlerin ne kadar süreceği konusunda hızlı bir tahmin yapabiliriz. Dağılımın sistem içerisindeki paydaşlar ile paylaşılması, (detay analiz yapılmadan önceki ilk etapta) işlerin ne kadar süreceği konusunda bilgi sahibi olunmasını ve risklerin anlaşılmasını sağlayarak proje bitiş tarihlerinin ne olabileceğini hızlıca gösterir. Bu destekleyici yöntemin elinizde hiçbir şey olmadan tarih sözü vermekten kat kat iyi olduğunu söyleyebilirim. (Bu yaklaşım tarih içerisinde de kullanılmıştır. Bkz. German Tank Problem, Troy Magennis; Percent Likelihood)

Bu dağılımı kullanarak yeni bir isteğin ne zaman sürüme çıkacağını soran müşterime şunu söyleyebilirim: Not: Bu dağılım grafiği müşteri gözünden olan dağılımı göstermekte yani sadece Kumbara takımının değerleri yok bu dağılımda, bütün sistem (analiz, test, sürüme alma) burada.

• %74 ihtimal ile 11 hafta (~3 ay) içinde sürüme çıkılabilir.
• %85 ihtimal ile 16 hafta (~4 ay) içinde sürüme çıkılabilir.
• %94 ihtimal ile 24 hafta (~6 ay) içinde sürüme çıkılabilir.

Bu dağılım bir histogram, yani bir tarihçe. 9 aylık gibi uzun bir aralığa bakmak çalışma ortamının, takımların ya da projelerin hızlı değişmesinden dolayı pek anlamlı sonuç vermeyebilir. Bu yüzden son 3 aylık dilimlere ya da sistemin yapısına göre bir aralık belirlenerek bakılması en uygunudur. Eğer takımlar değişmiş ya da yeni bir projeye başlanıp bu yeni projenin ortamı bir önceki projeden tamamıyla farklı ise (Java projesinden .NET projesine geçilmesi gibi) eski verileri kullanmadan yeni veriler ışığında tahmin yapılmasında fayda vardır.

İşlerin geçtikleri süreçlere ya da ilgilenilme şekillerine göre gruplandırılması (classes of services) bu tahmin aralığını daha da güçlendirilebilir. Büyüklüğe göre bölmek, literatürde de görüldüğü gibi, bir avantaj sağlamayacaktır. Örnek: iş listenizde küçük bir proje ve normal işleriniz bulunsun. Küçük proje devam ederken yukarıdan büyük bir proje gönderilsin ve en kısa zamanda bitirilmesi gerektiği söylensin. Küçük proje yapılmaya çoktan başlanmasına rağmen durdurup büyük projeye odaklanılıyor ve 1 ay içerisinde olağanüstü bir çaba ile büyük proje sonuçlandırılıyor. Küçük proje ise 1 ay gecikmeli olarak bitiriliyor. Şimdi iş büyüklüğünün işlerin daha hızlı bitirilmesinde büyük rol oynadığını düşünüyor musunuz? ????

Bir başka nokta ise; bu dağılımda sağ tarafa doğru uzayan kuyruğum ne kadar uzun ise sistemimiz o kadar istikrardan ve dengeden uzak diyebiliriz. Kuyruğumu kısaltmak istiyorsam çalıştığım işleri limitlemem gerekiyor. (Limit WIP)

Kumbara takımının içinde bulunduğu sistemin 3 aylık (çeyrek) dağılım dilimlerine bakarak neler yaptıklarını yorumlamaya çalışalım. Bu şekilde dağılımları kullanarak iyileşme olup olmadığını görebiliriz.

2. Çeyrek Aylık Lead Time Histogram Yorumu (Müşteri Gözünden)

Yukarıdaki grafik bize 2. çeyrek (Nisan – Haziran) içerisinde sürüme alınan işlerin ne kadar sürdüğünün haftalık dilimler içerisinde dağılımını göstermektedir.

Gözlem

• Müşterinin ya da paydaşın 4 hafta içerisinde sürüme çıkılan bir işi hiç olmamış. En az 5 hafta bekledikten sonra işler sürüme çıkılabilmiş. Ve bu 5 hafta içerisinde çıkan işler 2. çeyrek içerisinde biten işlerin %25’ini oluşturuyor.
• Çeyrek içerisinde biten işlerin
  %75’i 11 hafta içerisinde sürüme çıkılmış.
• Sürüme aylık çıkıldığından, daha fazla değer üretmek ve efektif çalışmak adına, 4 hafta içerisinde sürüme çıkılan işlerin dağılımda daha fazla olmasını beklemek iyi bir yöntem (fitness criteria) olabilir. Bu dağılımdan 4 hafta içerisinde sürüme iş çıkılamadığını görebiliyoruz. Fakat %50 ihtimal ile 8 hafta (~2 ay) içerisinde sürüme iş çıkılabildiğini görebiliyoruz. Kişisel Görüş: %50 ihtimal yazı tura atmaktan farksız bir ihtimal demek. Planlama yaparak zaman harcamaktansa yazı tura atmak daha mantıklı. Bitiremeyeceğim işlere başlamak hem hızımdan hem de ürettiğim değerden çalacaktır. %100 sistem doluluk oranı (aman boşta kalan kişi olmasın) yerine, kaliteyi nasıl arttırabilirim ve israfı nasıl engellerim diye düşünmek sistem verimini arttıracaktır. %100 proje işlerine odaklanmak yerine, sağlıklı bir oran olarak, %70 proje ve %30 iyileştirme/kişisel eğitim/deney işleri olarak kapasite dağılımı yapılabilir.

3. Çeyrek Aylık Lead Time Histogram Yorumu (Müşteri Gözünden)

Yukarıdaki grafik bize 3. çeyrek (Temmuz – Eylül) içerisinde sürüme alınan işlerin ne kadar sürdüğünün haftalık dilimler içerisinde dağılımını göstermektedir.

Gözlem

• Müşterimiz artık 4 hafta içerisinde sürüme çıkılan işler görmeye başlamış. Ve bu işler 3. çeyrek içerisinde biten işlerin %11’ini oluşturuyor. 5 hafta içerisinde sürüme çıkılan işlerin olasılığı da %28’e yükselmiş.
• Çeyrek içerisinde biten işlerin
  %72’si 11 hafta içerisinde (%75’i 11 hafta içerisinde idi)
  %83’ü 14 hafta içerisinde (%80 dilimi 2. Çeyrek grafiğinde yoktu.)
  %89’u 24 hafta içerisinde sürüme çıkılmış. (%90 dilimi 2. Çeyrek grafiğinde yoktu.)

Bir önceki çeyreğe göre iş bitirilme sürelerinde artış olmaya başlamış. Bunun sebebi bir önceki yorumlarda belirttiğimiz eskiden kalma işlerin bitirilmesinden dolayı oluşan ve ağustos ayında gözlemlenen sarsıntı olabilir.

• Kuyruğumuzun 26 haftalara çıkarak 2. Çeyrek değerlerine göre artmasından da yukarıdaki hipotezimiz destekleniyor. 26 hafta demek yaklaşık 6,5 ay demektir, 3 aylık bir dilime bakıldığı düşünülür ise eski işlerin temizlendiği yorumunun doğruluğu daha da güçleniyor. Bu temizliğin faydalarını uzun vadede görebiliriz.
• Hala aylık sürümler çıkılıyor ve 4 hafta içerisinde işleri sürüme alma olasılığına bakacak olursak %11’lik bir değere sahip. 2. Çeyrek grafiğinde 4 hafta içerisinde iş sürüme çıkılamıyordu. Yani sistem içerisinde yapılan değişikliklerin aylık sürümlere etkisinin olduğunu söyleyebiliriz. Uygulanan deneyimleme sistem içerisinde fark edilmeye başlamış olabilir. Ayrıca bu deneyler, sistemde uzun vadeli dönüşleri olan, iyileştirmelerin ne olacağının belirlenmesine yardımcı oluyor. Kişisel Görüş: Sistem içerisinde Kumbara takımının yaptığı bu değişiklikler evrimsel ve küçük değişiklikler olduğu için Kanban ile güzel bir deneyimleme ve iyileştirme ortamı yaratıyorlar. Organizasyon içerisinde etkisi büyük olacak deneylere girişmektense sistem içerisinde kontrollü bir deneyimleme gerçekleştirmek iki taraf için de kazan kazan durumu yaratıyor.
• Çeyrekte sürüme alınan işlerin sayısının 2. Çeyrekten daha fazla olduğunu da görebiliyoruz.
  2. Çeyrek sürüme çıkılan iş sayısı: 4
  3. Çeyrek sürüme çıkılan iş sayısı: 18
  Bu verilere raporun ilk bölümündeki Talep Yetkinlik yorumlarından ulaşabilirsiniz.

4. Çeyrek Aylık Lead Time Histogram Yorumu (Müşteri Gözünden)

Yukarıdaki grafik bize 4. çeyrek (Ekim – Aralık) içerisinde sürüme alınan işlerin ne kadar sürdüğünün haftalık dilimler içerisinde dağılımını göstermektedir.

Gözlem

• Bu 4. Çeyrek grafiği aslında sadece ekim ve kasım ayını içermekte. Kasım ayında da bir freeze olasılığı var. Aralık sonunda sürüme çıkılacak olan işlerin bu grafiği nasıl etkileyeceğini sistem paydaşlarının bilmesi önemlidir. İstikrar ve denge kazanmaya başlayan bir sistem içerisine yapılan bu etkinin dağılıma ve dolayısı ile ön görüye etkisi olumsuz olacaktır.
• Çeyrek içerisinde biten işlerin
  %75’i 8 hafta içerisinde (%72’si 11 hafta içerisinde idi)
  %83’ü 16 hafta içerisinde (%83’i 14 hafta içerisinde idi)
  %100’ü 20 hafta içerisinde sürüme çıkılmış. (%100’ü +26 hafta içerisinde idi)
• Sistemde en fazla görülen sürüme çıkış süresi 20 haftadır.
  Eski işlerin temizlenmesi, WIP sınırlandırması ve diğer kararların takım tarafından karşılaştırılarak alınması iyileşmenin başlangıcına işaret olabilir. %75’lik dilimde iyileşme olurken %85’lik dilim biraz daha açılmış gibi. Daha hala eskiden kalma işler sistem içerisinde duruyor olabilir. Tabi Kumbara takımı daha iyi yorum yapıp, veri gösterebilecektir.
• Ekim ve kasım ayında sürüme alınan işlerin sayısının 3. Çeyreğin %67’sine denk geldiğini görebiliyoruz. Aralık ayında sürüme çıkılan sayı ile toplam ne olur acaba?
  Çeyrek sürüme çıkılan iş sayısı: 4
  3. Çeyrek sürüme çıkılan iş sayısı: 18
  Sadece ekim ve kasım ayı sürüme çıkılan iş sayısı: 12
  Bu verilere raporun ilk bölümündeki Talep Yetkinlik yorumlarından ulaşabilirsiniz.

Bütün bu gelişmeler sistem içerisinde olurken takım içerisinde nasıl bir değişim vardı? Bu dağılımlara bir de takım gözünden bakalım.

Son 9 Aylık Lead Time Histogram Yorumu (Takım Gözünden)

Yukarıdaki grafik bize son 9 ay içerisinde teste gönderilen ya da sürüme hazır hale gelene kadar geçen zamanın haftalık dilimler içerisinde dağılımını göstermektedir. Örnek 1: Nisan – Aralık arasında teste gönderilen ya da sürüme hazır işlerin %82’si 3 hafta içerisinde teste gönderilmiş ya da sürüme hazır hale gelmiş. Buradaki kilit kelime “içerisinde”. Teste gönderilen ya da sürüme hazır işlerin %82’si 3 hafta sürmüş değil, en fazla 3 hafta sürmüş diyebiliriz. Örnek 2: Eğer bütün teste gönderilen ya da sürüme hazır işleri bir torbaya koysak ve rastgele bir tanesini çeksek, %82 ihtimalle süresi 3 hafta ya da küçük olan bir iş çekebiliriz.

Bu dağılımı kullanarak takıma gelen işlerin ne kadar süreceği konusunda hızlı bir tahmin yapabiliriz. Dağılımın takım üyeleri içerisinde paylaşılması, işlerin ne kadar süreceği konusunda bilgi sahibi olunmasını ve risklerin anlaşılmasını sağlayarak iş çıkış tarihlerinin ne olabileceğini hızlıca gösterir. Bu destekleyici yöntem ile takım ne kadar büyük ya da küçük bir sorumluluk altında olduğunun karşılaştırmasını yapabilir.

Bu dağılımı kullanarak yeni bir isteğinin ne zaman teste ya da sürüme hazır olacağını soran talep sahibine şunu söyleyebilirim: (Not: Bu dağılım grafiği takım gözünden geliştirme süresinin dağılımını göstermekte, analiz ekibi ya da test ekibi süreleri buraya yansımamıştır.)

• %68 ihtimal ile 2 hafta içinde teste ya da sürüme hazır hale geliyor. (Müşteri gözünden bakıldığında 8 hafta içinde)
• %82 ihtimal ile 3 hafta içinde teste ya da sürüme hazır hale geliyor. (Müşteri gözünden bakıldığında 14 hafta içinde)
• %94 ihtimal ile 6 hafta içinde teste ya da sürüme hazır hale geliyor. (Müşteri gözünden bakıldığında 24 hafta içinde)

Müşteri gözünden ve takım gözünden alınan değerleri karşılaştırdığımızda sadece takım bazında yapılacak iyileştirmeler ile sistemin iyileşmeyeceğini öngörebiliriz. Sistem içerisinde bulunan takımların ya da devir noktalarının daha koordine şekilde çalışması ile iyileşme elde edilecektir.

İşlerin geçtikleri süreçlere ya da ilgilenilme şekillerine göre gruplandırılması (classes of services) bu tahmin aralığını daha da güçlendirilebilir. Büyüklüğe göre bölmek, literatürde de görüldüğü gibi, bir avantaj sağlamayacaktır. Örnek: iş listemizde küçük bir proje ve normal işlerimiz bulunsun. Küçük proje devam ederken yukarıdan büyük bir proje gönderilsin ve en kısa zamanda bitirilmesi gerektiği söylensin. Küçük projeyi yapmaya çoktan başlamıştık fakat durdurup büyük projeye odaklanıyoruz ve 1 ay içerisinde olağanüstü bir çaba ile büyük proje sonuçlandırılsın. Küçük proje ise 1 ay gecikmeli olarak bitirilsin. Şimdi iş büyüklüğünün işlerin daha hızlı bitirilmesinde büyük rol oynadığını düşünüyor musunuz? ????

Bir başka nokta ise; bu dağılımda sağ tarafa doğru uzayan kuyruğum ne kadar uzun ise sistemimiz o kadar istikrardan ve dengeden uzak diyebiliriz. Kuyruğumu kısaltmak istiyorsam çalıştığım işleri limitlemem gerekiyor. (Limit WIP)

Kumbara takımının 3 aylık (çeyrek) dağılım dilimlerine bakarak neler yaptıklarını yorumlamaya çalışalım. Bu şekilde dağılımları kullanarak iyileşme olup olmadığını görebiliriz.

2. Çeyrek Aylık Lead Time Histogram Yorumu (Takım Gözünden)

Yukarıdaki grafik bize 2. çeyrek (Nisan – Haziran) içerisinde teste gönderilene ya da sürüme hazır hale gelene kadar geçen zamanın haftalık dilimler içerisinde dağılımını göstermektedir.

Gözlem

• Çeyrek içerisinde işlerin
  %50’si 1 hafta içerisinde
  %100’ü 4 hafta içerisinde
  en fazla 4 hafta içerisinde teste ya da sürüme hazır hale getirilmiş.

3. Çeyrek Aylık Lead Time Histogram Yorumu (Takım Gözünden)

Yukarıdaki grafik bize 3. çeyrek (Temmuz – Eylül) içerisinde teste gönderilene ya da sürüme hazır hale gelene kadar geçen zamanın haftalık dilimler içerisinde dağılımını göstermektedir.

Gözlem

• Çeyrek içerisinde biten işlerin
  %56’sı 1 hafta içerisinde (%50’si 1 hafta içerisinde idi)
  %72’i 2 hafta içerisinde
  %89’u 3 hafta içerisinde
  %94’ü 4 hafta içerisinde teste ya da sürüme hazır hale getirilmiş.
  En fazla +12 hafta süren iş var.

Bir önceki çeyreğe göre iş bitirilme sürelerinde artış olmaya başlamış. Bunun sebebi bir önceki yorumlarda belirttiğimiz eskiden kalma işlerin bitirilmesinden dolayı oluşan ve eylül ayında gözlemlenen sarsıntı olabilir.

• Kuyruğumuzun 12 haftaların üstüne çıkarak 2. Çeyrek değerlerine göre artmasından da yukarıdaki hipotezimiz destekleniyor. 12 hafta demek yaklaşık 3 ay demektir, 3 aylık bir dilime bakıldığı düşünülür ise eski işlerin temizlendiği yorumunun doğruluğu daha da güçleniyor. Bu temizliğin faydalarını uzun vadede (bir sonraki çeyrekte) göreceğiz.
• Çeyrekte teste ya da sürüme hazır hale gelen işlerin sayısının 2. Çeyrekten daha fazla olduğunu da görebiliyoruz.
  2. Çeyrek sürüme çıkılan iş sayısı: 4
  3. Çeyrek sürüme çıkılan iş sayısı: 18
  Bu verilere raporun ilk bölümündeki Talep Yetkinlik yorumlarından ulaşabilirsiniz.

4. Çeyrek Aylık Lead Time Histogram Yorumu (Takım Gözünden)

Yukarıdaki grafik bize 4. çeyrek (Ekim – Aralık) içerisinde teste gönderilene ya da sürüme hazır hale gelene kadar geçen zamanın haftalık dilimler içerisinde dağılımını göstermektedir.

Gözlem

• Bu dağılım 3 ayda elde edilen değerleri içermektedir. Müşteri gözünden bakıldığında yaptığımız “sadece ekim ve kasım verilerin olması” durumu burada söz konusu değil çünkü takım her zaman bir işi sürüme hazır hale getirebilir.
• Çeyrek içerisinde sürüme hazır hale gelen işlerin
  %50’si 1 hafta içerisinde (%56’sı 1 hafta içerisinde idi)
  %67’si 2 hafta içerisinde (%72’si 2 hafta içerisinde idi)
  %83’ü 3 hafta içerisinde (%89’u 3 hafta içerisinde idi)
  %92’si 6 hafta içerisinde (%94’ü 4 hafta içerisinde idi)
• Sistemde en fazla görülen teste ya da sürüme hazır hale gelme süresi +12 haftadır. Halen bir önceki çeyreğe göre bir iyileşme gözlemlenmiyor. Eski işlerin temizlenmesine devam ediliyor olabilir mi? İş yükü (push) çok artmış olabilir mi? Takım talep yetkinlik grafiğine baktığımızda ekim ayında kırmızı çizginin yeşil çizgi üzerinde olduğunu (overburden) görebiliyoruz.
• Çeyrekte teste ya da sürüme hazır hale gelen işlerin sayısının 3. Çeyrekten daha az olduğunu da görebiliyoruz. Yeni proje baskısı ile birlikte WIP artışı, Kasım ayındaki Freeze bu azalmanın nedeni olabilir.
  2. Çeyrek sürüme çıkılan iş sayısı: 4
  3. Çeyrek sürüme çıkılan iş sayısı: 18
  4. Çeyrek sürüme çıkılan iş sayısı: 12
  Bu verilere raporun ilk bölümündeki Talep Yetkinlik yorumlarından ulaşabilirsiniz.

Biraz da müneccimlik yapalım!

Limitless takımın raporunda bu bölüm yoktu ama raporu gönderdikten sonra keşke koysaydım diye hayıflandım. Kısmet Kumbata takımı içinmiş. ????

Aşağı yukarı bu verileri aldığımda devam eden ve sırada bekleyen toplam 20 iş vardı. Bütün bu 20 işin tamamlanması benim algoritmama göre şu şekilde.

Yeni eklenecek her iş için; %75 ~+6 gün, %85 ~+12 gün tarihlere ekleyebilirsiniz.
(Bu öngörü şu an ki veriler ışığında çıkartıldı. İyileşmeler olur ise model güncellenmelidir.)

16 sayfa boyunca bütün yorumları okuyup yorumlamaya çalıştığınız için tekrardan teşekkür ederim. Şunu hiç unutmayalım; en iyi ve gerçekçi yorumları yine takımın kendisinden alabiliriz.

Metrikler, karşılıklı konuşmanın yerine geçmeden, konuşmaları daha zenginleştiren yardımcı araçlar olarak kullanılması gerek. Metrikler iki yabancı kişi arasındaki ortak bir dil olarak kullanılmalı.

Daha derin yorumlar için Kumbara takımı ile konuşmakta fayda var.

Anonim yorumlarınızı bu adresten gönderebilirsiniz. sayat.me/intparse