Değişim/Dönüşüm üzerine üç kitap

Buzdağımız Eriyor / Peynirimi Kim Kaptı? / Scrum: Bir Dönüşüm Hikayesi

Buzdağımız Eriyor kitabı Güney Kutbu'nda, bugün Cape Washinton denilen yakın bir yerde yaşayan bir penguen kolonisinin değişim öyküsünü anlatıyor. Buz dağı statüko'yu ve değişime direnen ve asla değişmeyeceği düşünülen [inanılan] tüm şeyleri ve ayrıca taassup ile bağlı olduğumuz tüm değerleri sembolize ediyor. Sizi koruduğunu düşündüğünüz ve size güven hissi veren, sizi rahatlatan, gevşeten, yayan ne varsa sizin kuyunuzu kazıyor olabilir gerçeği ile yüzleşmenizi sağlıyor.

Buz dağımız Eriyor kitabının tam olarak başrol karakteri olmayan bir kitap. Serüveni başlatan karakter Fred, gözlemci ve zeki bir penguen. Yaptığı gözlemleri Buz dağının Liderlik Konseyi adını verdikleri konsey ile paylaşmak istiyor. Zira ortada acil bir durum söz konusu [buz dağı eriyor, daha doğrusu parçalanacak]. Fred Konseyden halka daha yakın olan Alice'e aktarıyor durumu.

Liderlik Konseyi toplantıları kasvetli. Katı bir şekilde yapılan bu toplantı bürokratik yapıyı sergiliyor. Halktan uzak.

Fred buzdan bir model ile durumu teorik olarak anlatıyor. Bu durumun farkındalığını artırıyor. Bir çok penguen'in ikna olmasını da sağlıyor. Konsey'in hoşuna gitmese de Alice herkesin katılacağı bir genel toplantı ayarlayarak ortak akıldan faydalanmak istiyor.

Fred'in cam şişe ile yaptığı deney, teorik olarak anlattığı modelin pratik örneği haline dönüşüyor. Böylelikle herkesin durum ile ilgili fikirleri oturmaya başlıyor. Fred sonuca varmak için aslında Cam şişe deneyinde analitik zekasını konuşturarak risk alıyor.

Sonrasında Akil Penguenler Heyeti [ki bu ismi onlara ben koydum] kuruluyor, Louis,Alice,Fred,Buddy Jordan(ki diğerleri onu Profesör diye çağırıyor.) Değişimi yönetecek ekip. Louis bu ekibin kaynaşmaları ve aynı hedefi gösteren bir takım olmaları için yemeğe çıkarır ve kişisel hayatları ile ilgili merak ettikleri soruları yöneltir. Onun bu yaklaşımı artık bu ekibi tam bir takım haline getirmiştir. [Louis Agile Studio Scrum Master'i :) ]

Louis'in penguenlere attığı nutuk oldukça etkili olur.(sayfa 55). [IT Bilgilendirme toplantısı]

Sonrasında harekete geçmeye karar veriler. Bunun için ilk olarak sloglarını heryere, herkesin görebileceği yerlere asarlar. [Bu iş yerinde Scrum uygulanmaktadır. :) ] Benim için en çarpıcı slogan "Biz buzdağı değiliz."

  Buzdağının yakınlarına gelen bir Martı'yla birlikte görüşmeleri onlar için ilham verici bir deneyimdir ve sonrasında kendi planlarını yaparlar. Martı'nın kendi kabilesinin izcisi olduğunu öğrendiklerinde kendilerininde izci takımı oluşturmaları gerektiğini anlarlar.[ Martıyı bulmak için Fred gibi etrafta dolaşarak gözlem yapmaları gerektiğine karar verirler. ]

Akil Penguenler Heyeti Aksiyon planını hazırlıyor. İzci seçimi seçmek, Yeni buzdağları bulmak, Yolculuklarda izlenecek noktaları tespit etmek ve koloninin lojistik hareket planını yapmak.

Tabi tüm bunlar olup biterken herşey güllük gülistanlık değil. NoNo isminde bir karakter var ki, ortalığın huzurunu kaçırıyor. Tam bir felaket tellalı. Akil Penguenler Heyeti engellerle nasıl uğraşılacağı konusunda tecrübeli olduğu için ortaya çıkan problemleri bertaraf ediyorlar.

Anaokulundaki öğrencilerin bile değişime dahil edilmesi, göz ardı edilmemesi ve ipin ucundan tutmalarının sağlanması değişimin gelişebilmesi için önemli. Bu sebeple en ufak bir etkinin bile dahil edilmesi sağlanıyor. Akil Penguenler Heyeti kahraman olmak için elinden gelenin en iyisini yapmak için çalışmak olduğunu anlatıyor yavru penguenlere. Onlar da artık kendilerini değişimin bir parçası olarak görüyorlar. Tabi bu bazı ebeveynlerin hoşuna gitmiyor. Yavruların [bile!] yetki sahibi olması onlar için görülmemiş bir şey.

İzcilerin dalışı sonrası buldukları bir kısa dönem kazancı yaratıyor. Kitap kısa sürede kazanılan zaferin büyük bir zafer olduğu vurgusunda.

