Kaizen Seansları: İyileşme İçin Farkındalık (Limitless 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.

Limitless Takımı

Limitless Takımından Murat ile, 27 Nisan 2017 tarihinde ilk Kanban (Team Kanban Practitioner) eğitimini aldıktan sonra, Mayıs 2017 sonundan itibaren birlikte çalışmaya başladık. Daha sonra Kanban Management Professional sertifikasını alabilmek için gereken ilk eğitimi (KMP I) 12 Ekim 2017’de aldı.

Birlikte çalışmaktan keyif aldığım, kendi sistemini daha iyiye taşımak için yaptığı denemeleri görerek mutlu olduğum, birlikte öğrendiğim bir kişidir kendisi. 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 iyileşmeleri irdelemek için yazılmıştır.

• Sürüme çıkış oranları Mayıs 2017’den itibaren 7 kat, Haziran 2017’den itibaren 2,5 kat nasıl artmış?
• Sürüme çıkan işler (%80 ihtimal) 10 hafta içerisinde tamamlanırken nasıl 5 hafta içerisinde tamamlanmaya başlanmış.
• Eylül 2017’den beri neden hiç hata (bug) kaydı raporlanmamış/açılmamış?
• Takım bir önceki durumlarına göre nasıl iş kapasitesini arttırabilmiş ya da artan iş yükünü dengelemiş?
• En önemlisi sistemlerini daha iyi hale getirmek için nasıl yön gösterici kararlar almışlar ya da diğer birimleri yönlendirmişler?

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.

Limitless takımının proje yönetiminden birlikte çalıştıkları bölümlere kadar mantıklı geri bildirimler vererek ve söylediklerinin duyulmasını sağlayarak bunu başardıklarını düşünüyorum.

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)

Yukarıdaki grafik bize Ocak 2017 – Kasım 2017 arasında talebe başlanan ve sürüme çıkılan işler ile ilgili değerleri göstermekte. Kırmızılar başlanan, yeşiller sürüme çıkılan işleri temsil etmekte. Bar grafiği 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. Mesela; mayıs ayında 9 talebe başlanmış ve 2 iş sürüme çıkılmış. Çizgi grafiği oranları göstermekte. Mesela; ağustos ayında günde 0.42 işe başlanmış (yaklaşık 3 günde 1 iş) ve günde 0.39 iş sürüme çıkılmış (yaklaşık 3 günde 1 iş).

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

Bu grafikten cevaplaması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) üzerinde fakat bu sefer 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) altında kalıyor ve fark büyük 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ından itibaren toplandığını göz önünde bulundurursak yorumları haziran sonrasındaki veriler ile yapmak iyi olacaktır. Buna göre;

• Haziran 2017 – Ağustos 2017 aralığında iş çıkış oranlarında 2 kat artış gözlemlenmekte. Günde 0.2 işi sürüme çıkarken bu oran günde 0.4 işin sürüme çıkılması ile artmış. (Mayıs verisine göre 7 kat bir artış.) Ağustos’un ilk iki haftasının tatil olduğunu düşünürsek güzel bir artış.
• Eylül ayında gelen anormal iş talebi ve işe başlanma oranının artışı ile takımın sürüme çıkış hızının azaldığı gözlemlenmekte. (Bkz. Queueing Theorem: Little’s Law; başlanan iş sayısı arttıkça işin sürüme çıkma süreleri de artacak ve iş bitirme oranına azalma olarak yansıyacaktır.)
• Kasım ayındaki Freeze ile takımın sürüme çıkışının etkilendiğini de görebiliyoruz.
• Kasım ayında da Eylül’de olduğu gibi iş talebine başlanmasında artış olduğunu görebiliyoruz.

Bu gerçekleşen durumlara göre takımın nasıl önlemler aldığı bu yorumların yanında daha önemlidir.

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)

