Çeviklik için kişisel gelişim yol haritası

   Kurumsal çevik dönüşümlerin başarısı, çeviklik anlayışının ve kültürünün tüm kurum tarafından benimsenmesi ile mümkündür.  Bu sürecin verimli ve sağlıklı ilerlemesi adına kurum tarafından eğitimler ve aktiviteler düzenlense de çevikliğin yerleşmesi ve ilerlemesi adına, kendiniz ve çalışma arkadaşlarınız için hazırlayacağınız bir çevik gelişim yol haritası daha faydalı olacaktır.

   ACM ile geçirdiğimiz kurumsal dönüşümde, gamification unsurları da içeren bir çevik gelişim yol haritası sayesinde bir çok referans kaynak, hedef olarak sunulmuştu. Bu yol haritasını takip ederken her bir kaynağın oldukça eğitici ve motive edici olduğunu gördüm. Agile, Lean, Kanban ve diğer bir çok konuda sunulan makale ve kitaplar hem bilgi birikimini artırmakta, hem de çeviklik motivasyonunuzu korumanıza yardımcı olmakta.

   Bu yol haritasını referans alarak, bu süreçte karşılaştığım kaynaklarla, ben de kendi yol haritamı hazırladım. Siz de kendiniz ve kendi kurumunuz için bir yol haritası belirleyebilirsiniz. Her bir maddenin kendi Definition Of Done'ı olabilir. Örneğin kitaplar ve makaleler için kitabı okumak ve sunumunu kendi ekibinize yapmak (ACM Versiyonu) ya da yol haritasındaki belli bir kitap için değerlendirme seansı düzenleyip katılımcıların okudukları kitapla ilgili en çok ilgisini çeken kısımlarını paylaşmasını sağlayabilirsiniz. Bu seanslara katılma ve fikir bildirmek ve paylaşımın özetini kendi takımı ile paylaşmak, bunları DoD olarak belirleyebilirsiniz.

Yol haritanızın ilk kısmı mutlaka aşağıdakilerini içermeli;

Okuma - Scrum Kılavuzu,
Eğitim  - PSM Eğitimi,
Sınav    - PSM I Sınavı,

Sonraki kısmını bir çok kitap, makale ve video ile şekillendirebilirsiniz. İşte onlardan bir kaçı;

Okuma - Buzdağımız Eriyor - John P. Kotter
(Değişim yönetimi üzerine değerli bir kitap)
Okuma - Scrum Bir dönüşüm hikayesi - Mehmet Yitmen
(Scrum dönüşüm hikayesinde kendinizi bulacaksınız.)
Okuma - Scrum - A Pocket Guide - Gunther Verheyen
(Çevik değerleri ve Scruma olan inancınızı tazeleyeceğiniz bir kitap)

Okuma  - Coaching Agile Teams - Lysaa Atkins
(Adım adım ilerledikçe takımlarınıza Scrum Master olarak nasıl koçluk edebileceğinize dair, gerçek deneyimlere dayalı verimli bir kitap)
Okuma  -  Tongue Fu: Sözlü Dövüş Sanatı - Sam Horn
(Çeviklikle birlikte artan takım içi iletişimin ve doğal olarak tartışmaların yönetimi üzerine harika bir kitap)

Video   - How Painting Can Transform Communities 
Video   - My Architectural Phılosophy Bring the Community into the Process
Video   -  Bisiklet Sürmeyi Unutmak Mümkün mü?
(Çeviklik penceresinden bakınca bu videolarda çok şey bulacağınızı garanti ediyorum.)

Vaka/Makale - Dunning Kruger
Vaka/Makale - Stanford Prison Effect
Vaka/Makale - Creating Reciprocal Value Through Operational Transparency
Vaka/Makale - Fanatic Discipline - Mehmet Yitmen
(Vaka ve Makaleler akademik diliyle sade çeviklik gerçeklerini paylaşıyor. Şeffaflık, hiyerarşi, odak, kararlılık  vs. bir çok konuda detaylar bulabileceğiniz değerli çalışmalar.)

    Çeviklik dönüşümü bir süreçtir, kurumsal firmalarda yürütülen değişim/dönüşüm faaliyetlerinde üst yönetimin desteği kolaylaştırıcı bir gerçektir ama daha da önemlisi tüm çalışanların değişimi sahiplenmesidir. Bu sahiplenmeyi tüm çalışanların takip edebilecekleri bir yol haritası hazırlayarak ve takip ederek kolaylaştırabilirsiniz. Özellikle dönüşümlerin Scrum Master'lığını üstlenen Çevik Stüdyolar bu konuda ayrı bir çalışma yürütmeliler.

   Çeviklik gelişiminize faydalı olması dileğiyle...