Konsey toplantılarının gereksizliğinden iptal edilmesi,kültürün değişiminin ve değişimin kültürüyle yer değiştirmesinin işaretlerinden.

İzcilerden birinin buz dağına döndüğüne eşiyle yaptığı konuşma kayda değer;

-Joe: Pete uzaktayken buz dağımızı özledin mi? [Penguen kolonisi sanırım çok edepli olduğundan kadınlar direkt eşlerine Beni özledin mi? diye soramıyorlar, bu sebeple Evimiz, yuvamız anlamında buz dağımız kelimesini kullanıyorlar.]
-Pete: Hayır ama seni çok özledim...

Bu replik aslında bir statükonun, maddenin [buz dağının], değerle[sen] yer değiştirmesini çağrıştırıyor.

Ve sonunda plan ilerletiliyor ve keşfedilen yeni buz dağına hareket ediliyor. Değişime alışan bu koloni, yeni gittiği yere de kök salmak yerine değişim hareketini devam ettirip, daha iyi şartlarda başka buz dağları ile göçebe hayatlarına devam ediyorlar.

Peynirimi kim kaptı? kitabını okuduysanız, Buz dağımız eriyor kitabı ile benzer bir başlangıca sahip olduğunu anlarsınız. Bir tarafta peyniri biten fare ve insancıklar, bir tarafta buz dağı eriyen penguenler. Peynirimi kim kaptı kitabında değişime ayak uyduran ve ayak direyen iki kesimi de derinlemesine resmeder; bir yanda ayakkabılarını asla yanlarından ayırmadan boyunlarında taşıyan ve gerektiğinde giyerek hemen yeni peynirler bulmak için iç güdülerine güvenen fareler, bir yanda ise kendi peynir istasyonlarının lezzetine kapılarak, peynirinin bittiğini göz göre göre kabul etmek istemeyen insancıklar.

Scrum: bir dönüşüm hikayesi kitabını okuyanlar için bilir, Hakan aslında Penguen Fred'in rolündedir, değişim ihtiyacını fark eden ve ilk adımı atarak kişisel bir öngörüden büyük bir kurumsal dönüşüme sebep olan. Hakanın yöneticisi Evren, Alice'dir, Hakan'ı dinler ve değişim için gerekli olan ortamın oluşması için çalışır. Akil Penguenler Heyeti olarak kurumsal dönüşümü yöneten Agile Studio kabul edilebilir. Aksiyon planının belirlenmesi, değişimi sürükleyecek kişilerin seçilmesi, değişim kültürünün kalıcı hale getirilmesi, değişimi hep canlı tutmak, kısa dönem kazanları sağlayarak dönüşümün etkisini ve devamlılığına güç katma hepsi Buz dağımız eriyor kitabında sezinlenebiliyor.

Üç farklı kitap ve tek bir konu değişim/dönüşüm.

İyi okumalar...

Scrum Ekipleri ve Hata Kayıtları

Kimse hata olsun istemez ama hayatımızın bir parçası olan hatalar yokmuş gibi plan yapılması da uygulanabilir değil tabi ki. Entegrasyon noktalarının çokluğu veya projenin büyüklüğüne göre geçiş sonralarında öngörülmeyen hatalarla karşılaşmak mümkün.

İdeal olanı hata kayıtlarının oluşmaması evet ama konumuz o değil. Sürekli hataların geldiği, hatta bunlardan bazılarının çok acil olduğu fırtınalı bir ekipte olduğumuzu varsayalım ve bu durumda neler yapılabileceğini şöyle bir düşünelim.

 

Ölçümleme

Ölçme aslında başarılı olmak isteyen herkesin yapması gereken ilk şey. Bunu sadece yönetime rapor sunmak için düşünmemek lazım. Bir kişinin önünü görmeden koşması mümkün olmadığı gibi durumunu takip etmeyen kişide kendini geliştiremez.

Ölçümleme illa çok detaylı olmak zorunda değil, ölçümlemeye aşırı zaman da ayırmamak lazım. Konumuz olan hata kayıtları açısından düşünürsek, yeni gelen ve kapatılan hata sayısını gösteren bir rapor başlarda bize yeterli olacaktır. Bu şekilde hızımızı ve ne zaman dingin sulara ulaşabileceğimizi az çok kestirebiliriz.

 

Çözüm Yolu

Scrum takımı olarak bizden her Sprint sonunda doğal olarak belli bir ilerleme bekleniyor. Nasıl işlerimizi daha küçük ve dikey parçalara ayırıyor ve sprintlerimize yayıyorsak aynı şekilde belirlediğimiz yolda buna benzer olmalı. Birkaç Sprint içime kapanayım sürekli hata çözeyim deme şansımız yok maalesef.

Öncelikle hata çözümü için ek bir iş gücüne ihtiyacımız olduğu kesin. Ama bu gücü nereden bulabiliriz. İlk akla gelen fazla mesai ve iş yerinde sabahlama düşüncelerini de savurduktan sonra düşünmeye devam ediyoruz. Tabi ki fazla mesai yapılabilir hatta yapılmalı ama öncelikle sistemli ve efektif çalışılmalı.