Yukarıdaki grafik bize Nisan 2017 – Kasım 2017 arasında geliştirilmesine başlanan ve teste hazır işler ile ilgili değerleri göstermekte. Kırmızılar geliştirmeye başlanan, yeşiller teste 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 hazır hale getirildiğini (Ready 2 Accept) göstermekte. Mesela; ağustos ayında 14 talebin geliştirilmesine başlanmış ve 10 iş teste hazır hale getirilmiş. Çizgi grafiği oranları göstermekte. Mesela; ağustos ayında günde 0.45 işin geliştirilmesine başlanmış (yaklaşık 3 günde 1 iş) ve günde 0.32 iş teste hazır hale getirilmiş (yaklaşık 4 günde 1 iş).

Gözlem

• Haziran ayından itibaren takım WIP sınırlandırması ile teste gönderme oranlarını sabit tutmayı başarmış. Haziran ayında günde 0.30 işin teste hazır hale getirilmesinden Kasım ayında günde 0.37 işin teste hazır hale getirilmesine kadar artmış.
• Ağustos ayında başlayan geliştirme artışına rağmen takım çıktı oranlarından ödün vermemeye ve sabit tutmaya çalışmışlar. Bu şekilde önceden tahmin edilebilir sistem yapılarını korumuş olabilirler.
• Alttaki WIP grafiğinden de gelen talebe cevap verebilmek için WIP değerlerini Eylül’den sonra arttırmak zorunda kaldıklarını fakat takım içi çıktı oranlarının yine de sabit kaldığını görebiliyoruz. Bu takım içi yetkinlik artışı demektir.

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)

Yukarı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 – Haziran arasında başlanan işlerde hata kayıtlarının yüzdesi düşerken Ağustos 2017’de başlanan işlerde en çok yüzdede hata kaydı içermekte.
• Mayıs – Temmuz 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 azalarak daha çok yeni fonksiyonlara odaklanılmış denebilir.
• Eylül 2017’den itibaren rapor edilen ve sürüme çıkılan hata kayıtları sıfıra indirgenmiş. Burada takımın yetkinliği artarak daha kaliteli işler çıkardığı yorumu yapılabileceği gibi iş birimlerinden hiç hata kaydı gelmediğinden hata kaydı sürüm çıkışları da yapılmamış 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

Yukarı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), dengeli bir dağılım olup olmadığını bu grafikten görebiliriz.

Gözlem

• Mayıs – Ağustos 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ışı Eylül’de yavaşlamasına rağmen Ekim’de tekrar ivme kazanmış fakat Kasım’daki freeze ile durmuştur.
• Grafikte belirtilen notlar ile değerler eşleştirildiğinde daha zengin yorum yapılabilir. Eylül’de gelen yeni proje (gri bölge) yeni işlere öncelik verilmesine sebep olmuş ve Ağustos – Eylül arasındaki sürüm düşüşü yaşanmış olabilir.
• Temmuz – Ağustos arasında test edilmeye hazır (mavi bölge) işlerin tükendiğini ve geliştirilen işlerin (turuncu bölge) artmaya başladığını görüyoruz. Ağustos – Eylül arasındaki sürüm düşüşünün (koyu yeşil) sebebi bu durumdan dolayı olabilir. Ayrıca sürüme hazır (açık yeşil bölge) işlerin hiç etkilenmeden artması da ilginç bir durum. İyi bir yorum için, her zaman olduğu gibi, takıma danışmak gerekir. Takım yorumu: Test edilen işlerin tıkanmaya başlaması takım tarafından gözlemlenmiş ve çıktı hızının olumsuz etkilenmemesi için, dış teste ihtiyacı olmayan işlerin yapılmasına karar verilerek bu sonuç elde edilmiştir.
• Grafikte sürüme hazır işlerin (açık yeşil bölge) oranının Eylül’deki yeni proje ve Kasım’daki freeze durumundan etkilenmeden hep yükselişte olduğunu gözlemlemiştik. Bu güzel bir durum, takım boş durmamış. ????Başka bir deyişle reaktif değil pro-aktif bir takım yapısında, iş yapmak için birilerinden komut beklenmediğini söyleyebiliriz.

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