Hatalar İle Nasıl Başa Çıkılır?

Bırakın artık hata çözmeyi Allah aşkına. Çöz çöz bitmedi bir türlü...

Daha önce yayınladığım "Scrum Ekipleri ve Hata Kayıtları" başlıklı yazımda takımların hata kayıtlarına karşı kullanabilecekleri bazı çözümlere değinmeye çalışmıştım. Bu yazım, daha hatalar ortaya çıkmadan nasıl çözülür hakkında olacak.

Hataları oluştukça çözmek hatta bu konuda çok başarılı olmak, kaliteli bir uygulamaya veya memnun müşterilere sahip olmanızı sağlamaz. Hata çözümündeki başarısı ile müşterileri memnun etmeyi düşünen geliştiriciyi ve hataları giderdiği için geliştiricisine minnet duyan müşteriyi hiç anlayabilmiş değilim. Sektör genelinde hatalar normal kabul edildiğinden midir yoksa müşterinin bizden başka çalacak kapısının olmamasından mıdır bilinmez bizim sektörde hatalar yeterince önemsenmez. "Sistem çalışmıyor!", "Ekranım dondu!" veya "Maalesef şu an işleminizi gerçekleştiremiyorum!" gibi cümleler bilişim sektöründe olağan karşılanır.

İlk evlendiğimde evimize aldığımız 2 tane dolabın çekmeceleri aynı hizada olmadığı için marangozu düzeltene kadar evden göndermemiştim. Tüm çekmeceler düzgün açılıp kapanıyor (yani çalışıyor) sadece 2-3 milimetrelik ufak bir fark ile biri diğerinden aşağıda duruyordu. Sonuçta para ile bu işi yaptırmıştım ve birebir istediğimin teslim edilmesini bekliyordum. Sipariş ettiğimiz buz dolabının bazı rafları soğuk olmasa, veya fırınımızın bir gözü bazen yanmazken bazen de yemeği yaksa herhalde aldığımız ürünü anında geri iade ederdik. Bir daha da o markadan alış veriş yapmazdık.

Sektör olarak hangi sebeplerden ötürü böyle olduğumuz hakkında (şimdilik) konuşmayı düşünmüyorum. Onun yerine bu duruma düşmemizi engelleyecek bazı yardımcılardan bahsedeceğim.

1. Yardımcı: Kendimiz

Evet doğru. Eğer elimizde hatası çok olan bir uygulama varsa bize en çok yardımcı olacak kişi kendimiziz. Elimizdeki uygulama ister yeni yazılmış ve 783 tane hata ile size devredilmiş olsun, isterse 12 yıldır çalışan ve artık kumaştan çok yaması olan bir elbise gibi olsun veyahut geliştirmesine yeni başlanmış olsun her durumda başvuracağımız ilk yardımcı kendimiziz.

Bir geliştirici geliştirdiği uygulamayı daha kaliteli yapmakla yükümlüdür. Tabii böyle söyleyince kuru bir laf oluyor. Herkes elinden geldiğince kaliteli uygulama geliştirir değil mi. Doğru. Ama sadece istemek yeterli olmaz. Bu konuyu zihnimizde canlı tutmalı ve diğer yardımcılara baş vurmalıyız. "Ah yine mi hata çıktı? O kadar da dilek tutmuş, Allah'a dua etmiştik hata çıkmasın diye!". Tamam duanın ilk aşaması olan sözlü duayı yaptın. Ama fiili duayı yapmazsan ne fayda. Yani hata olmamasını istedin ama istemenin yanı sıra ne yaptın? Sadece testçinin yapılan tüm hataları yakalayacağına güvendiysen gel bir de aşağıdaki yardımcılara bakalım.

2. Yardımcı: Geliştirme Yardımcıları

