Çıkarımlar : Bu yazıda ürün yerleştirme kullanılmıştır.

Scrum’i profesyonel olarak uygulamaya başladıktan sonra scrum ile ilgili kavramları hayatımın her köşesinde görür olmaya başladım.

Ataletten kurtulma ve kilo problemini aşmak için sahilde koşmaya başlamıştım. İlk başlarda hiç bir şey ölçümlemiyordum. Sonra bunun bir ihtiyaç olduğu farketmeye başladım. Gelişip gelişmediğim anlamanın tek yolu ölçümlemekti. Runkeeper programını cep telefonuma yükledim ve koşuya her gittiğimde kayıt etmeye başladım. Büyükada, Bostancı, Pendik, Belgrad ormanı vs. bir çok yerde kaydettim. Bu koşular sırasında bazı çıkarımlarım oldu. Şöyleki; 

Çıkarım 1- Yol değişirse, hızını mukayese etmenin bir anlamı kalmaz. 

Bunun scrum’daki karşılığı takımın velocity’si takımın işine bağlı olarak değişir. Takımdaki kişiler ve sprint uzunluğu değişirse velocity’yi karşılaştırmak anlamlı değildir. Onun üzerinden bir çıkarımda bulunulamaz 

Çıkarım 2- Herzaman odaklanılacak iyi bir taraf vardır. 

Runkeeper programı her koşumda o koşuya has iyi yaptığım birşey varsa onu söyleyerek beni motive ediyor. Örneğin en iyi hızını yaptın, en uzun koşunu gerçekleştirdin, yada 1-3 km arası en iyi hızını koştun, en yüksek eğimini tırmandın vs. Retrospective’lere başladğımızda genelde takım iyiye odaklanma konusunda sorun yaşıyor. Bu anlamda Runkeeper örnek alınabilir. 

Çıkarım 3- Önemli olan sürdürülebilir bir hız yakalayabilmektir. 

Bir kaç koşu sonrası artık ortalama ne kadar sürede koştuğumu biliyorum. [Ve bu sürenin bağlı olduğu değişkenleri keşfettim.] Bazen yanımda arkadaşlarla koşarken onların hızına aldanıp hızlı gittiğim bir iki kilometre oluyor, sonrasında kendimi zorladığım için geri kalan kısımda kendi ortalamamın oldukça aşağısına düşüyorum. 

Scrumda takım kendi sürdürülebilir hızını bulmalıdır.  Ve Kaizen gereği bunu artırmak için çabalamalıdır. HyperProductive takımlar ancak bu şekilde oluşturulabilirler. 

Son olarak Scrum takımı deyince aklıma kürek takımı geliyor. Arkada nereye gidileceğini belirleyen ve dümeni elinde tutan Product Owner, Önde takımı motive eden ve takımın fonksiyonelitesini ve verimliliğini sağlayan Scrum Master ve Ortada hedefe ulaşmak için var gücüyle çalışan Development Team.