Yukarıdaki grafik bize Nisan – Kasım arasında aylık bazda iş sürüme alma sürelerini (averaj/%75lik dilim/%85lik 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 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

• Kasım ayı itibari ile işlerin müşteriye ulaşma süresi yaklaşık 25 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.
• Tüm grafiğe baktığımızda 25 gün değerlerine Haziran ayında da ulaşıldığını fakat sonrasında (Temmuz ayında) bir dağılma olduğunu ve bu dağılmanın Ağustos ayından itibaren toparlandığını gözlemliyoruz. Not: Bu gibi bir dağılma genelde 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 verilmediği/koşuşturma içinde unutulduğu için bitirilemeyen 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. Nisan ayından bu yana gözlemlenen iyileşmeler, eklenen kurallar (policy) ya da sistemi daha iyi anlama sonucunda takım üzerindeki işler bitirilerek slack time oluşturulup takımın eskiden kalan işlerine odaklanması (temizlik yapılması) sağlanmış olabilir. Ve bu odaklanma sonucunda Temmuz ayındaki dağılma sonrasında Ağustos ayı ile birlikte yeni bir sayfa açılarak devam edilmiş olabilir.
• Takım kapasitesine bakarsak; Nisan – Mayıs arasında başlanan ve devam eden iş sayısı (WIP) yaklaşık 8 ile 9 arasında değişirken Haziran – Ağustos arasında bu sayı 12’ye kadar çıkmıştır. Bu dönemde sürüme alınan iş sayısının (kesikli mor çizgi) hep artıyor olması sistemin (sadece takımın değil) yetkinlik artışına gittiğinin göstergesidir. Buradaki yetkinlik ve kapasite artışındaki faktörlerin başını Limitless takımının çektiğini gönül rahatlığı ile söyleyebilirim.
• Eylül ayında gelen yeni proje ile WIP sayısının dramatik olarak 25lere çıkartılmasının sürüm çıktı sayısını nasıl olumsuz etkilediğini gözlemleyebiliriz. Yeni projenin gelişinin sistem içerisinde yarattığı panik ile hemen analiz işlerine başlanması bu durumu doğurmuş olabilir. Ne kadar çok işe başlanırsa işlerin bitirilme süreleri o kadar uzayacaktır. (Bkz. Queueing Theorem: Little’s Law)
• Ekim ayında sistemin kendini tekrardan toparlamaya çalıştığını görebiliyoruz fakat gelen freeze ile birlikte yine müşteri gözünde istikrarın olumsuz etkisi gözlenebilir.

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)

Yukarıdaki grafik bize Nisan – Kasım arasında aylık bazda işlerin sürüme hazır hale gelme sürelerini (averaj/%75lik dilim/%85lik 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 Limitless 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 belirtilen lead time değerleri geliştirmeye başlandıktan test aşamasına 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) teste gönderilmiş ya da sürüme hazır işlerin sayısı olarak alınmıştır.

Gözlem

