Non-IT Takımlarda Agile-Lean Yaklaşımın Kullanılması ve Ölçeklendirme
Agile ve Lean yaklaşımlar günümüzde birçok firma tarafından deneyimlendi ve kullanılmaya devam ediyor. Bir önceki makalemde( https://muhammedsimsek.medium.com/agile-trend-analizi-2021-610283ab8e71 ) belirttiğim üzere 5 yıldan fazla süredir Agile-Lean yaklaşımları benimseyen organizasyon sayısı geçen seneye nazaran %20 ye yakın artmış durumda.
Ancak bu zamana kadar Agile-Lean yaklaşımlar genellikle IT ekiplerinde yaygın olarak kullanılırken organizasyonun diğer birimlerinde çok fazla benimsenme fırsatı bulamamıştı.
Ta ki 2021 yılına kadar. 2021 yılında Non-IT ekiplerin (Marketing, HR, Sales…) Agile-Lean yaklaşımları benimseme oranı bir önceki seneye nazaran %250 civarında artmış durumda.
Bu da bize gösteriyor ki Agile-Lean yaklaşımlar artık sadece IT veya yazılım geliştirme ekiplerinin tekelinde değil, tüm organizasyona yayılmaya başlamış durumda.
Peki Non-IT ekiplerde Agile-Lean’i metodoloji veya yaklaşımların karmaşık dünyasıyla ürkütmeden nasıl yerleştirebiliriz? Ve takım seviyesinin üstünde bu yaklaşımı yukarı seviyeye doğru nasıl ölçekleyebiliriz?
Bir Agile Coach olarak bir organizasyonda görev aldığımda genel olarak karşılaştığım manzara şu oluyor;
· IT ekipleri yoğunlukla Scrum Framework’ünü kullanıyor.
· Agile-Lean diyince akla gelen yegane yaklaşımın Scrum olduğunu düşündükleri için diğer tüm ekipler de Scrum kullanmaya çalışıyor veya kullanmaya itiliyor.
· Ve sonuç olarak ölü doğmuş dönüşümler başlatılıyor.
Bir organizasyonda dönüşüme başlarken öncelikle ihtiyacı iyi analiz etmek, ekiplerin beklentilerini anlamak, çalışma düzenlerini bilmek gerekiyor. Bu konuya https://muhammedsimsek.medium.com/usta-%C3%A7ek-oradan-1-5-scrum-ya%C4%9Fli-olsun-6b728b47fcb9 yazımda değinmiştim.
Ekiplerin çalışma yöntemlerini ve ihtiyaçlarını anlamanın iyi bir yolu olan STATIK (System Thinking Approach to Introduce Kanban ) yaklaşımından faydalanabilirsiniz.
Şahsen ben Non-IT ekiplerle çalışmaya başlarken yukarıdaki yaklaşımdan faydalanıyor ve çoğunlukla Kanban yaklaşımının kullanımını öneriyorum.
Peki neden Kanban öneriyorum?;
· Kanban temel olarak daha az kurala sahiptir.
· Kanban’da yapılması gereken toplantılar gerekliyse ve faydalıysa yapılmalı, gereksizse ve değer katmıyorsa yapılmamalıdır.
· Sprint gibi keskin cycle lar yoktur. Temel olarak akışa iş girer ve çıkar.
· Master, efendi gibi roller yoktur. Gerekliyse ve değerliyse konulur.
· Şu an neredeysen oradan başla yaklaşımı ile bigbang değil zamanla iyileşmeyi önerir.
· En temelde To-do, In Progress ve Done kolonlarından oluşan bir board ile hemen bugün başlanabilir(Kanban Maturity Model Level-1 . Referans için ; https://muhammedsimsek.medium.com/nedir-bu-kanban-maturity-model-kmm-788b474f2911 ).
Peki örnek boardlarla bir iş birimine temelde nasıl bir board hazırlıyorum ve o iş biriminin diğer iş birimleriyle koordinasyonunu ve ölçeklendirmesini nasıl yapıyorum?
Gelin bunu 2 board ile açıklayayım;
1- Team Level Board-Level 1 :
Aşağıdaki board tasarımında göreceğiniz üzere akış soldan sağa doğru akmaktadır.
Boardun elementlerine değinecek olursak;
1. Columns;
a. Backlog; Takımın tüm işleri buraya girilir. Akışın başlangıcıdır.
b. Next; Önceliklendirmenin yapıldığı ve teslim taahhüdünün başlangıç noktasıdır. İşlerin Next kolonuna çekilmesi Replenishment toplantılarıyla yapılacağı gibi, On Demand olarakta yapılabilir ki, en çevik yaklaşım da budur.
c. In Progress; İşin asıl yapıldığı kolondur. Bu kolon çekme sisteminin işlemesi için 2 alt kolona ayrılabilir(Working-Completed gibi).
d. Waiting from Other Teams; Kanban’da en önemli pratiklerden birisi görselleştirmektir. Eğer ekip bir işle uğraşırken başka bir ekipten bir bilgi bekliyor ve kendi akışı kilitlenmiş duruma geliyorsa task bu kolona alınır.
e. Waiting from Other Partners; Eğer ekibin bilgi beklediği kişiler şirket dışından bir partner ise (Örneğin Ajans) task bu kolona alınır.
f. Discarded; Normalde işler akışa girmeden ıskartaya ayrılması gerekiyorsa ayrılmalıdır. Kanban’da soldan sağa gittikçe ıskarta oranı azalmalıdır. Ancak yine de başlanan bir işin bitirlmesi bir anlam ifade etmeyecek duruma geldiyse task bu kolona alınır.
g. Done; Bu kolon işin bittiği kolondur.
2. WIP Limits; Kolonlarda aynı anda kaç iş yapılacağının sınırıdır. Backlog ve Done kolonlarında WIP limit sonsuzken, diğer kolonlarda WIP limiti ekip kapasitesiyle doğru orantılı olarak sınırlandırmak önemlidir. WIP limit arttıkça çıktı sayısı artarken, azaldıkça teslim süresi hızlanır. Genel yaklaşım WIP limitin mümkün olduğunca az tutulmasıdır. Ancak zamanla akışınıza göre WIP limiti artırıp azaltabilirsiniz.
3. Swimlanes; Kanban’da her iş tipi aynı önceliğe sahip olmamalıdır. Canlıdan gelen acil bir hata ile bir ekrandaki kozmetik bir düzenleme aynı önemde olamaz. Dolayısıyla işlerimizi tagler vasıtasıyla swimlanelere bölerek öncelikleri yönetiyoruz. Kolonlardaki WIP limitler swimlaneler bazında bölüştürülmelidir. Yani In progress kolonunda 4 Limit var ise bunun 1 tanesi Acil işlere, 2 tanesi Proje işlerine , 1 tanesi de Diğer işlere bölüştürülebilir. Burada Acil satırının limitini düşük tutmak önemlidir. Yoksa maazallah “her iş acil!” denir 😉
4. Policies; Bu alanda da işlerin ne olursa bir sonraki kolona geçeceğine dair kontroller bulunur. Mesela; Talep dökümanı hazırlandı mı?, Kullanıcı testleri yapıldı mı?
Takım seviyesinde işlerimizi gayet güzel yürütmeye başladık. Peki diğer departmanlarla olan işlerimizi nasıl yürüteceğiz? Diğer bir anlatımla ölçeklemeyi nasıl yapacağız? İşte bunun için Flight Levels yaklaşımını oldukça kolay uygulanabilir bulduğumdan bu yaklaşımla ölçeklemeyi yapıyorum.
Flight Levels temel olarak 3 seviyeli bir ölçeklendirme yapmaktadır. Detaylar için https://www.flightlevels.io/flightlevels/ linkine başvurabilirsiniz.
İşte ben de 2 seviye koordinasyonu buna göre tasarladım.
2- Coordination Board-Level 2 :
Bu board yaygın olarak haftalık bir araya gelen Product Ownerlar, diğer key stakeholderlar ile yürütülür.
Ekipler diğer ekiplerle beraber bu board üzerinde koordine olur, birbirlerinden bekledikleri bilgi veya işler bu board toplantısında konuşulur.
Takımlara dağılacak işler bu boardda konuşulur, gereken önceliklendirme ve onay adımlarından sonra(ki onay adımları israftır gerekmedikçe koymamak gerekir) iş hangi birim tarafından yapılacaksa ilgili birimin Realization kolonuna alınır.
Eğer JIRA gibi bir tool kullanıyorsanız flow tanımlarını yapabilirseniz ilgili birimin Realization kolonuna gelen iş takımın kendi boardunda backlog veya next kolonuna düşebilir. Bu şekilde 2 boardu otomatik olarak işletebilme olanağını yakalarsınız.
Coordination Board’da ilgili birimin realization kolonunda bekleyen iş, Team Boardda done’a gelene kadar o kolonda beklemeye devam eder. Ne zaman Team Board’da takım işini Done kolonuna alır o zaman Coordination Board’da iş Done’a geçer.
Bu 2 seviyeli board tasarımıyla hem ekipleriniz işlerini görselleştirmiş hem de diğer ekiplerle koordine olmuş olur.
Bu tasarımlar ekiplerin olgunluk seviyesine göre geliştirilebilir. Ancak Kanban’ın çok önemli bir prensibi olan “Şu An Neredeysen Oradan Başla” ile hemen kullanmaya başlayabilirsiniz.
