Kanban Metodunun İlkeleri

İlk önce temel ilkeleri kabul edin…

Şimdi yaptığınız şeyle başlayın…

Kısa aralıklarla, evrimsel değişimin sürdürülmesini kabul edin…

Var olan süreç, roller, sorumluluklar & unvanlara saygı duyun…

Daha sonra aşağıdaki 5 maddeyi gerçekleştirin.

• İş akışını görselleştirme

• Aynı anda gerçekleştirilen iş sayısını limitleme

• Akışı yönetme

• Süreçleri belirgin hale getirme

• İşbirliği içinde gelişimi destekleme(modeller & bilimsel metotlar kullanma)

Hadi bu maddeleri tek tek inceleyelim…

Şimdi Yaptığınız Şeyle Başlayın

Kanban Metodu sürecinizi değiştirmenizi istemez. Temelinde var olan sürecin evrimleştiği düşüncesi bulunur. İçeriğinde mühendislik çalışması bulunan yeni bir süreç tanımı ya da yeni bir çalışma şekli yoktur. Kanban Yazılım Geliştirme Süreci ya da Kanban Proje Yönetim Metodu diye bir şey yoktur.

Kısa Aralıklarla, Evrimsel Değişimin Sürdürülmesini Kabul Edin

Bir organizasyon ya da takım, içinde bulundukları şartların yumuşak ve evrimsel bir yaklaşımla gelişim için birincil neden olduğunu kabul etmelidir. Belki takım üyelerinin direnişinden dolayı yakın zamanda büyük bir dönüşüm başarısız olmuştur. Organizasyon politikaları gereği, böyle büyük bir dönüşümün yöneticiler için çok riskli olduğu düşüncesiyle teklif bile edilmemiştir ve uygulanmamıştır. Anlaşma olmadan bu yavaş, yumuşak, evrimsel ve artımlı yaklaşım doğru yoldur eğer evrimsel yaklaşım uygulanmazsa Kanban girişimi için doğru çevre ya da yönetim desteği olmayacaktır.

Var Olan Süreç, Roller, Sorumluluklar & Unvanlara Saygı Duyun

Bir organizasyon, kabul görür bir şekilde çalışan ve korumaya değer bazı öğelere sahiptir. Geleceğin değişikliğine ortam hazırlarken korku da ortaya çıkarılmalıdır. Hali hazırda var olan rollere, sorumluluklara, iş unvanlarına saygı göstermeyi kabul ederek başlangıçtaki korkuyu gideriniz. Bu, Kanban girişiminiz için daha geniş bir destek almanızı sağlayacaktır. Belki unvanlarda, rollerde ve sorumluluklarda değişiklik gerektiren daha köklü bir dönüşümden örnekler vererek belki de bazı pozisyonları tamamıyla kaldırarak bireylerin bu yavaş geçişin yararlarını daha iyi anlamasını sağlayın.

İş Akışını Görselleştirme

İyi ki kitabımda Değer Akışı terimini kullanmayı seçmemişim. Görünen o ki bu terim bir mecaz ile yazılım geliştirmede bazı itirazları beraberinde getiriyor. Değer Yaratma Ağı daha uygun bir terim olduğuna dair bir tartışma da bulunuyordu. Janice Linden-Reed ve ben, DZone RefCard’ta bu terimi kullandık. Fark ettim ki bu sadece akıl karışıklığına ve karmaşaya neden oluyor. Değer Yaratma Ağı, yazılım geliştirmeye dahil olan ya da IT operasyon problemlerini çözen kişilerin iletişimidir. Halbuki benim ilgilendiğim Kanban Metodu ile bilgi erişim sürecinin kendisidir.

Tipik olarak işteki durum değişikliklerini arıyoruz. Bu genelde o iş hakkında yeni bilgi oluşturmak için gerekli aktivitedeki değişikliği yansıtır. Örneğin, analiz(bir aktivite) bilgi üretir. Azalan dönüşler noktasına ulaştığındaysa işin analiz tamamlanmıştır şeklinde düşünerek yeni bir aktiviteye geçeriz örneğin dizayn ya da geliştirme. İş Akışının Görselleştirilmesi diye anlatmak istediğim konu bu sürecin görselleştirilmesidir.

Aynı Anda Gerçekleştirilen İş Sayısını Limitleme

Aynı anda gerçekleştirilen iş sayısını limitleme şu anlama gelir; iş akışının bir bölümüne ya da tümüne bir “pull sistem” uygularız. Pull sistemi bir Kanban sistemi, CONWIP sistemi, DBR ya da başka bir sistem olabilir. Kritik öğeler, iş akışındaki aynı anda gerçekleştirilen iş sayısını her durum içinde limitlenmesidir ve aynı anda gerçekleştirilen iş sayısında bir açık olduğunda kapasitenin alabileceği kadar yeni bir işin çekilmesidir.

Akışı Yönetme

İş akışı içinde iş maddelerinin her durum için akışı izlenmeli ve rapor edilmelidir. Bu işlem genellikle Akışı Ölçme olarak adlandırılır. Akış ile anlatmak istediğimiz şey harekettir. Biz hareketin hızıyla ve pürüzsüzlüğüyle ilgileniriz. İdeal olarak hızlı ve pürüzsüz bir akış isteriz. Hızlı, pürüzsüz hareket şu anlama gelir; sistemimiz hızlı bir şekilde değer üretiyordur ki bu riski minimum seviyeye çeker ve bekleme maliyetini önler. Aynı zamanda sistemimizin öngörülebilir bir şekilde çalışmasına katkıda bulunur.