• Limitless takımının en istikrarlı ve hızlı olduğu dönem Ağustos ayı olarak görünüyor, yaklaşık 5 gün içerisinde işler sürüme hazır hale geliyor.
• Müşteri gözünden baktığımızda temmuz ayında gördüğümüz dağılma takım içerisinde, 1 ay öncesinde, haziran ayında olmuş. Haziran ayı içinde yaptıkları temizlik bir sonraki sürümü etkileyerek lead time değerlerini sallamış. Tabi bu temizliği önceden yapmaları ile uzun süre bekleyen iş miktarını azalttıklarından uzun vadede iyileşmeyi tetiklemişler. Kişisel Görüş: Bazen kısa vade uğruna uzun vadeyi göremeyip kendimizi göz göre göre uçuruma atabiliyoruz. Limitless takımının sorumluluklarını yönetmeyi kendi ellerine alması gerçekten takdir edilmesi gereken bir durum. İşte bu noktada liderlik ön plana çıkıyor; bir şeyleri kanıtlamak ve yeni bir yol çizebilmek.
• Ağustos – Eylül ayları arasında artan iş yüküne rağmen (mor çizgi; WIP) sabit tutulan çıktı sayısı (kesikli mor çizgi; throughput) takımın yetkinliğinin arttığını göstermektedir. Fakat yeni projenin baskısı ile artan WIP karşısında lead time değerleri artış göstermeye ve %75’lik ve %85’lik dilimin arası açılmaya başlamış olduğunu görebiliyoruz. Little’s Law burada da etkisini gösteriyor, eski işi bitirmeden yenilerine başlarsan iş bitirme süreleri artacaktır. Kişisel Görüş: Bu sonucu gören fakat bu şekilde ilerlemek durumunda kalan Limitless takımının ne sonuçlar elde edecekleri ve çıkarımlarının ne olacağı merak konusu. Sonuçta sistemini bilmeden bir akıntının içinde sürüklenmektense durumu gözlemleyip gemilerini kendilerinin yönlendirmesi değerli deneyimler yaşatacaktır. Bu çıkarımlardan umarım diğer ilgililer de bir sonuç çıkartabilir. Aralık verilerini bu yüzden çok merak ediyorum.

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 %76’sı 6 hafta içerisinde sürüme alınmış. Buradaki kilit kelime “içerisinde”. Sürüme çıkılan işlerin %76’sı 6 hafta sürmüş değil, en fazla 6 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, %76 ihtimalle sürüme alma süresi 6 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 Limitless takımının değerleri yok bu dağılımda, bütün sistem (analiz, test, sürüme alma) burada.

• %76 ihtimal ile 6 hafta (1,5 ay) içinde sürüme çıkılabilir.
• %85 ihtimal ile 13 hafta (~3 ay) içinde sürüme çıkılabilir.
• %94 ihtimal ile 17 hafta (~4 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)

Limitless 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 1 hafta içerisinde sürüme çıkılan bir iş hiç olmamış. En az 2 hafta bekledikten sonra işler sürüme çıkılabilmiş. Ve bu 2 hafta içerisinde çıkan işler 2. çeyrek içerisinde biten işlerin %10’unu oluşturuyor.
• 2. Çeyrek içerisinde biten işlerin %70’i 5 hafta içerisinde %80’i 8 hafta içerisinde %90’ı 14 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 %50 ihtimal ile 4 hafta 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 1 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. 2 hafta içerisinde sürüme çıkılan işlerin olasılığı da %33’e yükselmiş.
• 3. Çeyrek içerisinde biten işlerin %70’i 6 hafta içerisinde (%70’i 5 hafta içerisinde idi) %81’i 10 hafta içerisinde (%80’i 8 hafta içerisinde idi) %89’u 17 hafta içerisinde sürüme çıkılmış. (%90’ı 14 hafta içerisinde idi)

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 temmuz 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 (bir sonraki çeyrekte) göreceğiz.
• 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 hala %52’lik bir değer ile çok fazla bir şey değişmediğini görebilirim. Yani sistem içerisinde yapılan değişikliklerin aylık sürümlere etkisinin aynı kaldığını söyleyebiliriz. Uygulanan deneyimleme sistem içerisinde fark edilmedi fakat Limitless takımına değerli etkileri oldu. 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 Limitless 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.
• 3. Ç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ı: 10
• 3. Çeyrek sürüme çıkılan iş sayısı: 27

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. Sanırım bu iyileşmenin sistem içerisinde gözlemlenmesi şans eseri değil. ????

Gözlem

• Kasım ayından itibaren sistemin Freeze de olduğunu unutmamak gerek. Bu 4. Çeyrek grafiği aslında sadece Ekim ayını içermekte. 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.
• 4. Çeyrek içerisinde biten işlerin

%71’i 4 hafta içerisinde (%70’i 6 hafta içerisinde idi)

%82’si 5 hafta içerisinde (%81’i 10 hafta içerisinde idi)

%88’i 6 hafta içerisinde sürüme çıkılmış. (%89’u 17 hafta içerisinde idi)

