Kanban Neden İşe Yarar ve Ekibinizin Buna Hazır Olup Olmadığını Nasıl Anlarsınız

Çoğu ekip Kanban'ı biri bir blog yazısı okuduğu için benimser. Daha akıllıca soru, Kanban'ın çözdüğü sorunların ekibinizin gerçekten yaşadığı sorunlar olup olmadığıdır.

Çoğu ekibin tanıdığı bir an vardır; genellikle sekiz dokuz kişiyi aştıkları sıralarda gelir. İş yapılıyor, e-postalar gidiyor, özellikler yayına çıkıyor, müşteriler yönetiliyor; ama kimse diğerlerinin ne yaptığına dair net bir fikre sahip değil. Projeler birikiyor. Sözler veriliyor, sonra sessizce unutuluyor. Her toplantıdan önce yirmi dakikanızı, bir işin gerçekte nerede olduğunu çözmeye harcıyorsunuz. Yanıt genellikle "bir yerlerde" oluyor.

Kanban'ın çözmek için tasarlandığı sorun budur. Strateji belirleme, doğru insanları işe alma ya da kültür inşa etme sorunu değil; ekibinizin ne üzerinde çalıştığını ve neyin önüne engel çıktığını bilmenin, yıpratıcı ve operasyonel sorunu.

Bu kadar çok ilgi çekmiş bir araç için şaşırtıcı derecede alçakgönüllüdür. Kanban kuruluşunuzu düzelteceğini iddia etmez. Sadece işi görünür kılar. Ve görünürlük tutarlı biçimde uygulandığında, sonrasında çok sayıda şeyi değiştirdiği ortaya çıkar.

Kanban aslında nereden geldi

Sözcük Japoncadır ve "tabela" ya da "ilan panosu" anlamına gelir; sistemi 1940'ların sonunda Toyota, üretim tesislerindeki stokları yönetmek için geliştirdi. Fikir basitti: Parçaları sabit bir plana göre üretmek yerine, fabrika onları yalnızca sonraki istasyon ihtiyaç olduğunu bildirdiğinde üretecekti. Fiziksel bir kart (kanban) bir talep olarak hat boyunca geri yolculuk ederdi. Hiçbir şey spekülatif olarak üretilmezdi. Hiçbir şey gereksiz yere birikmezdi.

Toyota'nın sahip olduğu ve yazılım ekiplerinin sonradan ödünç aldığı içgörü şudur: Bir sistemdeki verimsizliğin çoğu insanların fazla yavaş çalışmasından değil, yanlış işin yanlış zamanda yapılmasından kaynaklanır. Aynı anda başlatılan çok fazla iş. Çok geç olana kadar kimsenin fark etmediği darboğazlar. Bir yerde bitmiş hâlde bekleyen iş, başka bir yerde ise iş yükü altında ezilen bir sonraki adım.

Yazılım geliştiricileri, özellikle 2000'lerin başında Microsoft gibi şirketlerde, bu fikirleri bilgi işine uyarlamaya başladı. Kartlar görevlere dönüştü. Fabrika istasyonları, iş akışındaki aşamalara dönüştü. Tabela ise önce fiziksel, sonra dijital bir panoya dönüştü; ekipteki herkes bir bakışta nelerin sürmekte olduğunu, nelerin beklediğini ve nelerin bittiğini görebiliyordu.

Bir Kanban panosu size gerçekte ne gösterir

Temel bir Kanban panosunun üç sütunu vardır: Yapılacak, Devam Eden ve Tamamlanan. Birçok küçük ekip için bu yeterlidir ve başlamak için iyi bir yerdir. Ancak gerçek değer, bu aşamaları işinizin nasıl aktığına göre (nasıl akmasını dilediğinize göre değil) özelleştirmeye başladığınızda ortaya çıkar.

Bir içerik ekibi şunları kullanabilir: Fikir, Brif, Taslak, İncelemede, Planlandı, Yayınlandı. Bir yazılım ekibi "Devam Eden" sütununu geliştirme, kod incelemesi ve QA için ayrı sütunlara bölebilir. Bir danışmanlık ekibi Keşif, Teklif, Aktif, Müşteri Yanıtı Bekleniyor ve Kapandı aşamalarını izleyebilir. Aşamalar gerçek devir teslimleri ve gerçek bekleme sürelerini yansıtmalıdır: işin el değiştirdiği ya da başka bir şey gerçekleşene kadar beklediği yerleri.

Ortadaki sütundaki karta dikkat edin: sekiz gündür süren, engellenmiş olarak işaretlenmiş depo denetim raporu. Panosu olmayan bir sistemde bu görev, kimse hareket etmediğini fark etmeden iki hafta daha bekleyebilirdi. Biri üçüncü bir tarafı bekliyor olabilir. Ya da engelleyenin kendisi olduğunun farkında olmayan bir yöneticiden karar gerekiyor olabilir. Pano tıkanıklığı görünür kılar. İşin büyük kısmı budur.