Eğer ben kod yazan bir kişi isem öncelikle işimi kaliteli yapacağım. Baştan savma ve hızlıca yazılmış bir kod ile zamanı çok iyi kullandığımı veya yöneticimi etkilediğimi düşünebilirim. Ama çoğu zaman yanılıyorumdur. Yazılan kod hatalı olmasa bile elbet biri bir gün kaportayı açacak ve yazılan kod üzerinde bakım çalışması yapacak veya üzerine yeni fonksiyonlar bina edecek. (Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. John F. Woods) Bu tür yazılmış kodlar en iyi ihtimalle, hatasız çalışsa bile ilerde başka hatalara sebebiyet verecektir. Temiz ve belirli standartlara uygun yazılan kodun kafamızı daha az ağrıttığı konusunda hepimiz hem fikirizdir.

Bu konuda kafa yoran kişiler sağ olsun bazı teknikler geliştirmişler. Code Review, Pair Programming, Test Driven Development (TDD) bunlardan bazıları. Bu tür teknikleri kullanarak hataları daha oluşmadan bertaraf edebiliriz.

Ayrıca Code Refactoring yapmaktan korkmamalı gereksiz kodları sürekli temizlemeli, ihtiyaçlara göre kodları yeniden dizayn etmeli, performans sorunu oluşturabilecek veya karmaşık kodları düzenlemeliyiz. Böylece uygulamamız daha yavaş yaşlanacak ve ihtiyaçlara daha hızlı adapte olabilecektir.

Bu konuda kendini daha da geliştirmek isteyenler Software Craftsmanship etkinliklerini takip edebilirler.

3. Yardımcı: Test Yardımcıları

Normalde her yaptığımız değişiklik sonrası, hatta ufak bir hatanın çözümünde bile etkilenen tüm noktaların test edilmesi gerekir. Ama ciddi olalım ki kimsenin o kadar vakti yok. Yazılımcı ufak bir değişiklik yaptı diye tüm testlerimi en baştan yapamam. Hele hele etkilenen diğer noktaları tek tek yeniden test edemem. Etmem lazım, ama edemem. Yazılımcılar bazen günde 3-4 kere test ortamına geçiş yapıyorlar, herhalde her seferinde 3 haftada yaptığım testleri yeniden yapmam beklenemez. O zaman ne yapacağız? Ya geliştirme yapan arkadaşımın "Sadece ufak bir değişiklik yaptım." lafına itimat edeceğiz yada sadece olası bazı noktaları yeniden test edip işimize devam edeceğiz. (Ki zaten projenin veya sprintin bitmesine çok az bir vakit kalmış).

Bu noktada test otomasyonları, test yapan kişilerin zamanını bloke eden bir çok standart testi devralarak kişilerin daha karmaşık ve yeni senaryolar üzerinde yoğunlaşmalarına olanak sağlar.

Ayrıca test yapan arkadaşlar (bu kendimiz de olabiliriz) geliştiricilerden ürün bazlı testlerini kolaylaştıracak araç ve ekranları geliştirmelerini talep etmeliler. Mesela benim sürecim başka bir kaynaktan tetikleniyorsa, her test yapışımda başka birinden benim ürünümü tetiklemesini beklememeliyim. Test amaçlı olarak kendi sistemimi istediğim parametreler ile tetikleyebilmeliyim. Veya bazen teste başlayabilmek için veriyi uygun hale getirmek testin kendisinden daha uzun sürebiliyor. Bu tür durumlar için hazırlanacak test ekranı veya kodları testçinin daha fazla senaryoda daha fazla test yapabilmesine olanak sağlayacaktır.

4. Yardımcı: Yönetimsel Yardımlar

O kadar konuşup yönetime değinmesek olmazdı :).

Yönetim tarafından yapılacak en büyük yardımın kaliteli uygulama için çalışan takım ve kişilerin önünün açılması olduğunu düşünüyorum. Üstüne bir de bu konuda destekçi ve önder olurlarsa şahane olur. Çalışanlardan elde edilecek fayda her zaman çalışılan zaman ile doğru orantılı değildir. İnsanların efektif ve kaliteli üretime teşvik edilmesi ve gerekli teknikler ile donatılması elde edilecek faydayı arttırmanın yanı sıra kaybı da azaltır.