• Sistemde en fazla görülen sürüme çıkış süresi 13 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ı bu iyileşmeyi getirmiştir. Limitless takımının hep birlikte sistemlerinin sorumluluğunu almaları ve bunu devam ettirebilmeleri için gereken iyileştirme (Kaizen) aksiyonlarını hayata geçirmeleri bu sonuçları doğurmuştur diyebiliriz. Tabi Limitless takımı daha iyi yorum yapıp, veri gösterebilecektir.
• Ekim ayında sürüme alınan işlerin sayısının 3. Çeyreğin %62’sine denk geldiğini görebiliyoruz. Kasım ayında Freeze olmasaydı ne olurdu acaba?

2. Çeyrek sürüme çıkılan iş sayısı: 10

3. Çeyrek sürüme çıkılan iş sayısı: 27

Sadece Ekim ayı sürüme çıkılan iş sayısı: 17

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ö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. Örnek 1: Nisan – Aralık arasında teste gönderilen ya da sürüme hazır işlerin %80’i 2 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 %80’i 2 hafta sürmüş değil, en fazla 2 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, %80 ihtimalle süresi 2 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 sürüme çıkacağı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.)

• %80 ihtimal ile 2 hafta içinde teste ya da sürüme hazır hale geliyor. (Müşteri gözünden bakıldığında 6 hafta içinde)
• %87 ihtimal ile 4 hafta içinde teste ya da sürüme hazır hale geliyor. (Müşteri gözünden bakıldığında 13 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 17 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)

Limitless 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

• 2. Çeyrek içerisinde işlerin

%60’ı 1 hafta içerisinde

%80’i 2 hafta içerisinde

en fazla 5 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

• 3. Çeyrek içerisinde biten işlerin

%59’u 1 hafta içerisinde (%60’ı 1 hafta içerisinde idi)

%78’i 2 hafta içerisinde (%80’i 2 hafta içerisinde idi)

%85’i 4 hafta içerisinde

%96’sı 8 hafta içerisinde teste ya da sürüme hazır hale getirilmiş. (En fazla 5 hafta içerisinde idi)

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 temmuz 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.
• 3. Ç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ı: 15

3. Çeyrek sürüme çıkılan iş sayısı: 28

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

• Kasım ayından itibaren sistemin Freeze de olması Limitless takımının sürüme hazır iş çıkarmasına engel değil. Bu yüzden 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 ayına ait verilerin olması” durumu burada söz konusu değil.
• 4. Çeyrek içerisinde biten işlerin

%76’sı 1 hafta içerisinde (%59’u 1 hafta içerisinde idi)

%82’si 2 hafta içerisinde (%78’i 2 hafta içerisinde idi)

%94’ü 4 hafta içerisinde sürüme çıkılmış. (%96’sı 8 hafta içerisinde idi)

• Sistemde en fazla görülen teste ya da sürüme hazır hale gelme süresi 5 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ı bu iyileşmeyi getirmiştir. Limitless takımının hep birlikte sistemlerinin sorumluluğunu almaları ve bunu devam ettirebilmeleri için gereken iyileştirme (Kaizen) aksiyonlarını hayata geçirmeleri bu sonuçları doğurmuştur diyebiliriz. Tabi Limitless takımı daha iyi yorum yapıp, veri gösterebilecektir.
• 4. Çeyrekte teste ya da sürüme hazır hale gelen işlerin sayısının (her ne kadar 4. Çeyrek verileri ekim ve kasım ayından oluşsa da) 3. Çeyrekten daha az olduğunu da görebiliyoruz.

2. Çeyrek sürüme hazır iş sayısı: 15

3. Çeyrek sürüme hazır iş sayısı: 28

4. Çeyrek (Ekim ve Kasım) sürüme hazır iş sayısı: 22

Bu verilere raporun ilk bölümündeki Talep Yetkinlik yorumlarından ulaşabilirsiniz.

15 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 Limitless takımı ile konuşmakta fayda var. Limitless takımının kendilerinin çıkarttıkları daha detaylı metrikleri bulunmakta ve bu metrikler ile kapasitelerini ve hangi yetkinlikte takım arkadaşına ihtiyacı olduklarını görüp başkalarına da anlatabiliyorlar.

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

— Alper Tonga