Bazı öneriler aşağıdaki gibi olabilir:

 

1.1.           Kota Ayırma

Hata kayıtları için belirli bir kota ayrılması düşünülebilir. Mesela ideal hour’umuzun %20si gibi. Bu çözüm, yeni gelen hata sayısı az olan ekiplerde daha uygulanabilir gözüküyor. Hatta hata kaydı haricinde Sprint içinde acil iş yapmak zorunda kalan ekipler tarafından da bu yöntem genellikle tercih ediliyor. Hata ve acil iş için belli bir saat ayrıldıktan sonra her gün Daily Scrum sonunda bu kotadan kullanılan kısım düşülür ve mümkün olduğunca kota aşılmamaya çalışılır.

Bu yöntemin başlıca dezavantajı kotanın kullanılmasında yaşanır. Günlük kullanılmayan kısmın başka işlerle doldurulması veya ayrılan kotadan çok daha fazlasının kullanılması gibi riskleri var. Eğer dikkatli uygulanmazsa hata çözümlerine yoğunlaşıp Sprint backlogunda bulunan PBI’ların ortada kalma ihtimali de var.

 

1.2.           Kişi Belirleme

Önceki yöntemde ayrılan saat tüm takım tarafından gerektiği ölçüde kullanılıyordu. Şimdi ise bu ayrılan saate denk gelecek kadar, sadece hatalar ile ilgilenecek kişilerin belirlenmesini ele alacağız. Bu çözüm yönteminde hata ile ilgilenecek kişiler sırf hata kayıtlarıyla ilgilenerek PBI ile ilgilenen kişilerin gönül rahatlığı ile işlerine odaklanabilmesini hedefleniyor. Bu yöntem, yeni hata sayısı yüksek olan ekipler tarafından tercih edilebilir.

Daily Scrum’larda backlogdan iş eritenler kendi tasklarındaki ilerleme ve durumdan bahsederken hata kayıtları ile ilgilenen kişiler çözdükleri hataları ve ilgilenecekleri hatalar hakkında konuşur. Ayrıca yeni bir hata kaydı geldiğinde ilk değerlendirmeyi yine bu kişiler yapar ve ilgilenir.

Bu yöntemin en büyük dezavantajı hata ile ilgilenen kişilerin üzerindeki yükün büyük olması ve mevcut işlerin içinde olmadıkları için uzaklaşıyor olmaları. Bazı durumlarda takımın angaryasını çekiyor gibi de algılanabilir. Her sprintte hata ile ilgilenen kişilerin dönüşümlü olarak değiştirilmesi bu durumun önüne bir nebze geçebilir.

 

1.3.           Hybrid Çözüm

Hata kayıtları gelmeye devam ettiği fakat kontrol altında tutulabilen ekiplerde ilk iki çözümün birleşimi bir çözüm kullanılabilir. Mesela yeni gelen hatalar ve acil işler için ilgilenecek kişi veya kişiler belirlenir ama tüm ekip birinci yöntemdeki gibi hata kotasından gerektiği ölçüde işleri aksatmayacak şekilde kullanır. Eğer acil veya öncelikli bir hata ortaya çıkarsa belirlenen kişi ilk müdahaleyi yapar.

Bu yöntem belki ideale yakın olsa da kuralları net belli olmadığından uygulanabilirliği diğerlerine göre daha düşük. Ayrıca acil bir iş geldiğinde ilgili kişinin elindeki iş aksayacağından güzel bir şekilde iş birliği yapılması gerekiyor.

 

1.4.           İdeal Durum

Olgun bir sisteminiz var ve geçiş sonrasında çok az geri dönüş alıyorsunuz. Bu durumda tabi ki hatalar için ek bir çaba sarf etmiyorsunuz. Herkes size imrenerek bakıyor. Ama tek tük gelen hataların, ortada kalmaması ve birikmemesi önemli. Her gelen hata anında incelenmeli ve planlı bir şekilde çözüm sürecine giriyor olmalı. Diğer ekiplerdeki gibi hatalar için pay bırakmamış olduğunuzdan, kaydın acilliğine göre ekstra bir çaba harcayarak anında çözüm veya ayrı bir iş olarak sonraki sprinte bırakmayı seçebilirsiniz.

 

Sonuç

Burada bahsettiklerim denenmiş örneklerdir. Takım kendine göre en uygun yöntemi seçer ve gerektikçe yönteminde değişiklik yapar. Takımlar ve hatalar değişiklik gösterebildiği gibi elbette şartlarda değişiklik gösterecektir. Scrum takımı şartlara göre yöntemlerini ve yaklaşımlarını değiştirerek en uygun ve etkili şekilde adapte olur.

Takımların kendine uygun yöntemi bulmasında yardımcı olması dileği ile yazımı sonlandırıyorum. Farklı yöntemler ve çözüm önerileriniz hakkında yorumlarda bulunursanız çok sevinirim.

Muhammed Osman Uçar