Doing Agile mi? Being Agile mi ?
Bu yazı 15 yıl + 3 günde hazırlanmıştır. Birçok kişi için gereksiz bilgi içerebilir ancak ilgilisine gerçek hayattan tecrübeler aktarır.
Agile mindset bilinçsiz ellerde hiçbir işe yaramaz.
Günümüzde Çeviklik Ajanları (Scrum Master, Agile Coach, Lean-Kanban Coach vs.) being Agile kavramıyla kafayı bozmuş durumda. Takım olmak, birarada olmak, Agile nedir neden önemlidir, Scrum mı Kanban mı, Takımlarla oyunlar oynamak, 1–1 ler yapmak vs gibi kavramlara o kadar çok takıldılar ki Doing Agile kısmını atlıyorlar.
Yani Organizasyona implemente edilecek Agile pratikler nelerdir, sadece takım seviyesinde değil organizasyon seviyesinde bilgi aktarımı ve şeffaflık nasıl sağlanabilir, verimlilik nasıl artırılabilir, Proje yönetimi metodu ile nasıl birlikte kullanılabilir gibi kavramları uygulayamıyorlar.
Bunun nedeni bu kısmın yoğun tecrübe ve Pratik gerektirmesi de olabilir isteksizlik de olabilir. Ancak ben ilk şıkka oynayacağım. Günümüzde birçok Çeviklik ajanı bu kavramları nasıl implemente edeceğini bilmiyor.Çünkü bunlar scrum guideda, udemyde veya alınan 1–2 günlük eğitimlerde anlatılmıyor. Burada Pratik gerekiyor.
İyi bir Çeviklik Ajanı sağlam bir toolbox a sahip olmalıdır. Bu toolbox içinden istenilen duruma özgü çözümü çıkarabilmelidir.
Bana göre bir organizasyonda çevik yaklaşımları implemente ederken yapılması gereken en önemli adımlardan birisi görselleştirmedir. Çünkü görselleştirmeden sorunlu noktaları, darboğazları gözlemleyemez ve çözüm üretemezsiniz.
Bu yazıda Görselleştirme üzerinde duracağız.
Peki nasıl Görselleştirebiliriz?
Bunun anlatmak için çok faydalandığım JIRA Software toolunu kullanacağım.(Tip: İyi bir Çeviklik ajanı bu veya bunun gibi toolları iyi kullabilmelidir.)
JIRA da iş takibi ve görselleştirme için birkaç araç bulunuyor. Bunlar;
· İş takibinin ve görselleştirmenin yapıldığı Boardlar
· Anlık durumu gösteren Dashboardlar
· Ve isteğe bağlı Raporlar
Sırayla gidecek olursak iyi bir JIRA Board nasıl hazırlanır?
Boardlar yani tahtalar bilindği üzere kanban(Toyota Production System) dan gelmektedir. Burada işler soldan sağa doğru akar, sağdan sola değil. Yani üretim hattını düşünürseniz hammaddeden nihai ürüne yolculuk tahtaya baktığınızda soldan sağa şeklindedir.
Öncelikle değer üreten bir board yaratmak için STATIK (System Thinking Approach to Introduce Kanban) yaklaşımını kullanmanızı öneririm.
STATIK Yaklaşımında özetle şu şekilde ilerleyebilirsiniz;
1-Gelen iş tiplerinin şu şekilde analizini yapmalısınız;
a. Nelerdir?
b. Ne sıklıklar gelir?
c. Nereden gelir?
d. Talebi açan kişi ne zaman ve ne aciliyette kapanmasını ister?
2-Talep tipine göre iş akışının oluşturulması; Farklılaşan her talep için ayrı iş akışları tanımlanmalıdır. Yani örneğin Story tipinde iş test adımından geçerken, Yetki tipindeki iş test adımına uğramadan başka biro nay adımından geçer. Dolayısıyla Story ile Yetki iş tiplerinin ayrı akışları olmalıdır.
Öneri 1: İş akışını oluştururken klasik to do- in progress-done akışından ziyade olabildiğince detaylı bir şekilde akışı oluşturmak görselleştirmenin artması anlamına gelir ve şeffaflığı artırır.
Öneri 2: Akışları oluştururken Domain Story Telling yöntemini kullanabilirsiniz. Bunu kullanırken de Value Stream Mapping tekniği ile israf noktalarını ortadan kaldırarak (yani gereksiz onay veya bekleme adımlarını) akışı tasarlamanız tavsiye olunur.
Örneğin Raporlama tipindeki bir iş için akış oluşturalım;
Boardun JIRA daki tasarımı şu şekidle;
3- STATIK yaklaşımındaki 3. Adım ise Class of Service (Servis Sınıfları) tanımlarının ve kurallarının yapılması olacaktır. Class of Service yapısın niye kullanıyoruz? Bunun için otoyoldaki ambulansları düşünün. Otoyol tıkalıyken ambulans tıkalı trafiğe girip sıkışıp kalamaz. Ona yol açılması lazım veya emniyet şeridini kullanması lazım. Ancak emniyet şeridi sadece acil durumlarda kullanılmazsa orasının da normal şeritten farkı kalmaz ve acil durumlara cevap verilemez. İşte bunun için gelen işlerde Acil, Yüksek Öncelikli, Orta Öncelikli gibi sınıflandırmalar yapılabilir. Burada ayrım yaparken dikkate alınacak en önemli kriter Cost of Delay kavramıdır. Yani; gelen o talebin yapılması gecikirse bize neye mal olur. Mesela bir bankanın IT departmanında çalışıyorsunuz ve müşteriler atm den para çekemiyor. İşte bu iş ambulans misali Acil öncelikli iş olarak boarda girer ve diğer işleri bekletir. Öncelikle bu işin çözülmesi lazım. Ne zaman bu acil iş çözülür ondan sonra diğer tasklara geçilir.
Class Of Service ler JIRA da swimlaneler ile yönetilir. Bu swimlanelerin kuralları olmalı ve işler o kurallara göre swimlanelere bölünmeli. Mesela aşağıda 2 ana durum var; Çok acil olan işler ve yüksek öncelikli işler.
Bu swimlanelere işler sorgular ile gelebildiği gibi aşağıdaki bölümlendirmeler ile de gelebilir;
Not: Swimlane bölümlendirmede priority/severity kullanacaksanız burada anlaşmaya varın ve örneğin Acil sınıfındaki iş sayısını 1–2 ile sınırlandırın ve kuralları net olsun. Aksi takdirde tüm işler buraya girer ve board anlamını yitirir. Örneğin; Canlıda müşteriyi etkileyen bir durum veya CEO dan gelen bir talep veya bir regülasyon talebi.
İşleri sınırlandırma demişken en önemli konulardan biri de WIP (Work In Progress) Limit tir. Yani aynı anda yapacağımız iş sayısını sınırlandırmamız gerekir. Burada WIP limitler maximum ve minimum konulabilir. Yani bir kolonda minimum şu kadar iş olmalı veya bir kolonda maximum şu kadar iş olmalı.
Tecrübeden gelen not: Backlog dediğimiz işlerin ilk geldiği kolona WIP limit koymayın. Müşteri orayı istediği gibi doldurabilir. Bir sonraki kolon olan Next kolonuna minimum limit koyun ki Product Owner veya Service Managerınız burada minimum şu kadar iş bulundursun ki takım boşta kalmasın.In Progress kolonlarınıza maximum limit koyun. Buradaki maximum limiti belirlerken başlangıçta ekip üyesi sayısı kadar koyabilirsiniz. Yani 10 kişi geliştirme yapıyorsa 10 ile sınırlayabilirsiniz. İlerleyen zamanlarda bu limiti deneyiminize göre artırıp azaltabilirsiniz. Ancak azaltıp artırırken bazı sonuçları Kabul etmelisiniz.
WIP Limit artarsa ürettiğiniz iş sayısı artar ancak hızınız düşer. WIP limiti azaltırsanız çıktı sayınız azalır ancak daha hızlı teslimat yapabilirsiniz. Bunu bir su hortumu gibi düşünün; Hortumun ucunu sıkarsanız su daha tazyikli akar ancak daha az miktar su geçer. Ucunu sıkmazsanız daha çok su geçer ancak daha yavaş akar.
JIRA da WIP limitleri kolonların üzerinde max veya min ifadeleri ile görebilirsiniz. Aşağıdaki görselde max limit aşıldığı için ilgili kolonun kızardığını görebilirsiniz. Buna izin vermemelisiniz.
Not: İşlere WIP limit koymak önemli bir kültürel değişimi gerektirir. Genelde işi yapacak olan birimler kaynaklarının sınırlı olduğunu diğer birimlere göstermek istemez. Burada değişim yönetimi yaklaşımlarını kullanmanızı öneririm. Çünkü burada kimi zaman güçlü sponsor -yönetim desteğini arkanıza alıp ilerlenebilir veya aşamalı olgunlaşma ile önce WIP limitsiz ilerlenip birimler buna alıştığında ileride WIP limit konulabilir. Ancak her iki durumda da WIP limit koymanın önemini hem işi yapacka birime hem de o birimin müşterisine anlatmak ve benimsetmek gerekir.
Peki JIRA da board u nasıl yaratırız?;
1- Projenize girdikten sonra sol panelde bulunan Create Board a tıklayın.
Scrum Board mu Kanban board mu yapacağınıza karar verin; Eğer işlerinizi sprintler ile yönetecekseniz Scrum Board u, Sprintler bizi bozar daha esnek olalım ve WIP limit koyalım derseniz Kanban Board u tercih edin. Tavsiyem ilk etapta Kanban Board ile gitmenizdir.
Boardu yaratırken boarda gelecek datanın nereden geleceğine karar verin; Benim tavsiyem Filtre yaratıp oradan ilerlemeniz olacaktır. Çünkü filtreler daha esnektir. Birden fazla projeden data çekip ilerleyebilirsiniz.
Filtre yaratmak için aşağıdaki alandan ilerleyin;
Filtreyi kaydettikten sonra details alanından izinlerini ayarlamayı unutmayın yoksa boarda işler gelmez ;
Boardu yarattıktan sonra Board Settings den ayarlarını yapın
2- Öncelikle Kolonları ayarlayın. Default olarak To Do , In Progress ve Done gelir. Tavsiyem burayı olabildiğince çeşitlendirin.
a. Commitment Pointinizi belirleyin ve Bir Next Kolonu koyun. Sizden iş talep edecek iş birimi ile işler To Do ya geldiğinde değil To Do dan sonra nexte çekildiğinde bizim için Lead Time başlar şeklinde anlaşma yapın. Aksi takdirde iş birimi sizin boardunuza iş yarattığı andan itibaren taksimetreyi çalıştırmaya başlar ve sonra bizim taleplerimiz neden bu kadar gecikiyor derler.
b. Kolonları ayarlamak için iş akışınızın kolonlara uyması gerekir. Yani iş akışınızda Next diye bir adım yoksa boardda kolon açsanız da buraya uğramayabilir.
c. Kolonlara statüleri mapleyin. Yani hangi statü hangi kolon ile ilişkilidir. Not: İlişkilendirmediğiniz statüler Unmapped status altında gösterilir ve bu statüdeki işler boardunuzda gözükmez.
In Progress kolonuna max WIP limit koymanızı tavsiye ederim.
3-Görselliği artırmak için Quick Filters lar belirleyin.
Mesela;
4-Görselliği artırmak için Card Colors u kullanın ; Burada neye göre kartları nasıl renklendirebilirsiniz seçeneği vardır.
Mesela Önceliğe göre renklendirmek ;
5-Card Layouttan Boardda kartların üzerinde detaya girmeden neler gözüksün bunları seçin ki bir bakışta ne olduğu anlaşılabilsin. Mesela; iş kimde ve end date’i nedir dersek;
Görselleştirmenin bir sonraki boyutu Dashboardlar. O da bir sonraki yazının konusu olsun.
To be continued …