Scrumofobi

        Yazılım geliştirme insanının scruma dönüşme korkusudur. Bu fobi yazılım geliştirme insanının gündelik iş hayatını etkiler. Scrumofobi'nin kök nedeni olarak değişime karşı duyulan korku ve direnç gösterilebilir. Yazılım geliştirme insanı ünvandan bağımsız olmakla birlikte bu modeli bir güç kaybı olarak değerlendirebilir. Kendi içinde oluşturduğu bu ön yargı, onu scrum'ın çerçevesini tam anlayamamasına sebep olur. 

         

         Daha çok proje yöneticisi, yazılım-analiz takım lideri gibi ünvanlarında çalışan kişilerde görülebilir. Bu kişiler geleneksel takım modelinden, çevik takım modeline geçmeyi yadsırlar ve bu onların adaptasyonlarını zorlaştırır. Eski modelde yetkin bir yönetici ve altında ona bağlı çalışanlar varken, Scrumda tüm takımın yetkinliğin artmasını sağlayan ve insiyatif almalarına olanak veren bir yapı vardır. Scrum daki bu takım yapısı taahhüt kavramınında tüm ekipçe paylaşılmasını sağlar ve sorumlu olarak geleneksel modelde olduğu gibi kişileri değil tüm takımı muhatap alır. Bu takıma güvenmeyi sağladığı için takımın kendine olan güvenin ve dolayısıyla üretilen işin kalitesinin artmasına sebep olur. Geleneksel takımla yönetilen işlerde muhatap hiyerarşik olarak tepede olan kişidedir, sorumlu odur ve bu takımda iş sahiplenişi azaltabilir. 

         

        Scrumofobik kişilerin bir diğer özelliğide şeffaflığa açık olmayışlarıdır. Kendi takımlarını korumak adına onlara sormadan karar verme yetkileri vardır. Kendilerinde olmayan şeffaflığın diğer ekiplerde de olmadığına inandıkları için sürekli defans halindedirler. 

         

        Bu kişiler bu şeffaflık aylayışlarından dolayı workaround'lara, by-pass çözümlere bayılırlar, kendi çarklarını döndürebildikleri müddetçe onlar için ortada bir sorun yoktur. Sistemin kendilerine by-pass çözüm üretebilecekleri bir açığını bulduklarında bundan kimseye bahsetmeden kullanmaya devam ederler. Kalıcı çözümler, Kaizen kültürü onlar için maliyetli şeylerdir. Ve genellikle o topa hiç girmeyelimcidirler. 

          

         Scrumofobik insanlar proje yöneticisi, takım lideri vb. pozisyonlarda olabileceği gibi, takım içerisinde hiyerarşiden beslenen ve ondan hesap sorulabilecek bir pozisyonda olmadığı sürece rahatsız olmayan yazılımcı/analist/testçi gibi pozisyonlarda da ortaya çıkar. Üstten gelsinci, gelmeden yapmamcı, yaparken banamı sorduncu bu tipler, sorumluluk ve insiyatif kelimesi ile kendilerini en uzak noktada konumlandırırlar. Bu kişiler Daily Scrum'ları bile kendi işlerinden hesap sorulduğu bir ortam olarak algılayabilirler. 

          Genel olarak değişime, şeffaflığa, deneyselliğe yani scrum'ın özüne uzak yazılım geliştirme insanının scrum dönüşümüne gösterdiği korkudur.

C'Lean development

[Aim of the book]:

In this book, we hope to chane the software paradigm 

from process to people, 

from disaggregation to aggregation,

from speculation to data-based decision making,

from planning to learning

from traceability to testing

from cost-and-schedule to deliver business value.

if you think that better, cheaper and faster can’t coexist, you should know that we used to think the same way in the pre-lean days of manufacturing and product development. However, we learned that by focusing on value, flow and people, you got better quality, lower cost and faster delivery. 

[p:xviii] 

[For whom is this book] 

software development managers, project managers and technical leaders.

[Introduction]

The story of Florida and Minesota.[p:xxi]

Differences between companies are rooted in their organisational history and culture, their approach to the market and their ability to capitalise on opportunities. [p:xxi]

The story of General Motor GM-10 and Honda [p:xxii]

[Outline] [p:xxv]

1.Eliminate Waste

2.Amplify Learning

3.Decide as late as possible

4.Deliver as fast as possible 

5.Empower the team

6.Build integrity in

7.See the whole

[2.Amplify Learning] 

Development is an exercise in discovery, while production is exercise in reducing variation.

and for this reason, a lean approach to development results in practices that are quite than lean production practices. 

Development is like creating a recipe, production is like making the dish. 

[p:xxvi] 

Örnek Alınacak Scrum Master

Scrum eğitimi ve sonrasında hizmetkâr liderlik (servant-leadership) kelimesini birçok kez duyduk. Peki, Scrum Master denildiği zaman aklımıza ilk gelen hizmetkâr liderlik ne demek ve neleri gerektirir? Bu konu üzerindeki düşüncelerimi ve elde ettiğim bazı bilgileri paylaşmak istiyorum. Yazımda hizmetkâr liderliğin temel taşlarından biri olan örnek bir insan olma üzerinde duracağım.
 

Öncelikle üzerinde düşündüğümüz hizmetkâr liderlik, 1970 yılında Robert K. Greenleaf tarafından tanımlanan hizmetkâr liderlik tanımından çok daha öncesinden gelen ve geçerliliğini yitirmemiş bir liderlik şeklidir. İslamiyet ve diğer dinler bu tür liderliği çok daha öncesinden benimsemiş ve uygulamıştır.
 