İşe yarayan kural: WIP limitleri

Kanban'ı düzgün kullanan ekipleri, sadece daha şık bir yapılacaklar listesi olan ekiplerden ayıran tek bir kavram varsa, o da devam eden iş limitleridir; kısaca WIP limitleri. Fikir, her sütunda aynı anda bulunmasına izin verilen azami öğe sayısı olmasıdır. Bir sütun dolduğunda, bir şey dışarı çıkana kadar daha fazla iş ekleyemezsiniz.

Bu sezgilere aykırı gelir. Aynı anda daha fazla görevin sürmesi, daha çok işin yapıldığı anlamına gelmez mi? Hayır. İnsanlar aynı anda çok fazla işle uğraştığında gerçekte olan, her şeyin daha uzun sürmesidir. Bağlam değiştirmek pahalıdır. Yarım kalmış işler koordinasyon yükü yaratır. Ve on şey "devam ediyor" olduğunda, hangilerinin gerçekten ilerlediğini ve hangilerinin sadece işaretlenmeden takılıp kaldığını anlamak çok zordur.

Devam Eden sütununuzda üç olarak belirlenmiş bir WIP limiti, dördüncü işin birinin masasına geldiği anda ekipten birinin karar vermesi gerektiği anlamına gelir: Mevcut görevlerden hangisi önce tamamlanacak? Bu, önceliklendirmeyi zorunlu kılar. Konuşmayı zorunlu kılar. Ve yeni iş başlatma hızı yavaşlasa bile, tek tek işlerin daha hızlı tamamlanmasını sağlama eğilimindedir.

Kanban ve Scrum: Ekiplerin hep sorduğu soru

Yazılım ekiplerinin ya da modern operasyon düşüncesinin çevresinde biraz zaman geçirdiyseniz, muhtemelen Scrum ile karşılaşmışsınızdır; işi sabit iki haftalık sprintlere, planlama oturumlarına, retrospektiflere ve Scrum Master ile Product Owner gibi tanımlı rollere ayıran çerçeve. Birçok ekip Scrum ile Kanban'ı rakip metodolojiler olarak görür ve birini seçmesi gerektiğini düşünür. Aradaki fark aslında bundan daha basittir.

Birçok ekip, özellikle saf yazılım mühendisliği ekibi olmayanlar, Scrum'ın seremonilerini ağır, sabit sprint düzenini ise süregelen operasyonel işe uygulamayı zahmetli bulur. Pazarlama ekipleri, müşteri başarı ekipleri, operasyon ekipleri ve her şeyi aynı anda yöneten kurucuların işi nadiren iki haftalık döngülere düzgünce oturur. Kanban'ın sürekli akış modeli genellikle onlara daha iyi uyar.

Bununla birlikte, birçok ekip ikisini birleştirir. Ürün geliştirme için sprint tarzı planlama döngüleri kullanırken, hangi sprintte olursanız olun akıp gelen operasyonel ve destek işleri için bir Kanban panosu işletirler. Bu son derece makul bir hibrit yaklaşımdır.

Panonuzun otuz saniyede yanıtlaması gereken üç soru

Bir Kanban panosu, ona bakıp kimseyle konuşmadan şu üç soruyu hızlıca yanıtlayabildiğinizde en yararlıdır: Ekip şu anda ne üzerinde çalışıyor? İş nerede takılıyor? Yapılması gereken ama başlanmamış bir şey var mı?

Panoya baktıktan sonraki otuz saniye içinde üçünü de yanıtlayamıyorsanız, pano büyük olasılıkla düzgün sürdürülmüyor demektir. En sık görülen başarısızlık biçimi, görevlerin oluşturulup hiç taşınmadığı bir panodur; gerçek işin canlı haritası yerine iyi niyetlerin mezarlığına dönüşür. Güncel olmayan bir pano panosuz olmaktan daha kötüdür, çünkü sahte bir görünürlük hissi yaratır.

Bir panoyu sürdürmek için gereken disiplin gerçektir. İş hareket ettiğinde görevlerin de hareket etmesi gerekir. Engellenen öğeler iki hafta sonra değil, takıldıkları anda işaretlenmelidir. Kartların net sahipleri olmalı ve sahipler kartlarını güncellemelidir. Bunların hiçbiri çok zaman gerektirmez (iyi yürütülen bir Kanban uygulaması kişi başı günde beş ila on dakika sürebilir); ama tutarlılık gerektirir. Kanban'dan en çok fayda sağlayan ekipler, panoyu ek bir kayıt tutma alıştırması olarak değil, tek doğru kaynak olarak görenlerdir.