Süreçleri Açık Hale Getirme

Yazılım geliştirme mekanizması ya da IT operasyon süreçleri açık hale getirilene kadar bu konuda gelişmeyi sağlayacak bir tartışma ortamı yaratmak genelde zor ya da imkansızdır. Bir şeylerin nasıl çalıştığı ve işin gerçekte nasıl bitirildiğine dair açık bir anlayış olmadan problemlerin tartışılması duygusal, anekdot şeklinde ve kişisel olma eğilimindedir. Açık bir anlayış ile daha mantıksal, deneysel, nesnel tartışmaların olması daha olasıdır. Bu daha çok geliştirme önerileri çevresinde bir fikir birliği oluşturmaya benzer.

İşbirliği İçinde Gelişimi Destekleme(Modeller & bilimsel metotlar kullanma)

Süreç problemleri konusunda tartışmaları eninde sonunda canlandıran “Aynı Anda Gerçekleştirilen İş Sayısını Limitleme”dir. Akışa engel olan ya da karışıklığı getiren şeyler ki bu akış tutarsız veya düzensiz anlamına gelir, genelde WIP’te bir sorunla sonuçlanır. Takım limiti bozma seçeneğine sahiptir, sorunu görmezden gelebilir ve devam edebilir ya da sorunla yüz yüze gelir ve tartışıp bir değişiklik önerebilir.

Takımlar işin, iş akışının, sürecin ve riskin teorisi hakkında ortak bir anlayışa sahip olduğunda büyük olasılıkla problem hakkında ortak bir anlayış oluşturabilirler ve fikir birliği ile kabul edilmiş iyileştirme aksiyonları önerebilirler. Kitabımda kullanışlı olan 3 model önerdim: Kısıtlar Teorisi(darboğazlar çalışması), Derin Bilgi Kuramı(bir çeşitlilik ve bunun süreçleri nasıl etkilediği üzerine çalışma) ve Lean Ekonomi Modeli(israf kavramı ya da muda, muri ve mura üzerine). Diğer modellerle de çalışılabilir örneğin Gerçek Opsiyon Teorisi.

Modellerin kullanımı ile takım, değişiklik hakkında ya da değişikliğin etkisi hakkında tahmin yapabilir. Değişiklik uygulandıktan sonra sonuç, akışı ölçerek ve datayı inceleyerek gözlemlenebilir. Sonuç modelden beklenen tahminle karşılaştırılabilir ve değişiklik bir ilerleme ya da değil şeklinde değerlendirilebilir. Sonrasında gerçekte ne olduğunu gözlemleme ve tahmin ile karşılaştırma bilimsel metodun kullanılmasıdır. Bu bilimsel yaklaşım inanıyorum ki hem bireysel hem organizasyonel seviyede öğrenmeye yardımcı olacaktır. Bundan dolayı Kanban’da bilimsel yaklaşımın kullanımı öğrenen organizasyonların ortaya çıkmasında etkili olur.

Kompleks Adaptif Sistemler

Kanban Metodunun ilkeleri artımlı şekilde gelişimi teşvik edecek ve bu gelişimi gösterecek şekilde dizayn edilmiştir. İyileştirmeler acil davranışlardır. Sonuç tahmin edilemez. Tümüyle mantıklı bir şekilde tahminde bulunarak bir şeylerin değişeceğini öngörmektir. Kanban Metodu gibi Kompleks Adaptif Sistemler yaklaşımı da organizasyondaki değişimi yönlendirmeyi temsil eder. Kompleks Adaptif Sistemler basit kurallar kullanır ve acil davranışları teşvik etmek için tohumları atarlar. Bu basit kurallar 5 çekirdek ilke içinde bulunuyor, şimdi yaptığınız şeyle başlayın, kısa aralıklarla, evrimsel değişimin sürdürülmesini kabul edin, var olan iş pratiklerine, roller, sorumluluklar ve unvanlara saygı duyun. Yapılacak bir sonraki şey acil değişikliklerdir. Bunun ötesinde tahmin yapamayız. Sistem izlenmeli ve aksiyon alınmalıdır. Basit kuralların kullanımı örneğin aynı anda gerçekleştirilen iş miktarını limitleme ve iş akışının görselleştirilmesi değiştirilmiş olmalıdır ki istenen sonucu üreten acil davranışlara yön verilebilsin.

Sistem Tasarımcı Rolü

Bu rol sistemin basit kurallarını yönetir ve istenen sonucu üretme sürecinde değişiklik yapar. Bu yeteneğin her takım üyesinde bulunması olası değildir. Çoğunlukla sistem tasarımcısı ya da sistem tasarım yöneticisi rolünü biri üslenir. Bu kişi yönetici, süreç mühendisi ya da dışarıdan bir koç olabilir. Sistem tasarımcısı Kanban girişiminin uygulanmasını ve Kanban sisteminin tasarımını yönetmelidir. Sistem tasarımı, kompleks adaptif sistem değiştikçe, acil davranış değişikliklerine cevaben ve ürettiği sonuca göre zamanla değişmelidir.

http://www.djaa.com/principles-kanban-method-0