Peygamberimizin (SAV) “Bir milletin efendisi, ona hizmet edendir.” (Aclûnî, Keşfü'l-Hafâ, 2:463) hadisi ve kendisinin yönetim şekli bize bu manada fazlasıyla örnek oluyor. Buradaki düşüncelerin bir kısmını zaten biliyor ve uyguluyor olsam da çoğunun farkına İdris Tüzün’ün kaleme aldığı “Hizmetkâr Liderlik Modeli” adlı kitabını okuduktan sonra vardım. Okunmasını şiddetle tavsiye ediyorum.
 

Örnek Bir İnsan Olmak

 

Liderlik öncelikle yaşantısı ve davranışlarıyla örnek bir insan olmakla başlar. İnsanlar münasebet içinde olduğu kişilerden etkilenir. Etrafında iyi kişiler olan kişinin zamanlar iyileşmesi ve kötü kişilerle takılanların zamanla kötü adetler edinmesi herkes tarafından bilinen bir gerçektir. Liderlerin ve idarecilerin insanlar üzerinde çok daha fazla etkisi vardır. İnsanlar genellikle liderlerini örnek alırlar. Bir lider olarak takımımızdaki kişilerin nasıl olmasını istiyorsak bizde öyle olmalıyız. Eğer lider iyiyse, etrafındakilerde iyi olur. Eğer cesursa etrafındakilerde cesur, korkaksa korkak olur. Eğer Scrum’ı benimser ve uygulama gayreti içinde olursa takımı da ona uyar, gevşeklik veya umursamazlık içindeyse takımı Scrum’dan daha fazla uzaklaşır.

İnsan eğer söylediklerini kendisi yaşamıyorsa dediklerinin hiçbir tesiri olmayacaktır. Hatta dediklerini tam manasıyla yaşayan bir kişinin örnek davranışı başka söze hacet bırakmaz. Kendisi sigara içtiği halde çocuklara sigaranın zararlarından bahseden bir kişinin ne kadar boş konuşmuş olduğunu ve dediklerini karşısındakilerin hiç kale almayacağını hepimiz tahmin edebiliyoruz. Scrum, karmaşık olan yazılım geliştirme süreci için biçilmiş kaftan diyen fakat Scrum’ın kaideleri konusunda gevşeklik gösteren ve kendini geliştirme çabası içinde olmayan bir Scrum Master’ın sözleri de aynı şekilde etkisiz olacaktır.
 

Ayrıca yanlış örnek olmamak için doğruyu biliyor ve bildiklerimizi de arttırıyor olmalıyız. Bilindiği gibi Scrum kendisi basit ama uzmanlaşması zor bir konu. Scrum Master Gelişim Programı bizim için hazırlanmış şahane bir yol haritası. Öncelikle programı takip etmeli, öğrendiğimiz konuları takımımız ve arkadaşlarımızla paylaşmalı ve çalışma hayatımıza uyguluyor olmalıyız. Daha sonra da öğrenmeye hevesli ve açık olmalı, bu konuda yazılmış kitap, yayın ve konferansları takip ediyor olmalıyız.
 

Son olarak Kur’an da buyurulan “Siz insanlara iyiliği emreder de kendinizi unutur musunuz?” (Bakara 44) ayetiyle yazımı sonlandırmak istiyorum. Yorumlarınızı ve eklemek istediğiniz değerli düşüncelerinizi bekliyorum.

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

Homo scrumus : yazılım insanının evrilmiş hali

Homo scrumus, klasik yazılım geliştirme süreçlerinde yazılım geliştirdikten sonra, agile yaklaşımlara kendini adapte etmiş, scrum framework'unu tüm terminolojisi ile kullanan, scrum değerlerine ve faydasına inanan yazılım geliştirme insanıdır.

Homo scrumus, odak insanıdır. Çalışmalarını odak çercevesinde tutmaya özen gösterir. Kendini odaktan uzaktan uzaklaştıracak her tür engel konusunda etrafındakileri uyarma eğilimi taşır.

Homo scrumus, deneysel süreç kontrolünün üç temelinden biri olan şeffaflığa sıkı sıkıya bağlıdır. Bu sebeple açıktır. Çalışmalarının her aşamasında çalışma arkadaşlarına karşı açık davranır. Onun gizlemek, saklamak ve ertelemek ile işi olmaz. O mevcut durum içerisindeki durumu açık bir şekilde ifade eder, gelecekte karşılaşılabilecek durumlar hakkında öngörülerini paylaşmaktan çekinmez. Bu açıdan Homo scrumus çekingen bir insan değildir.

Homo scrumus taahhüt insanıdır. O taahhüt eder ve çalışma arkadaşlarından da taahhüt bekler. Homo scrumus'un taahütü sadece sonuç ile ilgili değildir. Sadece çalışan bir yazılım'a tahhüt etmez, aynı zamanda scrum değerlerini sahipleneceğine, kendinden organize olmaya, gelişime, agile prensiplerine, şeffaflığa taahhüt eder.

Homo scrumus saygılıdır. Saygı duyar, saygı besler. Üretim aşamasının her safhasında ürüne değer katmak için atılmış her adıma saygıyla yaklaşır. Farklı kişilikler ve deneyimler ondaki saygıyı besleyen unsulardır.

Homo scrumus cesurdur. Statuko'ya karşı değişim adımlarını atabilmesi için cesur olmaya evrilmiştir. Hatalarını ve kimsenin hatasız olmayacağını kabul etmek için bu cesarete sahiptir. Ortamda şeffaflığı hakim kılmak için cesaretini kullanır.  

http://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/
https://www.scrumalliance.org/why-scrum/core-scrum-values-roles
http://barryhawkins.com/blog/empirical-process-control-why-scrum-works/ 

Sprint Planning : Not defterimden notlar.

Scrumda her döngü Sprint Planning toplantısı ile başlar. Bu toplantı Product Owner ve Geliştirme takımının Sprint için hangi işleri alacağına karar verdiği toplantıdır. Dört saatlik bu toplantı Product Owner ve Geliştirme Takımı arasında geçer.[1,2] İki kısımdan oluşan Sprint Planning'in ilk kısmında What?(Ne) sorusuna cevap aranır. Bu bölümde

• Grooming yapılır;
• Sizing
• Business analiz
• PBI'ların dikey olarak daha küçük PBI'lara bölünmesi 
• PBI'ların resize edilmesi 
• Sprinte alınacak PBI'ların seçimi
• Sprint Goal'un belirlenmesi 

konuşulur, kararlaştırılır. Sprint Planning, Grooming'ten ayıran Sprint için PBI'ların seçilmesi ve Sprint Goal'un oluşturulmasıdır. Sprint Planning toplantısının verimli geçmesini sağlayacak önemli bir etken, Sprint'in %10-15 lik kısmında Grooming toplantısını yapmak olacaktır. Grooming toplantısında asıl amaç Scrum takımının önündeki üç dört Sprint'lik PBI'ların size'landırılarak belirsizliklerin giderilmesi ve Sprint Planing toplantısında daha olgun bir Product Backlog ile çalışılmasının sağlanmasıdır. Groom edilmiş bir Product Backlog takımın işini kolaylaştıracak ve Sprint Planing'i hızlandıracaktır. 

Grooming noktasında Scrum Master'in aktif rol alarak Product Owner'ı toplantı yapmaya yönlendirmesini sağlamalıdır.

Sprint Planing toplantısının ikinci yarısı How?(Nasıl) sorusuna cevap arandığı kısımdır. Bu kısım kağıt kalem toplantısıdır.[3] Takımın PBI'ları nasıl detaylandırılacağının görüşüldüğü bu kısımın çıktıları; 

• Teknik analiz
• Tasarım 
• Plan
• Veri tabanı tasarımı 

olmalıdır. Bu çıktılarla doğrudan geliştirme aşamasına geçilebilir, detaylı bir analiz, teknik tasarım dokümanı beklenilmeyebilir. Bu kısımda yapılan yanlışlardan bir tanesi de tasklara verilen zamanlar ile PBI'lara atanan size'lar arasında lineer bir ilişki aranmasıdır. Takımın taahhüt ettiği Product Backlog'tur. Bu açıdan Sprint Backlog takıma özeldir ve kimseyi ilgilendirmez. Takım taahhütlerine ve Sprint Goal'e odaklanmalıdır. Asıl yakalanması gereken sürdürülebilir bir hızdır (sustainable pace) ve bu artırmaya çalışılmalıdır. 

[1] http://scrummethodology.com/scrum-meetings/

[2] http://en.wikipedia.org/wiki/Scrum_(software_development)
[3] Ahmet Akdağ, ACM 

Scrum: bir dönüşüm romanı

[Scrum: bir dönüşüm hikayesi roman olsaydı diye düşününce girizgah olarak aklıma bunlar geldi...]

Hava açık olsa da gecenin mat siyahı sokak lambalarının ışıklarıyla delik deşik olmuştu. Bu saatte Hakan'a kösele ayakkabısının hicaz makamında çıkardığı seslerle, sokak köpeklerinin solukları eşlik ediyordu. Bir an duraksadı. Bir sokak lambasının altında duruyordu. Ayaklarının altında kalan gölgesinin dalgalanışının fazla mesai sonrası yorulan gözlerinin bir oyunu mu olduğu yoksa sokak lambasının bozukluğundan mı kaynaklandığı kısa bir an zihnini yokladı. Bu saatte kendisini bekleyen eşine ve kızına gitmek yerine, hala açık olduğunu umduğu kahve dükkanına uğrayacaktı. Kendisine sert bir kahve ısmarlayıp, kızı Melis için kakao drajelerinden eşine föndü için kuvertür alacaktı. Çok yorulduğunda içine derin bir nefes çekmek gibi, içinde sıkışıp kaldığı kısır döngüye kısa bir mola vermek istiyordu.

Dükkana girdiğinde eşinin mesajını gördü, Melisin uyuduğunu eve geldiğinde zile basmaması gerektiğini yazıyordu. Hakanın evde olamayışı eşini ve Melisi de değiştirmişti. Ricaların yerini emir kiplerine bıraktığı bir dönem geçiriyorlardı. Tükenmişlik hissinin en acıtan tarafı da buydu belki de. Hayatında her zaman zorluklar olmuştu. Üniversite sonrası girdiği iş ortamı umduğunun aksine gayri samimi ve iki yüzlüydü. Kendi statülerini sağlama almak için elindeki topu sürekli başkalarına atan, taşın altına elini sokmak için sürekli üstlerinden emir rica bekleyen, bu tarz konularda asla kendi insifiyatiflerin kullanmak istemeyen bir sürü insan yığınıyla muhatap olmuştu. Yazılım geliştirme uzmanı olarak başladığı ve proje yöneticisi olarak devam ettiği iş hayatında profesyonelliğini koruyarak hiç bir işi kişiselleştirmeden yönlendirmiş ve gereken özveriyi ve hatta fazlasını göstermişti. Ama artık yavaş yavaş yorulduğunu hissetmeye başlıyordu.

Dükkandaki kesif kahve kokusunun etkisiyle yorgunlunun yerini sabahları saatin alarmına gerek kalmadan kendiliğinden uyandığı zamanlardaki gibi tuhaf bir uyanıklık hali alıyordu. Bu kahve dükkanını Hakan için özel kılan ona çocukluğunu hatırlatıyor olmasıydı. Her zaman karşısındaki koltuklara oturmayı tercih ettiği büyük duvar saati de onun buraya gelmesinin en büyük sebeplerindendi. Rahmetli dedesinin marangozhanesinde aynısında vardı. Hakan için çocukluğunun en canlı hatıraları bu marangozhanede olanlardı. Dedesinin her gün sabahın en erken saatinde marangozhaneyi açışı, birlikte çalıştıkları kalfa ve çırakla diyalogları, onları yetiştirirken gösterdiği özen ve hoşgörü, esnaf ve müşterileri ile olan muhabbeti Hakan'ın iş yaşamına da yön veren anılarıydı. Dedesi her sabah işe başlamadan o gün nelerin yapılacağını istişare eder, kalfa yada çırakların işler ile ilgili değerlendirmelerini alır, önemli yada önemsiz tüm detayları itina ile dinler, o gün için önlerinde bir sorun var mı sorarak emin olurdu. Müşterilerine asla yetiştiremeyeceği bir iş için söz vermezdi. Çalışanlarını asla fazla mesaiye bırakmaz, herkesle işe aynı vakitte başlar ve herkes ile birlikte bitirirdi. Bu marangozhaneye dışarıdan bakan biri usta ile çırağı ayırt etmekte zorlanırdı. Zarar edecek dahi olsa çıraklarının eğitimi adına onların hata yapmasına izin verir, hata yapmaktan korkmayan kişilerle çalışmak isterdi. Oluşturduğu bu ortam bir çoklarının ücret bile talep etmeden çocuklarını Hakan'ın dedesinin yanına çırak olarak göndermesini sağlamıştı. Marangozhanenin üç temel dayanağı dürüst, çalışkan ve sorumluluk sahibi olmaktı.

Hakan saatinde ilerlemesi ile iyice ıssızlaşan mekanda bir başına kahvesini yudumlarken bir yandan da marangozhanedeki anılarına dalmıştı. Duvar saatinin tıklamalarının oluşturduğu sabit melodi Hakanın en büyük terapisti oluyordu. Bu kadar yoğun çalışmasına rağmen hala işlerin istediği hızla gitmemesi, fazla mesailer yüzünden etkilenen sosyal yaşamı ve aile hayatı artık bir şeyleri değiştirmesi gerektiğini fısıldıyordu. Para transfer sistemlerinin dönüşümü ile ilgili yürüttüğü bir projede çok fazla mesai yapması gerekmişti. Evden ne kadar uzak kaldığını anlamasını kızı Melis sağlamıştı. Melis yeni yeni konuşmaya başlamıştı. Annesi ona anne, baba gibi kelimeleleri öğretmişti, aile bireylerini tanıyor ve onlara doğru şekilde hitap edebiliyordu. Tanımadığı kişiler içinse abi, abla, teyze, amca gibi kelimeleri kullanıyordu. Bir akşam Hakan işten döndüğünde Melis ona abi diye seslendi, Hakan Melisin onu karıştırdığını zannetmişti ama bir kaç kez daha aynı şekilde hitap etmesiyle durumu anlamıştı. Sabahın erken vaktinde uyanıp çoğu zaman Melis uyandıktan sonra eve geliyor olması artık onun için bir rutin olmuştu. Böyle bir tempoda kendi kızının onu unutması normaldi. Sonraki günlerde artık mesaiye kalmayacağını belirttiğinde iş arkadaşlarının hoşnutsuz tavrıyla karşılaşsa da ailesiyle vakit geçirmek onun için hayati bir görev olmuştu. Melisin yemeğini yedirmek, üstünü değiştirmek, parka götürmek gibi rutin işlerini artık kendisi devralmıştı. Baba demesini sağlayana kadar bu görevleri kendisi yapmıştı. Sonra mesailerine istemese de devam edebilirdi.

Hareketsizliğin ve yoğun çalışma temposunun emarelerini öyle uzakta aramaya gerek yoktu. Hakanın son zamanlarda aldığı kilolar en trajik belirtisiydi. Hakan artık sıklıkla göbeğini çevreleyen yağ simidini eliyle kavrayarak ne kadar kilo aldığını anlamaya çalışıyordu. Projelerin zorluğuyla birlikte kilolarıda paralel olarak artıyordu. Her akşam söylenen pizzalar içilen kolalar Hakan'ı aslında yaşamak istediği hayattan uzaklaştırıyordu. Üzerine yapışan bu atalet ona öğrendiği fizik kurallarını hatırlatıyordu. Aynı kuvvetle ağır nesneler daha az bir ivme ile haraket ettirebilir. Hakan her sabah ayakkabılarını iliklemesi gerektiğinde göbeğinin ona engel olmasıyla birlikte koşuya başlamaya karar veriyordu. Sadece karar vermekle geçen zamanının özgüveni ve kendi yaşam kalitesi üzerinde ki olumsuz etkisi giderek büyüyordu. Hakan yine göbeğindeki yağ öbeğini tutmuş ve içinden onunla konuşuyordu. Ona bir isimde vermişti, Göbek Can. 'Artık seninle yollarımızı ayıracağız Can' diye geçirdi içinden pek inanmasada. Hakan, Can'ın ağaçların gövdesindeki yaş halkaları gibi halkaları olduğuna inanıyordu, her bir proje için eklenmiş yeni halkalar.

Hakan değişime inanıyordu ama değişim için yeterince motivasyonu olmadığını düşünüyordu. En azından geldiği bu noktada sahip olduğu değerlerle kendi kurumu için vazgeçilmez bir noktada olsa bile yinede kendisi ve çalıştığı kurum için birşeyleri değiştirmeliydi. Kendi hayat serüveninde geriye baktığında yapmak isteyip yapamadığı birşeylerin olmasının onu üzeceğini biliyordu. Bu sabit gidişatın sürdürülebilir olmadığını,  ailesi, arkadaşları ve işi adına harekete geçmesi gerektiğine inanıyordu. Zira Peynirimi Kim Kaptı kitabında bahsedilen değişimi unutan ve değişime direnç gösteren zavallı insancıklardan olmak istemiyordu. Yazılım dünyasını dedesinin marangozhanesine çevirmenin bir yolu vardı aslında, Scrum. İş hayatının kendi hayatının büyük bir kısmını aldığını bildiği için, değişime oradan başlamalıydı. Yeni öğrenmeye başladığı karışık projeleri yönetiminde kullanılan bu çatı tek nokta üzerinden yönetilen ve yönlendirilen tüm süreci tabana yayarak onların da bilgi, birikim ve deneyimlerinden faydalanarak, şeffaflık, denetleme ve uyarlama temelinde sürecin ilerleyişini hızlandırdığı gibi gereksiz zaman ve maliyet kayıplarını en aza indiriyordu.

Kahvesinin son yudumlarında daldığı düşünce denizinden yavaş yavaş çıkıyordu. Kahvesi iyice soğumuştu. Hakan kararını verdi. Artık kendisi adına değişim için elinden geleni yapacaktı. İkna edilmesi gereken herkesi ikna etmek, sorumluluk ve insifiyatifi almak, değişim için ne yapılması gerekiyorsa kendi payına düşeni yapmak ve geri kalan kısım içinse etrafındakileri harekete geçirmek konusunda tüm gücüyle çalışacaktı.

Agile, Lean, Scrum hakkında merak ettiklerim

Scrum [altyapısı/çatısı]'nı kullanarak yazılım geliştirdikçe ortaya merak ettiğim konular çıkıyor. Zamanla araştıracağım ama şimdiden zihnimi kurcalayan bazı başlıklar şöyle;

• Yazılım Pratiklerinin Agility'ye etkisi
• Bu konuda takip edilecek bir isim Lemi Orhan Ergin. Yakın bir zamanda CraftSummit'15 de de yer aldı. Pair Programing, Test Driven Development vs. bir çok kavramla ilgili olarak sizi engin denizlerde yüzdürebilir... 
• Servis takımıları ile Proje takımlıların Scrum'a uyum hızı ve farklılıkları
• Bu konu da deneyimlerim oldu bu süreçte. Proje ve Servis takımlarının dimanikleri farklı olduğu için Scrum'ı uygulayış şekilleri de farklı olmakta. Servis takımları daha çok maintenance/bakım kısmında kalabiliyor(Mevcut sisteme destek vermek açısından). O yüzden Sprint'lerinde gelen problem kayıtları için bir buffer ayırlmaları gerekmekte. Ayrıca bu bakım çalışmalarından dolayı New Feature üretmekte de Proje takımlarından  daha geride kalabiliyorlar. Proje takımları biraz daha odak ilerleme lüksüne sahip ekipler. Aynı zamanda problem sadece kendi ürettikleri problem kayıtları ile ilgilenmekteler, ayrıca New Feature/Done oranlarıda proje takımı olmalarından mütevellit yüksek çıkmakta.
• Scrum dönüşümlerinde Sosyolojik farklılıkların etkisi 
• Scrum tamamen bir iletişim oyunu. Evet bir oyun. Bir çerçevesi ve basit kuralları var. İletişim içinde olduğu için Sosyolojik farklılıklar direkt ekiliyor. Şeffaflık üzerinden bir analiz yapmak mümkün. Acaba biz USA'daki scrum takımları kadar şeffaf mıyız?