Eğer işler kaliteli yazılım üzerine planlanırsa, yani analiz, geliştirme ve test aktivitelerinin yanına  code review veya otomatik test oluşturma aktiviteleri de eklenirse ilerde çıkacak hatalar şimdiden giderileceği için beklenmedik zaman kayıplarından dolayı planlarda da kayma azalacaktır.


Burada yazdıklarım haricinde ekleme yapmak isteyen arkadaşlar beni çok memnun ederler. Lütfen olumlu/olumsuz yorumlarınızı esirgemeyin :).

Sprint Sonlarında Çalışır Uygulama Teslim Etmek

Scrum uygulanırken zorlanılan konulardan biri de her sprint sonunda çalışır uygulama teslim etmek. Bu konuya basitçe sprintin sonunda yaptığımız geliştirmelerin hatasız çalışır olması olarak dar çerçevede bakmamak lazım. Kullandığımız eski Waterfall yönteminin hepimizde yer ettiği projelere bütün olarak bakma alışkanlığı bu konuda bizi rahat bırakmıyor maalesef. Eski yöntemlerimizi Scrum’a göre dönüştürüp aynı şekilde uygulamaktan vaz geçmeliyiz.

Şimdi hayali olarak bir proje takımına dâhil olalım: Proje için bir araya geldik ve oturup yapılacakları iyice anlamak için Grooming toplantıları yaptık. Analizler, tasarımlar havada uçuşuyor. Deneyimli arkadaşlar çok güzel bir şekilde ne yapılması gerektiğini açıklıyor. Artık projenin sonuna kadar ne yapacağımızı ve nasıl yapacağımızı büyük oranda biliyoruz. Ve ilk sprinti bitirdik. İlk Review toplantısında ilgili paydaşlara yaptığımız analiz ve teknik tasarımları gösterdik. İlerde bizi bekleyen güzel günlerden bahsettik. Onlarda (eskiden kalma alışkanlıkla) hepimizi canı gönülden tebrik ettiler. Başarılı 1-2 sprintin ardından tasarımımız artık mükemmel. Bir sonraki sprint’in planlamasına geçtik. Product Owner’ımızın planlamaya getirdiği maddelerden birini konuşuyoruz. Daha yeni tamamladığımız bir ekranda ek düzenlemeler isteniyor. Derken talep sahibi hiç beklemediği bir dirençle karşılaşıyor. Neden? Çünkü eğer orada bir düzenleme yaparsak, güzelim tasarımın birçok yerini yenilememiz gerekecek. Hâlbuki o kadar emek vermiştik.

Bu durumda doğal olarak değişime direnmeler ve neden baştan söylenmediler başlıyor. İstek sahibine eğer isteği gerçekleştirilirse ne kadar maliyete girileceği ve projenin ne kadar uzayacağı anlatılarak isteğinden vaz geçmesi sağlanıyor. İşte tam o anda can alıcı soru geliyor: “Hani Scrum değişime açıktı?”. Bir yerde yanlış yaptık değil mi?

 

Burada yaptığımız en büyük hata, eskiden olduğu gibi projeyi bir bütün olarak düşünüp bu bütünü tasarlamak oldu. Projenin bütünü yerine varılmak istenen noktaya ve hep bir sonraki adımımıza odaklanmalıydık. Groomingler bir sonraki adımlara, Review toplantıları ise hedefe doğru ilerleyişimize ışık tutuyor olmalıydı. Projeyi parçalarken, sadece birleştirildiğinde anlamlı hale gelecek parçalar oluşturmaktan ziyade, projenin çok basit ve temel özelliklerinden oluşan bir parça ve her sprintte daha gelişmiş ve daha çok işe yarar parçalar haline getirmemiz lazım. Böylece her Review toplantısında çalışan uygulama, yani projenin ta kendisi değerlendirilir. Hedeflenen haline ne kadar yaklaştığı incelenir ve talepler buna göre şekillendirilir.

Bu hali ile aslında proje, üretime geçmiş ve sonradan gelen küçük istekler ile sürekli gelişen, mükemmelleşen, yeni ihtiyaçlara en kısa zamanda cevap veren bir uygulamadan pek de farklı olmayacaktır.

Çı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