Kanban; Evrimsel Değişim – (You are Allowed to Think)
Kanban, 2000’li yılların başlarında ilk kez David J. Anderson tarafından uygulanan, karakteristik özelliklerini Yalın Üretim (Lean Production) ilkerinden (özellikle Taiichi Ohno’nun 1953 yılında Toyota’da uygulamaya başladığı yalın üretim tekniğinden) alan ve Kısıtlar Teorisi (Theory of Constraints) yanında Sistemsel Düşünme (Systems Thinking) gibi sistemik optimize yaklaşımlarını barındıran bir yalın/çevik metodolojidir.
kanban (看板)
/ˈkanban/
isim
1. Japon dilinde pano, tabela ya da işaret veren tahta anlamına gelen kelime.
2. Tam Zamanında (JIT) Üretim ortamında malzeme hareketlerinin kontrolü amacıyla kullanılan bir çizelgeleme yaklaşımıdır.
3. Kanban sistemlerinde kullanılan bilgi kartı.
Köken: Japonya.
İlk olarak kelimenin anlamından yola çıkmanın doğru bir başlangıç noktası olacağını düşünüyorum. Düşüncelerimi paylaşacağım konu Bilgi Teknolojileri sektöründe Kanban Metodolojisi, yazı içerisinde kısaca KANBAN olarak kullanacağım. Bu konuda yeterli sayıda Türkçe kaynağın olmaması ve olanların bir çoğunun da yanlış algılara sebep olmasından dolayı burada okuyacaklarınızı kaleme almak istedim.
Kanban konusunda otorite olmadığımı belirtmek isterim. Dunning Kruger efektinden (bit.ly/dnngkrgr) korkan biriyim. Fakat 2012 yılından bu yana Kanban üzerinde yaptığım çalışmalar, şirket ortamında gerçekleştirdiğim uyarlamalar ile elde ettiğim tecrübeler, ve tüm kazanımlarımın sonucunda T.C. Bilim, Sanayi ve Teknoloji Bakanlığı Verimlilik Genel Müdürlüğü tarafından her yıl düzenlenen Verimlilik Proje Ödülleri’nde 2016 yılı Orta Büyüklükteki İşletme Kategorsi’nde ikincilik ödülünü arkadaşlarım ile birlikte almam belki siz değerli okuyucuların beni değerlendirmesi için bir referans noktası oluşturur. Bu çalışmanın ödül başvuru dokümanına buradan (bit.ly/vpo2016PDF) ulaşabilirsiniz.
Kaizen felsefesi gereği deneyimlerimi yeni bilgiler ile sorgulayarak Kanban‘ın derinliklerine inmeye devam ediyorum. Bu yüzden burada dile getirdiğim fikirlerim ileride geçersiz kalabilir ya da güncelleme ihtiyacı olabilir, önceden uyarmak isterim. ???? Her şeyi sorgulayın; bu bilenen öğreti de yine takip ettiğim Kanban topluluğu tarafından “No Dogma” sloganı ile benimsenip farklı düşüncelere açık kapı bırakarak topluluğun kendini geliştirmesinin önünü açmak için yaygınlaştırılmıştır. Diğer bir sloganımız da, aynı zamanda bu yazının başlığı oluyor, “You are allowed to think!”. Bu slogan, metodolojiyi uygularken ve yorumlarken takıldığım noktalarda kendi kendime tekrar tekrar söylediğim ve çözüm yoluna ulaşmamda yardımcı olan katalizörlerden biridir.
Takdir edersiniz ki bu konuyu tümüyle ele alarak okunması kolay bir yazıya sığdırmak mümkün değil. Bu yüzden, 3 bölümden oluşacak bir dizinin ilk parçası olarak bu yazıyı sizlerle paylaşıyorum. Bu bölümde sorunun direk kalbine inip, Kanban‘ın ne olduğuna çok odaklanmak yerine ne olmadığını anlatmak sanırım hem “No Dogma!” hem de “You are allowed to think!” sloganlarına daha uygun olacaktır. O yüzden üçlemenin bu ilk sayısında benden Kanban‘ın temel ilkeleri ve ana pratiklerinden bahsetmemi beklemeyiniz. Eğer Kanban konusunda herhangi bir bilgiye sahip değilseniz serinin bu ilk yazısı sizin için biraz ileri seviye gelebilir.
Haydi başlayalım.
Kanban, 2000’li yılların başlarında ilk kez David J. Anderson tarafından uygulanan, karakteristik özelliklerini Yalın Üretim (Lean Production) ilkerinden (özellikle Taiichi Ohno’nun 1953 yılında Toyota’da uygulamaya başladığı yalın üretim tekniğinden) alan ve Kısıtlar Teorisi (Theory of Constraints) yanında Sistemsel Düşünme (Systems Thinking) gibi sistemik optimize yaklaşımlarını barındıran bir yalın/çevik metodolojidir.
Esential Kanban Condensed (Anderson and Carmichael, 2016, goo.gl/ZbtDIk) kitapçığının ön sözünde Janice Linden-Reed (President, Lean Kanban, Inc.) Kanban‘ı “Kanban işlerimizin nasıl işlediğini bize gösteren bir metottur” diye tanımlıyor. Hem ilk başta atıfta bulunduğum sözlük anlamı ve bu tanım Kanban‘ın görselleştirmeye ne kadar çok önem verdiğini anlatmaya yetiyor. Bir durum zihnimizde görselleştirildiği zaman daha iyi anlaşılıyor. Sistem içerisinde akışı engelleyen bir durumu ya da tıkanmayı da idrak etmenin en iyi şekli sistemin görselleştirilmesi ile olabilir (Beynimiz görsel bir varlıktır. j.mp/brainVis).
Çok fazla tanımlara, ilkelere ve pratiklere bu yazıda girmeyeceğimi baştan söylemiştim ama âdettendir küçük bir tarihçe ve tanım ile protokolümüzü yerine getirdik. Şimdi kanayan yaramıza ve herkesin beklediği gıybet konularına geri gelelim.
Çoğu konuda olduğu gibi bu konuda da 10-15 sene geriden geliyoruz. Ülkemizdeki çeviklik kültürünün yavaş yavaş yayılması ile birlikte Scrum‘dan sonra Kanban da Türkiye’deki çevik toplulukların konuşmaya başladığı bir konu olmaya başladı. Fakat ne yazık ki kişiler Kanban‘ı “Scrum‘ın sprint/timebox olmayan hali,” “bakım takımları için uygun ama proje takımları için değil,” “ToDo listesinden hallice,” “küçük ölçekli dönüşümlerde kullanılabilen bir yöntem,” “Waterfall gibi ama çevik metot” gibi maruz kaldığımda beni benden alıp bu diyarlardan göçmeme sebeb olacak daha nice anlatımlarla tanımlamaya çalışıyorlar.
Yukarıda belirtilen anlatımların sadece iki tanesini ele alacağım ve her takıldığınız konuda lütfen “You are allowed to think!” sloganını aklınıza getirin ve size mantıklı gelen açıklamayı ya da yorumu seçin.
1. İlk mercek altına alacağımız “Scrum‘ın sprint/timebox olmayan hali” tanımlaması; Daha önceden Scrum uygulamış olan takımlar Kanban ile tanıştıklarında ilk fark ettikleri fakat tam algılayamadıkları durumun bu olduğunu düşünüyorum. Kanban içerisinde sprint ya da timebox uygulanmamalı diye bir yönlendirme yoktur. Kanban‘ın birinci temel ilkesi “süregelen sistemi kullanarak başla” olduğundan, sistemin olağan durumuna ya da isteklerine göre timebox ya da sprint süresi pekala Kanban içerisinde de sürdürülebilir.
Bunu bir kenara koymamızla birlikte asıl kaçırılan nokta şudur; Kanban akış odaklıdır. Sistem içerisindeki dar boğazların ve çöp noktalarının görülüp yok edilmesi ve işlerin en kısa zamanda bitirilmesi için ortam sağlar. Yani Lead Time değerimizi azaltmamızı ön görür. Lead Time değerleri bazı işler için 2 ya da 3 gün olabilir. Scrum‘da belirtilen en düşük sprint süresinden bile daha kısa Lead Time değeri olan kanban sistemleri bulunmaktadır; 3 günde bir release yaptığınızı düşünün.
Lead Time hedefleri olasılığa dayalı öngörülebilir planlama (probabilistic predictive planning) yöntemleri ile hesaplanır. Little’s Law ve Monte-Carlo simulasyonları bu planlamalarda kullanılan yöntemlerden bir kaçıdır.
Yani Kanban uygularken sonsuz süreniz yoktur, daha sık iterasyonlarınız bile olabilir.
“Bakım takımları için uygun ama proje takımları için değil”
Lütfen yapmayın, bu tanım her kullanıldığında bir yavru kedi intihar ediyor. ???? Scrum uygulamaya çalışan ya da Scrum yaygınlaştırılması karar verilmiş toy organizasyonların bünyesi içindeki bakım takımlarında yaşanan sorunlardan sonra ortaya çıkmış bir görüş diye düşünüyorum (Scrum‘ı yerlere vurduğumu düşünüyorsanız yazının sonuna bakınız).
Şimdi şu sloganı tekrarlayıp bir düşünelim: “You are allowed to think!”
Bakım takımlarında çalışan bir yöntemin mantık olarak proje takımlarında da çalışmasını beklerim çünkü diğerine göre daha kolay bir sistem içerisinde çalışıyorlar.
Scrum der ki; Sprint backlog içerisine alınan maddeler o sprint boyunca yapılacak olan işleri içerir ve takım bu maddelerin bitirilmesi için söz verir; commitment. Takımın odaklanmasını bölmemek ve sözünü yerine getirmesi için sprint backlog içerisine sprint başladıktan sonra yeni bir iş alınmamaya çalışılır. Çok güzel ve mantıklı bir yönlendirme.
Fakat çoğu bakım takımı iş yükü altında boğulduğundan öngörülebilen bir sistem yaratamıyor ve ne zaman nerede bir problem yaşanacağını göremiyor. Yine bu iş yükünden dolayı sorunun kaynağına inip kalıcı bir çözüm üretemiyor. Bu yüzden planlama etkinliğinde hazırlanan sprint backlog araya giren daha acil işler ile sabote ediliyor, verilen söz yerine getirilemiyor. Bu durum sadece bakım takımlarında değil sürekli bölünen bir proje takımı için de geçerli; hep genel müdürünüzden iş geldiğini düşünün.
Peki Kanban bunu nasıl çözüyor? İlk temel kuralı tekrar hatırlayalım, “süregelen sistemi kullanarak başla.” Daha sonra Kanban‘ın ana pratiklerinden ikisini hatırlayalım, “yapılan işi sınırla (WiP; work in progress)” ve “akışı yönet.”
Öngörülebilen bir sistem niye oluşturamıyoruz? Çünkü yetişilmesi gereken ve kuyrukta bekleyen çok iş var. O zaman WiP sınırlamalarını devreye al. Little’s Law’a (L= λW) göre WiP = Lead Time (zaman) * Throughput (iş/zaman). Eğer üzerinde çalıştığım işleri azaltırsam Lead Time değerim de azalır; işlerin süresi kısalır. Lead Time kısalır ise ürün çıktım artar (throughput). Üzerimdeki işi sınırlandırarak daha kaliteli iş çıkartabilirim ve kök soruna daha çok zaman ayırabilirim, slack time yaratabilirim.
Süregelen sistemi kullanarak başladığımdan, daha önceki süreç nasıl ise öyle ilerlerim ve iyileştirme noktalarını görerek aksiyon alırım; kaizen. İlk başta takıma sprint sözü gibi bir yaptırım getirmem, çünkü yeni düzene alışmak zaman alacaktır. Alışılan sistem içerisindeki iyileştirme noktalarına odaklanmak takım için daha kolay.
Bu açıklamalar ışığında sizce Kanban sadece bakım takımları için mi uygundur?
Yukarıda yazdıklarımdan Scrum‘ı kötülüyorum gibi algı ortaya çıkar ise bu da yanlıştır. Yukarıda ele alınan durumların çıkış noktasının Scrum çerçevesi ile alakası yoktur ve hepsinin de Scrum içinde bir çözümü vardır. Eğer organizasyonel dönüşümü Scrum çerçevesi içerisinde bütün birimlerde hızlı bir şekilde gerçekleştirebilirseniz her tip takımda sorunsuz Scrum uygulanabilir. Bu durumun yegane sebebi Agile kültürünü benimsememiş ya da daha yolun başında bulunan organizasyonlardan kaynaklı olduğunu düşünüyorum. Tabi bu kültürü hızlı bir şekilde benimseyecek bir organizasyon ve değişimi iyi yönetecek kişilerin bir arada olabilme ihtimali kanatimce oldukça düşük.
Scrum devrimsel bir metottur ve her devrimde olduğu gibi geride kalanlar, yetişemeyenler olacaktır ve bu sıkıntı yaratacaktır.
Kanban ise evrimsel bir metottur. En basit hali ile süregelen sistemi inceleyerek yalın üretim, kısıtlar teorisi ve sistemsel düşünme yaklaşımları ile çöp üreten ve bekleme yaratan noktaları yok ederek sistemi iyileştirmeyi ve hafifletmeyi amaçlar. Bu hafifleme ve yalınlaşma ile organizasyon daha çevik tepkiler verebilecektir. Evrimsel oluşundan dolayı da diğer metotlarda yaşanan organizasyon kültüründen kaynaklı tepkiler en düşük seviyede olacaktır.
Bu yazımda net bir Scrum–Kanban karşılaştırması yapmak istemiyordum ama kaçış yok gibi duruyor. Her ne kadar ikisi de bir birinden bağımsız bir yöntem ve karşılaştırılamaz desek de bunu herkes yapıyor.Şu ana kadar okuduklarım arasında Scrum ve Kanban karşılaştırmasını en iyi ve en yalın yapan sanırım Karl Scotland. Kendisi şöyle demiş;
“#Scrum focuses on being #agile which may lead to improving. #Kanban focused on improving, which may lead to being agile.” – Karl Scotland.
Birinci bölümün sonu.
Teşekkürler,
Yorumlar