Kanban'ın yapmadığı şeyler

Kanban bir strateji aracı değildir. Neyin üzerinde çalışmanız gerektiğini bulmanıza yardımcı olmaz; yalnızca üzerinde çalışmaya zaten karar verdiğiniz şeyleri yönetmenize yardımcı olur. Kuruluşunuzun bir önceliklendirme sorunu, belirsiz bir yetki sorunu ya da süreçte değil liderlik davranışında kök salmış "eskileri bitirmeden çok fazla proje başlatıyoruz" sorunu varsa, Kanban panosu bu sorunları ortaya çıkarır ama çözmez.

İyi yönetimin yerini de tutmaz. Pano, birebir görüşmelerin, düşünceli görev devrinin ya da belirli işlerin neden önemli olduğuna dair net iletişimin yerini almaz. Ekipler bazen süreç araçlarını, süreç gerçekte yöneticinin işi olan ilişkisel ve örgütsel işi üstlenir diye umarak benimser. Üstlenmez.

Yapacağı şey, çoğu ekibi yavaşlatan ortamsal belirsizliği azaltmaktır. "Kim ne üzerinde çalışıyor", "bu bitti mi" ve "bir sonraki ne alayım" soruları, ortak ve görünür bir sisteme sahip olmayan kuruluşlarda çok büyük miktarda düşük değerli iletişim üretir. Kanban bu gürültünün çoğunu ortadan kaldırır. Ve bu gürültünün baskın sorun olduğu ekipler için fark önemlidir.

Üç günlük bir atölye olmadan nasıl başlanır

Gördüğüm en iyi Kanban uygulamaları küçük başladı ve gelişti. En kötüleri ise bir danışman, iki günlük bir offsite etkinliği ve üçüncü haftada kimsenin kullanmadığı güzel tasarlanmış bir pano içeriyordu.

Ekibinizle olduğu gibi, gerçekte sahip olduğunuz işle başlayın. Üç sütun oluşturun: Bekleyen İşler, Devam Eden, Tamamlanan. Ekibinizle otuz dakika geçirip mevcut her iş öğesini bir karta koyun. Tek bir kuralda anlaşın: Bir şeye başladığınızda panoya girer. Hareket ettiğinde kartı siz taşırsınız. İki hafta boyunca başka hiçbir şey yapmayın.

İki hafta sonra panoya birlikte bakın. İşler nerede birikti? Herkesin öncelik olduğunu söylediği hangi şeyler Bekleyen İşler'de kaldı? Hangisi beklenenden hızlı ilerledi? Ne takıldı ve neden? Gözlemlediklerinizi sütunları netleştirmek ve ayrıntı eklemek için kullanın. Belki "Devam Eden" sütunu "Devam Eden" ve "Dış Yanıt Bekleniyor" olarak ikiye bölünmeli. Belki o adım sürekli kaybolduğu için "İncelemede" adında bir sütuna ihtiyacınız var. Panonun, bir metodoloji kitabının nasıl görünmesi gerektiğini söylemesine göre değil, gerçek işinizin ortaya koyduklarına göre evrilmesine izin verin.

Uzun oyun: akış metrikleri

Bir Kanban sistemi çalışmaya başladığında, çoğu ekibin hiç kullanmadığı veriler üretir. Bunların en önemlisi teslim süresidir (lead time): bir görevin oluşturulmasından tamamlanmasına kadar geçen toplam süre. Tipik bir görevin ortalama teslim süresi on iki günse ve bunun beş gün olmasını istiyorsanız, artık hedef alacağınız bir sayınız ve o fazladan yedi günün nereye gittiğini gösterecek bir panonuz var demektir.

Çevrim süresi (cycle time) yalnızca aktif çalışma dönemini ölçer ve görevin bekleyen işlerde geçirdiği zamanı hariç tutar. Verim (throughput) ise ekibinizin haftada kaç öğeyi tamamladığını ölçer. Kartların ne zaman oluşturulduğunu ve ne zaman kapatıldığını not etme konusunda disiplinliyseniz, bu metriklerin hiçbiri özel yazılım gerektirmez. Ve birlikte, tahmine dayalı herhangi bir planlama sürecinden çok daha dürüst bir ekip kapasitesi resmi verirler.

Çoğu küçük ve orta ölçekli ekip buraya hiç gelmez. Kanban'ı bir görünürlük aracı olarak kullanırlar (ki bu tek başına değerlidir) ve daha ileri gitmezler. Sorun değil. Ama paydaşlara bir şeyin ne zaman biteceği konusunda taahhütte bulunmak istiyorsanız ya da bazı işlerin neden beklenenden üç kat uzun sürdüğünü anlamak istiyorsanız, metrikler ihtiyaç duyduğunuzda orada.