Bir agile koç olarak artık hayata dair herşeye agile gözlüklerle bakıyorum, profesyonel iş hayatımda profesyonellerle çalışırken de  özel hayatımda aile ve diğer işlerimi takip ederken de agile felsefesi hep yanımda. Bu ne demek mi, yapılması gereken işleri sıraya koymak, bitirmeden başlamamak, kısıtlı zamanda ailem ve kendim için en değerli işleri tamamlamak, şeffaf ve kolay takip edilebilir olmasını sağlamak,  “Agile Anne” olarak kızımın soruları karşısında direk kendi bildiğim doğruları, çözümü paylaşmak yerine onun kendine uyacak çözümleri bulmasını sağlamak gibi…

Agile Anne

Hal böyle olunca 6 yaşına girecek olan kızımın anaokulu aile katılım aktivitesinde  ” Agile Anne” olarak kızım ve arkadaşlarına Spagetti Marshmallow Zorluğu oyununu oynatmak direk aklıma geldi.

Bu oyunu ülkemizde ve yurtdışında profesyonellere de defalarca oynattık ve her sefer benzer deneyimleri gözlemledik ve oynayan tüm profesyonellerde aynı aydınlanma ve öğrenme gerçekleşti. Oyunla ilgili yurtdışı örneklerini ve detayları öğrenmek isterseniz Ted Talk taki kısa videoyu izmelemenizi ya da bu oyunu oynamak için bize ulaşmanızı tavsiye ederim. Bu yazıda oyunun ana amacından bahsetmeyeceğim, bizim ülkemizde sonuçlar nasıl farklılaşıyor, eğitimin  iş yapma biçimimizi çocuk yaştan itibaren nasıl geliştirdiğini ve kültüre dönüştüğüne odaklanacağım.

20 adet Spagetti çubuğu,1 adet Marshmallow, 1 m kadar ip, 1 m bant ve makas. Hepsi çocukların bile aşina olduğu malzemeler…

Oyunda katılımcılardan istenen ellerindeki bu malzemeleri kullanarak belirli bir zaman dilimi içinde takım olarak kendi başında ayakta durabilen en yüksek kuleyi yapmaları, ve bu kulenin üstünde de o pamuk kadar hafif marshmallowun tek parça olarak duruyor olması. Yani çok basit bir istek değil mi? Hepsi bu, neresi zor olabilir di mi? Neler deneyimlediler, ben neler gözlemledim?:)

Anaokulu çocuklarıyla ilgili deneyimimden kısa notları şöyle özetleyebilirim:

  • Çocuklar oyunu anlattığımda çok heyacanlandılar, bir de onlara onlarla aynı yaşlarda bu oyunu oynayan diğer çocukların resimlerini gösterdiğimde bir hayli ilgilendiler.
  • Bu yaş grubu bu oyunu oynamaya uygun, bahsettiğim gibi malzemeler tehlikeli değil ve hepsinin bildiği malzemeler. Hatta yurtdışında yapılan çalışmalarda anaokulu çocuklarının (mimar ve inşaat mühendislerini ayırırsak) yeni mezun çalışanlar ve “CEO” lardan daha yüksek kuleler yaptığı gözlemlenmiş, sonuçları incelemek isterseniz bu makalede bulabilirsiniz.
  • Benim çocuklarım iki grup olarak yarıştılar, yönergeleri en az profesyoneller kadar gayet net anladıkları hemen dikkatimi çekti.
  • İş hadi bakalım şimdi sizde “takım” olarak çalışarak en yüksek kuleyi yapın dediğimde ise bu takım ne demek acaba diye duraladılar.
  • Malzemeleri paylaşma yoluna gittiler, daha aktif çocuklarımız malzemeleri kendi önlerinde topladılar ve birşeyler yapmaya başladılar.
  • Öğretmeni ve ben bir kaç kez takım vurgusunu yapmamıza rağmen herkes kendi başına bir kule inşa etmeye çalıştı.
  • İki gruptan bir tanesi kısa zamanda bunun bireysel bir aktivite olmadığını ancak beraber çalışırlarsa, yardım ederlerse ve malzemeyi ortak kulanırlarsa hedefe ulaşabileceklerini keşfetti, sonunda gerçekten hedeflenen yapıya ulaşabildiler. 
  • Diğer grup ise limitli süre sonunda hedefe ulaşamadı, ortada israf olmuş malzeme dışında sonuç çıkmadı.
  • Yani kısacası bizim çocuklar küçüklükten itibaren takım çalışması değil, bireysel çalışma, sınav, bireysel rekabet üzerine yetiştiğinden küçük yaşta da yetişkin yaşta da gerçek takım çalışmasına geçişleri zor oluyor.
  • Artık biliyoruz ki iş hayatında karşılaştığımız problemler karmaşık, geliştirmemiz gereken çözümler tak çalıştır değil. Sadece tek kişinin yetkinliğine, uzmanlık bilgisine dayanarak hedeflenen iş sonucuna ulaşmak mümkün değil çoğu zaman. Dolayısıyla farklı yetkinlik ve uzmanlığa sahip profesyonellerin takım olarak bir araya gelip çözümler üretmesi , varsaymaksızın hızlı test etmeleri ve iteratif olarak üretmeleri gerekiyor.
  •  Bir çok ülkede “kendi kendine örgütlenme, “time box”, “takım çalışması” , ” deneysel süreç” gibi kavramlar doğal olarak gelişirken bizim ülkemizde iş yapma biçimine dönüştürmemiz için gerçekten odaklanmamız ve desteklememiz gerekiyor, bunu Agile koç olarak çalıştığımız profesyonellerde destekliyoruz  ve zaman içinde gelişebildiğini gözlemliyoruz.

Kıssadan hisse “Agile Anne” olarak çocuklarla bu zorluğu deneyimlemek güzeldi, ve bize özel sonuçlara da ulaşmak.. Ve biliyorumki  “Agile Koç” ve aynı zamanda bir takımın parçası bir profesyonel olarak daha çevik olabilmek için yapacağımız çok işimiz var.

Çevik kalın,

 

Scrum Antipatern’ler-Kaçınmamız Gerekenler

“Antipatern”( antipattern) tabiri,  yazılım dünyasında kullanılır. Genel olarak  başlangıçta çekici, kolay görünen çözümlerdir. Resimde olduğu gibi bol çiçekli bir yol gibi, ancak daha sonra problemi çözmekten uzak ,daha büyük sorunlara , sizi resimdeki gibi korkunç canavarlarla karşılaştırabilecek davranışlar, çözümler olarak nitelendirilir.

Scrum kılavuzunda da belirtildiği üzere;

İnsanların mümkün olan en yüksek değere sahip ürünleri üretken ve yaratıcı bir şekilde geliştirirken, karmaşık ve adaptasyona açık sorunları ele alabildikleri bir çerçeve.

Scrum tanıtırken kullanabileceğiniz anahtar 3 sıfat dersek te;

  • Basittir
  • Anlaması kolaydır
  • Ustaca yönetmek zordur.

45 dk ya da 1 saat içerisinde Scrum’daki bütün unsurları birisine anlatabilir, anlamasını sağlayabilirsiniz. Aslında çoğu zaman karmaşık problemlerle karşılaştığımızda ve iş çıkarabilmek için tek bir yetkinlik ve uzmanlığın yeterli olmadığı durumlarda içgüdüsel olarak geliştirdiğimiz  “task force”,”war-room” gibi uygulamaların çoğaltıldığı bir çerçeve. Ve bütün araştırmalar ve deneyimler gösteriyor ki 1990 lı yılların başından beri kullanılan Scrum, bu çerçeve doğru uygulandığında başarımızı ve verimliliğimizi arttırıyor.

Ama ,ya anlaması çok kolay, ne gerek var böyle yapmaya ben tavsiye edildiği gibi uygulamadan ve ustalaşmadan ara çözümler, kısa yollarla bunu uygulayayım yani “antipatern”ler geliştireyim ve kullanayım dediğinizde beklenen başarı ve etki düşüyor ve o zaman Scrum-But dediğimiz formunu alıyor.

 Daha önceki bir yazımda dövüş sanatları uygulamasındaki çırak-usta-profesyonel seviyelerinin (Shu-Ha-Ri) doğru şekilde geçilmesinin öneminden bahsetmiştim. Bu konsepti hatırlamak isterseniz blog yazıma buradan ulaşabilirsiniz.

Scrum’ın geceden sabaha bir mucize yaratmayacağını, insanların yeni çalışma şekillerine alışması ve özellikle kültürel dönüşüm için zamana ihtiyaç olduğunu aklımızda tutalım. Çok sık karşılaştığımız dolayısı ile yorumsuz olarak aşağıda en kötü “antipatern”lerden bahsedeceğim.

 

  • Takım kendisine görev atanmasını bekler, Scrummaster’da görevleri atar ve bu şekilde kendi kendi kendini örgütleyen ve karar alan bir takımın gelişmesini tahrip eder.
  • ScrumMaster’ın ismindeki “Master” kısmı teknik ya da domain uzmanı gibi algılanır ve takımdaki en deneyimli yazılımcı ScrumMaster olarak belirlenir, bu şekilde takım geliştirme kapasitesini olumsuz etkilemiş olur.
  • Product ownerlar takımı en iyi şartlarda sadece Sprint planlama ve Review da görür, Sprint süresince takımla ve müşteriyle vakit geçiremez, dolayısıyla hızlı karar alma ve öğrenme süreci yavaşlar.
  • Sprint planlama toplantısında bütün taskler kişilere baştan atanır ve tüm Sprint boyunca kollobrasyon yaratmaksızın herkes sadece kendi taskının sorumluluğunu alır, takım değil, bireysel çalışma devam eder.
  • Bu şekilde kollobrasyon ve takım olarak günlük karar alma kabiliyetine imkan sağlayan Daily Scrum yapmazsak olur mu sorularını duymak çok şaşırtıcı değil:) Hemen daily Scrum’dan vazgeçilir.
  • Kendi başına anlam ve değer üreten fonksiyonlar takip edilmez, ister sonuca ulaşsın, ister ulaşmasın tasklara odaklanılır.
  • Retrospektif yapılmaz.
  • Review yapılmaz, yapılırsa da sadece o sprintte ne üretildiğine bakılır, genel olarak servis ya da ürünün hangi noktada olduğu ve büyük resim unutulur.
  • Toplantılarda “timebox” gözetilmez.
  • Sprint devam ederken Sprint kapsamının büyük bir oranı değişir.
  • Sprint planlamada sadece ne yapılacağı konuşulur, Nasıl sorusunun cevabı için ilerleyen günlerde zaman kaybedilir.
  • Bir şirkette takımlar “velocity” üzerinden karşılaştırlır.

Bir çırpıda aklıma gelip yazdıklarım bunlar , sizler de bu “antipatern”lere ekleme yapmak isterseniz bize yazın, yazıya ekleyelim.

Bir sonraki yazıda görüşmek üzere, çevik kalın.

Agile Fidan Dik, Sula

ODTÜ EEE mezunu, yüksek lisanslı telekom mühendisi, Agile tutkunu. Bir ara 'Alamancı', şimdi Türkiyeli, voleybolda smaçör ve acemi sörfçü. ~~ METU EEE Alumni, MSc. Telecomm. Engineer, Agilist. Long-term expat in Germany, now back to TR; wing spiker & amateur surfer.

Merhabalar,

Bu yazıda sizlere, gerek yurt içinde gerekse yurt dışında gözlemlediğim, deneyimlediğim bir durumdan ve olası çözümlerinden söz etmek istiyorum. Agile olmak isteyen, bu amaçla yola çıkan pek çok firmanın yaşadığı bir durum bu: Tabir-i-caizse, ektiğiniz (Agile) fidanın tutmaması.

Agile Fidanı

Uygulayanlar bilirler, Agile yaklaşım, sadece geliştirme takımları kurup onlardan çıktı beklemekle olmaz. Bir süre sonra takımlar, bu yaklaşımı benimseyip doğru işletirlerse, kendi önlerindeki engelleri çöze çöze giderek, zamanla başka engellere takılmaya başlar. İç yapıdan doğan, süreçlerden, rollerden ve daha pek çok şeyden doğan bu görünmez cam duvarlar birdenbire görünür olur. Şimdi sıra, şirketin önündeki engellere; ‘business agility’nin, yani şirketin uçtan uca çevikliğinin önündeki engellere gelmiştir. Organizasyonel engelleri kaldırmadıkça da şirket hiçbir zaman tam anlamıyla agile olamaz, ancak belirli bir yere kadar gelip orada takılır, kalır. Bu noktada yönetim kadrolarının, liderlerin, üzerlerine düşen çok önemli görevler olduğunu bilmeleri gerek.

Lider Yönetim

Liderlik edecek yönetim kadrolarının desteği ve inancı olmadan, tam olarak anlamadan,  inanmadan yapıldığında Agile, ancak yarım yamalak sonuç verir. Bu durumda, biz “change agent” ya da Agile koçlar çekildikten sonra ne olur dersiniz? O ellerinizle tohumlarını ektiğiniz, özene bezene sulayıp filizlendirdiğiniz, yeni yeşerttiğiniz agile fidanı sahiplenilmezse, bakılmazsa, tam da yeni yeni tutunmaya, kök salmaya başlamışken, ilgisizlikten, bakımsızlık ve susuzluktan kurur, ya da ilk rüzgarda kırılır. Belki de birinin “Şu daha hızlı büyüse ya!” diye aşırı gübrelemesiyle, yapraklarından çekiştirmesiyle can verir, ya da (belki de en acı olan), sonradan gelen birinin “Bu ne böyle? Yabani otlar bürümüş burayı, yolun şunları, buralar bize lazım.” yaklaşımına kurban giderek, sökülüp atılır. Böylece bu işe harcanan onca bütçe, çaba, zaman ve emek de çöpe gitti..

Bunun hemen görülmeyen, ama bir o kadar da ciddi yan etkisi ise şu: Agile olmayı (Scrum çalışmayı, Kanban yapmayı..) bir kere ‘denemiş’ olan ekipler ve şirketlerde, toprakta anız yakmaya benzer izler kalır; yeniden denemeye karşı direnç oluşabilir. Bir gün gerçekten Agile olmayı istediklerinde, aşmaları gereken (içsel ve dışsal) eşik her turda yükseldiği için, başarma şansları giderek azalır. “Biz geçen sene denedik, olmadı”,  “Agile/Scrum/XP/.. bize göre değilmiş”, “Bizim şirkete uymadı” – tanıdık geliyor mu?

Bir Kanban Tahtası Örneği

Öyleyse Agile fidanının yaşaması, yeşermesi, boy atıp meyve vermesi için ne yapmalı? Aslında, bunun için yapılabilecek pek çok şey var. İçlerinden en önemli birkaçı:

  • Agile çalışacak ekipler eğitim & koçluk desteği alırken, paralelinde liderlik yapacak kadrolara da benzer desteği vermek; önlerine net ve paylaşılmış bir vizyon koyarak, ileride değişip dönüşecekleri rollerini, görevlerini netleştirmek, onları bu dönüşüm rüzgarına hazırlamak
  • Geliştirme ekipleriyle yönetim arasında şeffaf, güvene dayalı iletişim için diyalog kurmak
  • Toprağı uygun hale getirmek  – ki, bu noktada şirket kültürü büyük önem taşıyor. Agile’ın temelinde yatan güven ve şeffaflık ortamını sağlamak, ektiğiniz fidanın o topraklarda tutunma ve yeşerme şansını önemli ölçüde artırır.
  • Bu değişimin sadece (örneğin BT’deki) geliştirme ekipleriyle sınırlı kalmayacağını bilmek; şirketçe bunun tüm organizasyonu, (ve hatta müşterileri de) içine alacak bir dönüşüm olduğunun ayırdında olmak

    Değişim Rüzgarları

  • Şirket içinde elbette ki direnç gösteren, buna daha çok veya daha az inananlar olacaktır. Ancak temelinde, yönetimin ve tüm paydaşların desteğini, CEO’dan gerekli bütçeyi kolunun altına alarak, yola öyle çıkmak
  • Bu işin, gözle görülmeyen fakat çok önemli bir parçasının da kültürel boyutta olduğunu bilerek hareket etmek, hatta bu kültürel dönüşüme aktif yön vermek – bizim sıklıkla agile dönüşümlerine, ETF’in ilk halkası olan “assessment” – durum değerlendirmesi- ile başlamamızın ve “cultural assessment” için kendimize özgü araçlar geliştirmemizin bir nedeni de bu.

    Dönüşümün Kültürel Boyutu

  • Sabırlı olmak – daha önce de dediğim gibi, bu bir kültürel dönüşüm. Bunun elbette ki bir gecede / haftada / ayda olmayacağını bilerek hareket etmek, yeniliklerin yerleşmesi, oturması için zaman tanımak. Yabancı bir dil öğrenirken, tek bir yeni kelimeyi dağarcığınıza katmak, kendi cümlelerinizde kullanabilmek için 80 (seksen!) kez bir yerde duymuş/okumuş olmanız gerektiğini biliyor muydunuz? Benzer şekilde, yeni alışkanlıkların oturması da zaman alır. Nasıl ki bir ağacı yapraklarından çekerek daha hızlı büyütemezseniz, Agile da o şirketin toprağında, o kültürel ve dokusal şartlarda hangi hızda büyüyecekse, o hızda büyüyecektir. (Bu süreci hızlandırmak için neler yapabileceğinize, birazdan değineceğim)
  • Üstteki maddeyle elele giden – hemen sonuç beklememek. Yeni ekilen bir fidanın da bir gecede büyüyüp meyve vermesini beklemeyiz. Aynı şekilde, Agile’ın da tutunması, yeşerip meyve vermesi için zaman, emek ve sabır gerekli. İstediğimiz kadar hızlı büyümüyor, hemen meyve vermedi diye kestirip atmak, hem israf olur, hem de sizi agile’ın ulaşabileceğiniz potansiyel faydalarından mahrum bırakır. Altı haftada yirmi yedi metre büyüyen ağacın hikayesini bilirsiniz:

    6 Haftada 27 Metre Büyüyen Ağaç – Bambu

  • Başarıları kutlamak ve hatalardan ders çıkarmak. Başarılarda sevinci sonuna kadar yaşamak, ve bunun yanında asıl öğrenme fırsatının, asıl gelişmenin başarısızlıklarda gizli olduğunu bilmek, onları iyi analiz etmek, suçlu aramadan bir dahaki sefere neyi daha farklı yapalım yaklaşımıyla, elde ettiğimiz kazanımlarla ilerlemek (“Safe-to-fail experiments” ya da “güvenli-ortamda-başarısızlık deneyleri” kavramı, agile42 olarak kurumsal dönüşümlerde sıkça kullandığımız, akademik araştırmalarla da desteklenen önemli araçtır. Bu konuda daha detaylı bilgi için Cognitive Edge’e bakabilir, ve bize ulaşabilirsiniz.)

    Domain’lere Göre İş Yaklaşımları – Cynefin Çerçevesi

  • Şirketçe, gerçekleşen dönüşümün arkasında durmak, bu kültürü tüm şirkette yaymak için çalışmalar yapmak – örneğin görseller, duyurular, posterler, farkındalık eğitimleri, belki gönüllü bir Scrum Master / iç koçun haftalık zaman ayıracağı, sorusu olanların gelip danışabileceği bir “Office Hour”..özetle bu yönde, buna yönelik düşünmek ve yapıcı olmak
  • Ektiğiniz fidanın daha hızlı meyve vermesi ve gerçekleştireceğiniz dönüşümün kalıcı ve sürdürülebilir olması için yardım almak, uzman koçluk desteğiyle ilerlemek
  • Müşteriyi bilgilendirmek ve ekiple iletişimde olmasını sağlamak; onu da sürece dahil etmek

Agile yolculuğunu kolaylaştırmak ve değişimleri kalıcı kılmak için yapabileceklerinizden bazılarına yukarıda değindik. Hepimiz biliyoruz ki, değişmeden, değişim olmuyor. Şöyle düşünelim: bu süreçte ‘büyüme sancıları’ yaşamak, aslında bir şeylerin gerçekten değişmeye başladığını gösteriyor. Engellerden korkmadan, inanarak, isteyerek yola çıktığınızda zaten önünüze çıkan şeyler sizi yıldırmayacak, yoldan döndüremeyecek, size ‘engel’ olamayacak.

Bu tarz bir dönüşüme (Agile dönüşümle ilgili, Regina Martins’in şu yazısına da bakabilirsiniz), tıpkı bir fidanı ekip büyütürken olduğu gibi, hissiyatla yaklaşmak gerek. Neye ihtiyaç var? Sıradaki adım nedir? Karşımıza çıktıkça, çöze çöze, adım adım ilerliyor olmalıyız. Biliyorsunuz Agile’da kullanıma hazır, kalıp çözümler yoktur. Sihirli bir formül olmamakla beraber,  şu üç temel malzeme, “Agile fidanı” için hayati önem taşır: şeffaflık, güven, ve sabır.

Unutmayın – yolun yarısında inancınızı kaybedip geri dönerseniz, neler kaybettiğinizi asla bilemezsiniz..

-Eda COŞKUNER-

 

ScrumMaster ve Takım Koçlarına Bazı Tüyolar-1. Bölüm

Scrum eğitimlerinde ve yeni takım kurulumlarında en fazla konuştuğumuz konuların arasında Scrumdaki roller oluyor. Daha önce  Product Owner rolüne ilişkin bir yazı paylaşmıştım. ScrumMaster rolü toplum olarak çok alışık olduğumuz bir rol değil belki de, Agile konseptlerin, çerçevelerinin son yıllarda daha fazla uygulama alanı bulmasıyla çokça gündemde olan bir rol. Bazen yanlış algılanabiliyor ve uygulama örneklerini görebiliyoruz. Dolayısıyla bu rolü taşıyan arkadaşlarımızın “Hizmetkar Liderlik” rolünü doğru şekilde icra etmesi gerekiyor. Bu yazı ve devamında özellikle ilk kez bu rolü üstlenen arkadaşlarıma hem kendi tecrübelerimden hem de takımlar üzerine çalışmalar yapmış kişilerin görüşlerinden alıntılar yaparak bazı tüyolar ve paylaşımlarda bulunmak istiyorum. Bu arada Agile şemsiyesi altında Scrum kullanmıyor olabilirsiniz ancak hangi çerçeveyi kullanıyor olduğunuzdan bağımsız özellikle yeni kurulan takımlarda ve iş yapışı değişikliklerinde sürekli iyileşmeyi gözeten bir takım koçunuzun olarak ta rol aldıysanız bu yazı size göre de …Yazının geri kalanında ScrumMaster kelimesini sadece Scrum uygulayan takımlar için değil bu bağlamda sürekli iyileşme ve prosesi gözeten takım koçları için de kullanıyor olacağım. Bir kaç başlıkta ve iki blog yazısı olarak paylaşımda bulunacağım.

Kendinizi Tanıyın, Gözlemleyin ve Geliştirin

ScrumMaster olduğumuzda geçmişten gelen alışkanlıklarımız ve görev olarak yaptığımız rutinlerden hangilerinin rolümüzle çeliştiğini bir şekilde düşünmek , şeffaf bir şekilde kendimizde farkındalığı sağlamak, kendimizi denetlemek ve adapte olmamız gerekiyor. Bu sadece takımlar için bir yolculuk değil, bizim de üstünde emek harcamamız gereken bir yolculuk. İyi bir ScrumMaster olmanın önemli adımlarından biri gözlem ve denetleme yapmak. Denetleme ve yönetme önce kendimizle başlıyor.

Bu konuyu bir örnekle somutlaştırmak istiyorum. Daha önce proje yöneticiliği ya da ekip yöneticiliği yapmış kişilerin ilk ScrumMaster oldukları yaşadıkları ve benim de yaşadığım eski alışkanlık ve davranış şekli “command ve controlism” den hızlı bir şekilde kurtulma zorunluluğu. Bu farkında olmadan zamanla edindiğimiz bir alışkanlık. Geçmiş iş tanımımız insanları , ekipleri yönetmek ve kontrol etmek üzerine olsa da artık ScrumMaster olarak böyle bir görevimiz yok ve hatta bundan “cızzzz” kesinlikle hızlı şekilde kurtulmamız gerekiyor. Ben ilk ScrumMaster olduğum zamanlarda hatırlıyorum, farkında olmadan Retrospektif toplantılarında alınması gereken aksiyonlarla ilgili nerdeyse kişilere iş atama ve görev paylaşımıyla ilgili yönergelerde bulunuyordum, elbette bunu o zamanlar iyi niyetle yapıyor olsam da kendi kendini yöneten bir takım geliştirmek için doğru bir davranış şekli değildi. Bu alışkanlıktan önce farkına vararak, sonra denetleme ve kendimi kontrol ederek dönüştürerek kurtulabildim:)

Eminim hepiniz kendinizi değerlendirdiğinizde bir ya da bir kaç tane buna benzer davranış şeklini gözlemleyecek ve hızlı aksiyon alacaksınız, eğer çelişen davranışlarınız yoksa da geliştirmek istediğiniz davranışlar için alıştırma yapabilirsiniz.:)  Lyssa Adkins  Coaching Agile Teams kitabının 1. bölümünün tamamını  kişisel farkındalık ve gelişime ayırıyor ve “It Start with you” genel başlığı altında bazı önerileri paylaşıyor, bence faydalı paylaşımlar, okumanızı tavsiye ederim.

Güven ve Etkileşim

Agile Manifesto’da yer aldığı gibi İnsanlar ve etkileşimlerinin süreçler ve araçlardan daha önemli ve öncelikli olduğunu unutmamız lazım. Özellikle Scrum’a ik geçişte kitabına uygun bir şekilde süreci , aktiviteleri akıtmak ve yürütmek önemli, ancak ekiplerimizi bunları emme basma tulumba gibi ezberden yapan robotlara dönüştürmek değil amacımız:) Bu şekilde davranış hangi Agile çerçeveyi kullanırsak kullanalım sürecin etkinliğinin kısıtlı kalmasına sebebiyet verecektir. Bu sebeple koçluk yaptığınız ekip arkadaşlarını tanımalı, sizi tanımalarına fırsat vermeli ve sağlıklı bir süreç için etkileşimde bulunulması gerekiyor. Ekipte öncelikli olarak güven ortamının yaratılması gerekiyor ve ekibinizin size, sizin de ekibinize güvenmesi elzem. Ancak güvenin olduğu ve etkileşimin açık ve şeffaflığa izin verdiği ortamlarda problemler ortaya çıkar ve ekip ve siz daha iyisini yapmanızı engelleyen konuları tartışır ve aksiyon alabilirsiniz. ScrumMaster olarak bu konuda size rehberlik edebilecek ve takımların etkinliğini azaltan Patrick Lencioni’nin “Ekiplerin 5 Temel Aksaklığı” modelini anlamanızı ve ekiplerinizde bu aksaklıkları çözümlemeye odaklanmanız iyi olacaktır. Bir ekip olmanın en temelinde güvenin oluşturulması gerekir. 5 Temel aksaklık Piraminde görüldüğü üzere temelde güven olmadıkça onun üstüne daha iyisi için sağlıklı çatışma, taahüt , sorumlu hissteme ve ortak sonuçlara duyarlılığı inşa etmek pek mümkün değil.  Ben genel olarak güvenden bahsederken birkaç anlamına değineceğim.

Birinci anlamı sadece raporlama yada bazı aktiviteleri yürütmek için ekiple vakit geçiriyorsanız, birbirinizi tanımak ve etkileşimde bulunmak için emek ve zaman harcamıyorsanız ekiple aranızda güven ve şeffaflık oluşamayacak, problemleri sizinle kouşmayacaklardır. Bunun bir örneğini geçenlerde ScrumMaster arkadaşlarımdan biriyle konuşurken duydum. Yeni ScrumMaster olan ve iyi niyetli olan bu arkadaşım, ekibiyle sadece kısa toplantılarda biraraya geldiğini,iş sonuçları çok olumlu olmadığı halde ara sıra yaptıkları kısa retrospektiflerde hiçbir problemden bahsedilmediğini, herşeyin yolunda gittiği mesajının çok sık vurgulandığını söyledi. Eğer ekiplerimizile etkileşmiyorsak ve güven aşılayamadıysak bu karşılaşabileceğimiz durumlardan birisi.

Güven eksikliğini gösteren bir diğer durum da hataları gizlemek ya da yardım istemekten çekinmek, sadece kişilerin yetkinliklerine olan güvenden ziyade, eksikliklerimizi de rahatça paylaşabilme güveni, bunu da rol model olarak kendimiz göstermeli ve oluşmasına katkı sağlamalıyız.

Varsaymayın :)Takımınızı Gözlemleyin ve hedeflenen davranış değişikliğini check edin.

Bir ürün/ servis geliştirirken de düşülen en büyük yanılgılardan birisi en baştan herşeyi anladığımızı düşünmek, varsaymak. Takımlarla çalışırken de benzer bir yanılmasamaya düşebiliriz.

Bir diğer üst başlıkta olduğu gibi etkileşimde bulunmak ve gözlemlemek için takımla kaliteli vakit geçirmeliyiz. Problemleri ve nasıl yaklaşacağınızı ilk seferde anladığınızı düşünebiliriz, ne kadar tecrübeli olursak olalım  yine de varsaymak yerine ekibinizden tespitler için teyit almamız gerektiğini unutmayalım. Bazen bazı aksaklıklar temelinde başka problemlerin göstergeleridir ve sadece buz dağının üstünü temizlemek değil sorunları kökten anlayıp ekipleri desteklemek için bolca gözlem yapmalıyız. Takımın ancak inandıkları problemleri çözmek için gerçekten davranış değişikliğine gideceklerini unutmayalım. Bu davranışlara gitmek için tek yol tek araç olmayabileceğini ve farklı çözümlemelerle destekleyebileceğinize kendinizi açın ve ancak istenen değişikliğe ulaşıp ulaşmadığı hissi kalben vuku ile değil metriklerle takip edebileceğinizi gözardı etmeyelim.

Sessizliğe Sabrınızı Artırın:) Dinleyin…

Süreçlerinizi iyileştirmek veya yeni konuları gündeme getirmek, fikir alışverişinde bulunmak için ekiple bir araya geldiğinizde konuyu geliştirmek için ScrumMaster olarak soru soruyor olabiliriz. Ekip ister süreç konusunda yeni, ister tecrübeli olsun bazen sorularınız ardından sessizlikler olabilir. Hatta sorduğumuz konu hakkında domain uzmanu olabiliriz. Bu eskiden benim başıma gelebilen birşeydi, sessizlik oluştuğunda kendi sorularımın yanıtlarımı vermem…Oysa ScrumMaster rolünde yapmamız gereken sessizlik karşısında sabırlı olmak ve ekipten yanıt gelmesini beklemek. Emin olun bir süre sessizlikten sonra birisi konuşmaya başlayacaktır.

 

Dinlemekte bir o kadar kritik bir yetkinlik, dinlerken karşı tarafın söyledikleri, ses tonu ve vücut diline odaklanmanız yani tam anlamıyla dinlememiz gerekiyor. size etkili bir egzersiz tavsiye ediyorum, bir sonraki ikili konuşmanızda ya da takımla bir araya geldiğinizde nasıl dinlediğiniz konusunda kendinizi denetleyin, karşı taraf konuşurken kendi söyleyeceklerimi ya da hikayelerimi mi düşünüyorum, karşı taraf dinlediğimi anlıyor mu, ses tonu, vücut dili, kelimeler hepsini yakalayabiliyor muyum? Çoğu zaman en üst seviyede dinlemediğimizi farkedince şaşırmayın:)

Yazımın ilk bölümünde bu birkaç hususu hem tecrübelerim hem de empirik ve bilimsel bazı kaynaklarla paylaştım. Bu konuyla ilgili önümüzdeki günlerde yazının devamı olarak değinmek istediğim birkaç husus daha var. Sizler de yazımı okuduktan sonra bu tüyolara katkı yapmak isterseniz lütfen yorum bırakın.

Keyifle okumanız dileğiyle,

 

 

 

Sürekli Öğrenmek ve Paylaşmak

Aslında yazıma biraz agile42 olarak bizler sürekli öğrenmek ve paylaşmak için neler yapıyoruzu bahsederek başlamak istiyorum. Yazının ilerleyen kısımlarda farklı firmalarda gördüğüm örneklere de değineceğim.

2007 yılından beri salt Agile üzerinde 10 farklı ülkede , farklı profil, ölçek ve kültürlere sahip organizasyonlarla çalışmış olan bizler bir sürü tecrübe biriktiriyoruz. Başarılı ya da failure olmuş bir çok pratik , uygulama deneyimledik ve bunlardan öğrendik. Öğrendiklerimizi kendimize saklamak yerine paylaşmak ve çoğaltmayı seviyoruz. Beraber çalıştığımız organizasyonlar bize bağımlı kalmasın , yetkinlik ve know how ı aktardık ve rol model olarak gösterdikten sonra ara ara bizlerin değerlendirmeleriyle Agile yolculuklarına kendi başlarına devam edebilsinler istiyoruz.

Sürekli öğrenmek bizim çalışma kültürümüzün bir parçası, bunun için her 2 ayda bir bütün koçlar biraraya gelerek birbirimizden öğrenme, paylaşma ve hizalanma için biraraya gelip kampa giriyoruz. kendimizin uygulamadığı ya da deneyimlemediği birşeyi sadece trendy olduğu için beraber çalıştığımız organizasyonlara önermiyoruz.

kockamp-2

Koç kampta Presentation Kareoke yi deneyimlerken biz 

Organizasyon olarak kendimizi geliştirirken her bir koç ta kişisel olarak kendini geliştirmeye zaman ayırıyor ve emek harcıyor. İşte bu emeklerin sonucu bugün  http://www.agile42.com.tr/tr/ web sitemizde Agile ‘a ilgi duyanlar için paylaşıma açık bir sürü bilgi var; case study, müşteri deneyimi, blog yazıları vbg. İngilizce yazı paylaşımlarının yanısıra her ülke kendi dilinde yazılar yayınlayabiliyor.Şirket dışında yaptığımız bu paylaşımların yanısıra şirket içinde de yeni deneyimler ve bilgiye kolayca ulaşabilmek için i herkese açık bir bilgi havuzu var. Buradan ihtiyaç duyulan her bilgi kolaylıkla çekilebiliyor. Biz bunun faydasını gördükten sonra beraber çalıştığımız organizasyonlara da benzer bir uygulamayı kullanıma açtık,bilgiyi sadece kendimize saklamadık . Team Coaching Framework yani TCF  tcfuygulaması kendi deneyimimizi beraber çalıştığımız organizasyonlara genişlettiğimiz bir uygulama. Burada bizim kullandığımız araçlara , koçluk kartlarına ulaşılabiliyor.

Öğrenmek ve paylaşmak için yaptığımız en önemli şeylerden biri de “pair working”.Bu da en fazla yapmaya özen gösterdiğmiz ve katkısı olan konulardan birisi. Gerek eğitim verirken gerekse kendi aramızda konuların üzerinde çalışırken, yeni çalışmalar tasarlarken ve çalıştayları yönetirken pair working yapıyoruz. Farklılıklarıızın farkındayız ve buna saygı duygu duyuyoruz ve bunun sonucunda kalitesi daha yüksek ve daha enerjik çalışmalar yürütüyoruz.Bu takım olarak birbirimize güven duymamıza da katkı sağlıyor. Kendi firmamız dışında gördüğüm iyi örneklerden birisi de  Amerika’dan .Geçen yıl Amerika’da yaptığımız Koç Kampta Michigan Ann Arbor’da Menlo isimli bir şirketi  ziyaret ettik. Burada value streamlere göre ayrılmış ekiplerde çalışma esası Pair workinge dayalı, iki kişi bir bilgisayar kullanıyor ve tek başına hiçkimse bir tek kod satır bile yazamıyor.

open-agile

Eda ve ben bir çalıştayı fasilite ederken, pair working

Paylaşımı en yüksek seviyelere çıkarmak için  çalışma anlaşmamız, bunu sağlayan pratikler ve malum 10 farklı ülkede olduğumuzdan hızlı iletişim  için bazı araçlar da kullanıyoruz. Colocated çalışabilmek için maksimum 2 ayda bir Koçkamplarda biraraya geldiğimiz gibi , dağıtık takım olarak çalıştığımız zamanlarda Slack, Yammer, Trello , Skpye gibi bir çok teknolojik aracı da kullanıyoruz. Daily stand uplar bizi hizalamak ve bir sonraki aksiyonlarımızı belirlemek, paylaşım için kullandığımız pratiklerden birisi. Öğrenebilmek için kaliteli vakit ayırmak ve odaklanmak önemli, bunun için de Pomodora Tekniği, squad çalışma grupları pratiklerini kullanıyoruz. Artık bu pratikler kültürümüz ve çalışma şeklimimizin bir parçası. Pomodoralarla odaklı ve kaliteli vakit ayırabiliriz, bölünmeksizin öğrenebilir ve iş üretebiliriz, bu YTÜ Davutpaşa kampüsü Teknopark’ta bulunan VNGR firmasında da rastlamıştım. Biz squadları gönülülük usuluyle öğrenmek ve geliştirmeyi odaklı sağlaması için kullanıyoruz. Öğrenmek istediğimiz alanlara göre farklı profil, deneyim ve bilgi sahibi kişi biraraya gelerek ortak bir hedefle çalışabiliyor.

Sürekli öğrenmeyi ve paylaşıma açık olmayı güçlendiren davranışlardan birisi de geribildirim almak ve dinlemek. Paylaşımlarınızın yansıması ve nasıl algılandığını öğrenmek için  geribildirim sormalı, bunu ciddiye almalı ve değerlendirmemiz gerektiğinin farkındayız. Gerbildirim almak için illa yazılı formlar kullanmamız gerekmiyor. Biz koçlar geribildirimi bir armağan olarak değerlendiriyor ve bunun öğrenme döngüsünün önemli aşamalarından biri olduğunu biliyoruz. Bunun için de Perfection game, Ritual Dissent , ROTI gibi hızlı pratikleri kullanıyoruz. Bu tekniklerin detaylarını merak ediyorsanız bizimle iletişime geçebilirsiniz.

Deneyimli koçlarımızın tecrübeyle öğrendikleri ve elde ettikleri konuları derledikleri ve soft olarak herkese paylaşıma açık 2 kitabı paylaşarak yazımı tamamlamak istiyorum.

Birincisi koçlarımızdan Andrea ve bir arkadaşının ortak yazdıkları bir kitap.

agiletransitionAgile Transition isimli bu kitaba linki tıklayarak ulaşabilirsiniz.

Bir diğeri yine koçlarımızdan Peter’ın yazdığı bir kitap.

do-better-scrum-cover-thumb  Bu kitaba da Do Better Scrum linki tıklayarak ulaşabilirsiniz.

Öğrendiklerimizi paylaşmaya özen gösterdiğimizi belirtmiştim. Bu yazımda bizim öğrenmemize katkı sağlayan bazı pratikleri  paylaşmak istedim,  umarım sizin için faydalı olmuştur.

Sürekli öğrenme de kalın,

Sevgiler,

 

Push vs Pull Konsepti Nedir?

Push vs Pull; Türkçeleştirdiğimizde itmeli ve çekmeli sistemler olarak adlandırdırırız bu konseptleri. Eğitimler, tartışmalar, toplantılar  esnasında  gündeme geldiklerinde haklarında en fazla  konuşulan konulardır;

  • Bazen yöneticiler tarafından itiraz edilirler
  • Çalışanlar tarafından işte tam da bu denir ancak bizim ortamımızda bunu uygulayabilir miyiz soru işaretleri doğururlar.

 

Bu sebeple bu konseptleri sadece teorik olarak anlatmak, dinlemek yeterli olmaz, genelde bu iki sistemi anlamak ve farklarını hissetirmek için oyunlar ve pratikleri kullanırız. Buna yönelik olarak geçen hafta Open Agile Turkey grubu olarak ücretsiz ve herkese açık olan düzenli aylık toplantılarımızdan birinde bu konseptlere yer verdik ve etkili ve eğlenceli  bir oyun olan “Aeroplane game” oyununu Eda Coşkuner ile akıtarak katılımcıların deneyimlesini sağladık.

Oyun sonrasında katılımcılar arasındaki yorumlar ve take away’ler kayıda değer ve ilgi çekiciydi. Biz oyunu agile42 olarak kendi yorumumuza göre geliştirip fasilite ediyoruz ancak oyunun orjinaline bu linkten ulaşabilirsiniz. Bu blog yazımda eğlenceli bu oyunla ilgili bazı görsel ve katılımcıların neleri deneyimlediklerini aktaracağım ancak oyun detaylarından  daha ziyade konseptlerin üzerinde durmak istiyorum. Bu oyunu bizim nasıl akıttığımızı öğrenmek ya da sizde bizimle bu oyunu oynamak isterseniz turkey@agile42.com’dan bize ulaşabilirsiniz.

oyun-1grup-tartismalari

Basit bir anlatımla “Bu işi Cuma gününe kadar bitireceksin” tarzı talimatları duyduğumuzda ve çalışanların bu talimatlarına körü körüne itaat etmesi beklendiğinde genelde  ortamda “Push” sistemin hakim olduğunu düşünebiliriz. Maksimum verime odaklı, çalışanların kendilerine tanımlanmış görevleri en kısa sürede ve en fazla görevi(taskı) bitirmesinin başarı sayıldığı bu sistemlerin temeli 1900 lü yıllarda ölçek ekonomisinin baskın olduğu üretim sistemlerine uzanır. Yetkinin ve denetlemenin sadece Yönetici de toplandığı ve çalışanların tüm zamanlarını sadece işi tamamlamaya ayırdığı bu sistemin kısa vadede iş sonuçları ve verimlilikte pozitif sonuçlar doğuruyor gibi görünse de uzu vadede sistemde

  • dengesiz akışlar
  • talep kapasite dengesizliği
  • kalite problemleri
  • çalışanların sistemi aldatma ve
  • suça başkalarına ya da birimlere atma gibi sistemsel bozukluklara sebep olmaktadır.

Bu yaklaşım ayrıca çalışan ve yöneticiyi taraflar olarak karşı karşıya getirir. Çalışan hedefin bir parçası olduğunu düşünmez, çünkü o sadece kendine söyleneni yapmakla sorumludur, hedefleri tuturmakta yöneticinin sorunu.

“Cumaya kadar bu işlerin ne kadarını bitirebileceksiniz?” sorusunu duyuyorsak ve çalışanların hedefler doğrıltusunda ellerinden gelen en iyisini yapmaya odaklandıkları ,kapasiteleri kadar işi çektikleri ve buna taahüt ettiklerini görüyorsak burada “PULL” sistemi hakimdir diyebiliriz. Kendilerine güvenildiğini ve hedefi gerçekleştirmek üzere sadece kendisine söyleneni değil, sistemin bütününü takip eden çalışanlar kollabratif hareket ederler, takım olarak başarmak için ve sisteminin dengeli şekilde akmasını engelleyen birikimler , tıkanıklarını çözmek için iletişimi artırırlar, yaratcı çözümler bulmaya çalışırlar. Kendi kendine organize olarak kendisine denetlerler ve değişimlere daha kolay adapte olurlar.

push-vs-pull2

Bu konularla ilgili söylenebilecek çok fazla şey var, Multitasking, Motivasyon , WIP limitleri , Toplam kalite, Değer vbg ancak şu ana kadar bahsettiklerimin kısaca özetlediği kananatimdeyim.

Kendi kendini örgütleme, çalışanların yapabilecekleri kadar işi çekmelerini olanaklı hale getirme ilk başta bazen bazı yöneticiler tarafından çekimser yada itirazla karşılaşılaşabiliyor. Ama ben şunu da çok gördüm; bu konuların üstünden geçip, altında yatan temelleri konuştuğumuzda,Kendi kendine örgütlemenin sadece çalışanların kendi istedikleri şeyleri yapmak değil, bir yön ve kısıtlar dahilinde çalışanların insiyatif alabilmesi, karar alabilmesi olduğunu konuştuğumuda  ve iki sistemi karşılaştırdığımızda genelde PULL ssteminin PUSH sistemine göre daha iyi iş sonuçlarını çıkardığını , oyunla bile olsa deneyimlediklerinde önce şaşırdıklarını sonra da kendi ortamlarını sorgulayıp değişime nasıl başlayacaklarını çokça gördüm bunu Open Agile Turkey toplantımızda da bir kere daha deneyimledik. Bu konular sadece duygusal yada insani boyutta sistemlere değer katmayıp somut iş sonuçları olarakta kendini gösterir.

oyun-results

PULL sistemlerinde

  • Thruput dediğimiz birim zamanda üretilen iş çıktısı miktarının arttığı
  • Ortalama üretim süresi ( Lead time)nin düştüğü
  • Değişen gereksinime cevap verebilme hızının  arttığı ve
  • Sistemdeki gereksiz aktivitelerin azaldığı , sürecin İsrafları azaltmak üzere geliştiği görülmüştür.

Bu yazımda Agile Bakış açısının temellerinden biri olan Push yada Pull konseptini kısaca aktarmak istedim. PULL yoksa, hatalardan öğrenip gelişme yoksa Agile’ın varlığından söz etmek çok mümkün değildir. Sadece yazılım değil, sadece Agile değil tüm çalışma şekillerine ve domainlere uygulanabilir.

Bir sonraki yazıda görüşmek üzere, çevik kalın…

Etkili Retrospektifler için Öneriler ve Bazı Araçlar

 

img_4515

Daha önceki blog yazımda Agile süreçleri ve takımlarının olmazsa olmazı yani sürekli iyileşme ve öğrenmeyi sağlamak için Agile Retrospektifleri yapmamız ve karar verilen aksiyonları hayata geçirmemiz gerektiğini paylaşmıştım.  Retrospektifleri sadece Scrum etkinliklerinden biri olarak değil takımımızın gelişmesine  yönelk hem işleyişimiz hem de takım içi davranışlarımızı objektif  verilerle değerlendirdiğimiz bir fırsat olarak düşünmek en doğrusu. Retrospektiflerin bu amaca hizmet edebilmesi için retrospektif fasilitatörünün  toplantıya herkesin katılımını sağlayacak, verileri toplayacak, karar alınmasını sağlayacak bir toplantı akışını önceden hazırlaması önemlidir. Retrospektifler sadece Scrum değil, Kanban veya hangi çerçevede çalışıyorsak düzenli yaptığımızda muhakkak faydasını göreceğimiz  denetleme ve geliştirme etkinlikleridir.

Bu sebeple bu yazımda Scrummasterlera ve Agile Koçlarına etkili retrospektifleri fasilite edebilmeleri için  bazı öneri ve bir kaç etkili aracı paylaşacağım. Bu araçlar için daha fazlasına Ben Linders ve Diane Larsen’in kitaplarından ulaşabilirsiniz.

Bazı Öneriler;

  • Retrospektif toplantısının iyi bir şekilde fasilite etmek için ve sonucunda takımın işine yarayacak aksiyonları taahüt edebilmesi için 5 aşamada toplantının akıtılması önerilir. Özellikle yeni bir Scrummastersanız bu akışı kullanmanız ve öncesinde bu akışı sağlayacak aktiviteleri düşünmeniz iyi olacaktır.
  1. Tüm katılımcıları toplantıya ısındırmak ve hazırlamak için bir giriş
  2. İyileştirilmesi gereken konu üstünde tüm veri ve bilginin paylaşılması
  3. Bu veriler ışığında fikirler ve önerilerin geliştirilmesi
  4. Geliştirilen fikirlerin değerlendirilmesi ve kararların alınması
  5. Taahütün verilmesi ve toplantının kapatılması
  • Toplantıda tüm katılımcıların konuşabilmesini sağlamak, sadece sesi yüksek çıkanların değil herkesin katılımını teşvik etmeyi sağlamanız.
  • Takımın kendi krarlarını almasını sağlamak, kısıtlar dahilinde kendi kendine yönetebileceği ve taahüt edebileceği çıktılara ulaşmasını desteklemeniz.
  • Ve en önemlisi Retrospektif fasilitatörü olarak en büyük sorumluluğumuz doğru cevapları vermek değil, fikir üretmeye ve akışı düzgün bir şekilde akıtabilecek doğru soruları sormak olduğunu hatırlamanız.

Bazı Araçlar;

Starfish/ Denizyıldızı

Tanım: Retrospektif toplantılarında sorulan 3 sorunun( iyi gidenler/gelişmesi gerekenler/kötü gidenler) geliştirildiği bir yöntemdir.

Beklenen Fayda: Takımın fırsat ve problemleri tanımlayabilmesini sağlar. Bu sayede takımdaki üyeler toplam resimde nelerin iyi gittiğini, nelerin geliştirilmesi gerektiği ve başarısızlıkları daha net görebilir.

Ne zaman Kullanılır?

Takımın olgunluk seviyesinden bağımsız her takım ve her türlü durum için uygulanabilir. İterasyon gözden geçirilirken olumlu aksiyonlar ile daha az etkisi olan aksiyonların net bir şekilde takımın farkına varması sağlanır.

Kullanılacak Araç: Flipchart, post it

Zaman: 45 dk

Nasıl Yapılır?

 

  1. Beyaz tahta yada flipcharta aşağıdaki resimdeki gibi bir daire çizilir ve daire 5’e bölünür. Alanlar aşağıdaki gibi kategorilere ayrılır;

star-fish-retrospective

  • Durdur
  • Daha Az
  • Koru
  • Daha Fazla
  • Başla
  1. Takımlara iterasyondaki deneyimlerine istinaden 5 dk lık beyin fırtınası seansı başlat. Düşüncelerini flipcharta post it ile yapıştırmalarını iste.
  2. Durdur kategori alanından başlayarak saat yönünün tersine doğru ilerle.
  3. Takımdaki her bir bireyin 3 dk süre içerisinde ilgili alandaki konuları okumalarını iste.
  4. 5 dk zaman kısıtlı süre içerisinde takımdaki üyelerin ilgili alanda alacakları aksiyonlar konusunda hemfikir olmasını sağla.
  5. Her bir bölüm için aynı süreci çalıştır.
  6. Başla kategorisi için takım için önemli olan bir alanda odaklanarak aksiyonların belirlenebileceği ekstra bir adım koyabilirsin.

Sonuçta şöyle bir çıktınız olacak, bu dairedeki aksiyon listesinden bir sonraki Sprint için yapmayı taahüt edilenler belirlenerek ilerlenir.

243077f

Yelkenli

Tanım: Takımla yelkenli arasında benzetme yaparak takıma amaçları, engelleri, başarılı pratikleri, riskleri adreslemeye ve aksiyon almaya yönelik ilginç ve basit bir araçtır.

Beklenen Fayda: Bu çalışma ile takımın vizyonu tanımlanamasını, amaçlarına ulaşmak için onları engelleyen ve onlara güç katan faktörleri belirleyerek aksiyon almalarını sağlanır.

Ne zaman Kullanılır?

Basit bir tekniktir, herhangi bir olgunluk seviyesindeki takıma uygulanabilir. Aynı ürün kapsamı üzerinde 1 den fazla çalışan takım varsa ortak çalışmalarını desteklemek ve takımları ortak ürün kapsamı etrafında birleştirmek için de kullanılabilir.

Takım içindeki bireyleri aynı geminin içindeyiz argümanıyla ortak hareket etme duygusunu ve iradesini pekiştirmek için kullanılabilir.

Kullanılacak Araç: Flipchart, beyaz tahta, tahta kalemi, renkli post itler

Zaman: 50-60 dk

Nasıl uygulanır?

  1. Denizin üstünde bir yelkenli resmedin. Resim üstüne geminin varacağı adalar, denizin altında kayalar, bulutlar, rüzgar ekleyin.

photo

 

  • Adalar takımın her gün uğraştığı ve varmaya çalıştıkları ana hedefi temsil eder.
  • Deniz içerisindeki kayalar takımın hedef giderken karşılaşılacak riskleri temsil eder.
  • Yelkenlinin çapası takımı yavaşlatan faktörleri temsil eder.
  • Bulut ve rüzgar yelkenin hedefe ulaşmasını destekleyen ve güç katan unsurları temsil eder.

Takıma bu benzetmeler ile ilgili bilgi ver.

  1. Takımın vizyon ve hedefini belirtmelerini iste ve büyük harflerle tahtaya yaz.
  2. 10 dk zaman içinde takıma yukarıdaki unsurlar dahilinde her alan için düşüncelerini post itlere yazmalarını iste.
  3. Her bir kişiye 5 er dk vererek fikirlerini diğerleriyle yüksek sesle sırayla paylaşmalarını talep et.
  4. Bu aşamada takıma bulut ve rüzgarın temsil ettiği, takıma güç veren iyi pratikleri nasıl koruyacakları ile ilgili tartışmalarını iste. Zaman: 5 dk
  5. Daha sonra riskleri nasıl minimize edecekleri ve baş edebileceklerini tartışmalarını iste. Zaman: 5 dk

Tek Kelime Oyunu

Tanım: Bu teknik takıma takım içi davranışlar ve duyguları ele alması için yardımcı olur. Son iterasyon ve takım içi davranışlar ile ilgili bir kelime ile özetleyerek durumu gözlemleme ve buna yönelik aksiyon almak üzere takımı hareket ettirmeye yarar.

Beklenen Fayda: Takım içinde saygı ve işbirliğinin gelişmesi için takımdaki kişilerin duyguları ve takımın performansını etkileyen olumsuzlukları tartışılabildiği bir tekniktir. Takım üyelerinin duygularını iyi bir şekilde ifade etmesine ve sorunlu çözülmesi için adımları belirlemesini sağlar.

Ne zaman Kullanılır?

Takım içinde hassas durumlar oluştuğu zamanlarda bu teknik kullanılır. Aynı zamanda takımdaki üyelerin retrospektif toplantısına hazır olup olmadığını kontrol etmek için de kullanılması iyi olabilir. Eğer bu uygulamada takımın sorunlu konuları ortaya çıkarsa retrospektifin gidişatı bu bulgulara göre ilerler.

Kullanılacak Araçlar: Flipchart

Zaman: 45 dk

Nasıl uygulanır?

  1. Tüm takım üyelerine son iterasyonla ilgili duygularını ifade etmeleri için 1 kelime söylemelerini iste.
  2. Her kelimeyi yüksek sesle tekrarla ve flipchartta herkes tarafından görülecek şekilde yaz.
  3. Böyle düşünmelerinin nedenini sor.
  4. Takım üyelerinin ifade ve kelimelerini kullanarak tartışmalarını sağla.
  5. Takım üyelerinin mutabık kaldığı konuları, meseleleri listele.
  6. Takımın anlaşmaya vardığından emin ol ve gelecek iterasyonda sorunları çözümlemek içinalacakları aksiyonları iste.

Bu çalışmayı yaparken;

  • Bu tekniğin iyi bir şekilde yönetilmesi için takımda konuların tartışılabileceği açık, şeffaf , güvenli bir ortam oluştuğundan emin ol.
  • Tüm takım üyelerinin görüş ve duygularına saygı duyulduğundan emin ol.
  • Bu çalışmanın sonunda takım üyelerinin kendilerinin dinlendiğinden ve sorunlarına çözüm bulunduğundan emin olarak ayrılmalarını sağla.
  • Duyguların ortaya dökülmesi riskli bir süreç olduğundan konuların ortada kalmadan netleştirilmiş olmasına dikkat et.

Bu yazımda etkili retrospektifler için bazı öneriler ve araçları paylaştım. Bu konuda daha detaylı bilgi almak ve diğer araçlar için turkey@agile42.com üzerinden bizimle iletişime geçebilirsiniz.

Product Owner Rolü ( PO) ve Bazı İpuçları

Scrum çerçevesindeki 3 rolden birisi Product Owner, çoğu yerde kısaltma olarak kullanıldığı üzere PO. 

po

Bir Scrum takımnda doğru ürünü geliştirmek için uzmanlık ve yetkinlikleri yeterli bir Geliştirme takımının var olması elzem. Bir o kadar elzem olan da doğru kişinin Product Owner olması. Yeni bir takım kurulurken genellikle organizasyonla birlikte yaptığımız önemli çalışmalar arasında

  • Üzerinde çalışılacak ürün/servise göre doğru kişiyi PO olarak seçmek konusunda destek olmak
  • PO’ın Geliştirme takımını doğru yönlendirebilmesi , paydaş ve müşteri beklentilerini yönetebilmesi ve en karlı ve değerli işlerin yapılması için Product Backlogu güncel ve yaşar tutması için yeni yetkinlik ve teknikleri kazandırmak oluyor.

Bunun için PO’ın 3 anahtar özelliğe sahip olması gerekiyor; konu uzmanlığı, karar verebilme yetkisi ve çok önemli olan ve çoğu zaman organizasyon tarafından gözardı edilebilen zaman. Zaman önemli çünkü PO hem geliştirme takımıyla vakit geçirebilmeli(sadece Sprint planlama ve review’a katılmak yeterli değil) hem de Paydaş, sponsorlarla vakit geçirebilmeli. Karar verebilmesi önemli, takıma hız ve çeviklik kazandıran en önemli unsurlardan birisi takımı klasik organizasyondaki hiyerarşiyi, karar mekanizmalarını beklemeden PO’dan yanıtlarını alabilmesi ve geliştirmeye devam edebilmesi. Konu uzmanlığı da en değerli işleri ve neyin yapılabilip yapılamayacağı konusunda öngörüsünün olması ve böylece backlog yönetimini en iyi şekilde yapabilmesini sağlıyor.

po-chara

Bana göre 3 önemli özelliğe ek bir konu daha var ;PO’luk rolü ve Scrum’daki diğer 2 rol yani ScrumMaster ve Geliştirme takımı eşlenik seviyelerde roller yani PO, Geliştirme takımının üstü değil, Scrum takımındaki aynı seviyedeki rollerden biri. Dolayısıyla PO olacak kişinin PUSH tarzında olmayan,takımın yöneticisi tarzında çalıştığını düşünen bir kişi de olmaması gerekiyor.

İşte bütün bu özellikleri taşıyabilen birisinin PO rolünü üstlenmesi iyi olacaktır.

Product Ownerlar Geliştirme takımı Sprinte başlamadan çok önce ürün/servis vizyonundan başlayarak Product Backloga doğru işleri almak, sıralamak için çalışmaya başlarlar. İster yeni ürün geliştirilsin, ister mevcut üründe geliştirme yapılsın ,pazar araştırması sonuçlarını incelemek, son kullanıcı deneyim beklentisini, sponsor beklentilerini anlamak ve Şirketin vizyonuyla uyumlu ve ekibe motive güzel bir ürün/servis vizyonu hazırlamak başlangıçta yaptıkları işler arasındadır. O yüzden sadece Sprint review ve planlama toplantılarına katılırım diye düşünülüyorsa PO’lar  görevlerini eksik yapmış olurlar.

Agile Product Ownerlık rolünü yakından tanımak için size tavsiye edebileceğim Henrik Kniberg’ten kısa bir  videoyu  izlemenizi tavsiye ederim.

Ben kendim PO’luk yaptığım zamanda ya da yeni PO olan kişilere önerdiğim ve etkin olduğunu düşündüğüm bir araç var ; Kendileri için özelleştirebilecekleri  ve kendilerin kontrol edebilecekleri bir check list. Bu yeni yetenek ve sorumluluklarımızı  otomatik olarak düşünmeden alışkanlık haline getirinceye değin ya da sonrasında da atlamamak için kullanabilecekleri, ihtiyaca ve deneyime göre güncelleyecekleri bir liste.

Unutmayalım check listleri kullanmaktaki amacımız raporlama yapmak değil, gelişigüzel , kullanmayacağımız, israf olacak döküman doldurmak değil, bunu kendimizi denetlemek ve gelişim aracı olarak kullanmamız.:)

PO’luk zor iş ve zamanla kendini geliştiren kişilerle çalışma fırsatım oldu. Dolayısıyla PO’lukla ilgili söylenebilecek çok fazla şey olmakla birlikte bu yazımda bu check listle ilgili bir kaç öneri ve kaynak paylaşacağım. İhtiyaca yönelik istediğinizi kullanmak , kendinize göre adapte etmek PO’larımızın elinizde.

Henrik Knibergle başlamışken onun diyagram şeklindeki check listi bu örneklerden birisi. Henrik Kniberg linkinden bu check liste ulaşabilirsiniz.

Product ownerla ilgili okuduğum ve tavsiye edeceğim kaynaklardan birisi de Roman Pichler.  Bu kitabı severek ve rahat okuduğum bir kitap olarak tavsiye edebilirim.

 

Pichler_MECH.qxd

Yine Roman Pichler’den örnek olarak hazırlanmış bir check listede  Roman Pichler check list bu linki tıklayarak ulaşabilirsiniz.

Bir diğer tavsiye edebileceğim kaynak ise Robert Gallen’ın Scrum Product Ownership Kitabı. Sorularınız olduğunda konu başlıklarına dönüp bakabileceğiniz bir kitap.

 

po-book

Elbette User story konusunda Mike Kohn’un kitaplarınıda unutmamak lazım.

Son olarak paylaşabileceğim  Lare Ekman tarafından tarafından oluşturulmuş ve aşağıda görebileceğiniz üzere Türkçeye çevrilmiş olan bir check list. Burada herbir madde için kendinize puan verebilir ve sonuçta sorumluluklar listesinde kaç üstünden kaçı tamamlayabildiğinizi, kendinizi geliştirmek için odaklanacağınız alanları seçebilirsiniz.

Lare Ekman Check list

Ürün Vizyonu

  • Müşteri, son kullanıcılarla beraber oluşturulmuş bir ürün vizyonuna sahibim.
  • Ürün vizyonu hakkında soruların soruları net, özlü ve motive edici biçimde yanıtlayabiliyorum.
  • Ürün vizyonunun basit, doğru şekilde anlaşılmasına yarayan ve releaselerimin değerini vurgulayan ilgi çekici bir anahtar iletişim söylemim var. Örneğin ‘’cebinizde 1000 şarkı’’(ıpod 2011)

Paydaşlar

  • Müşteri, son kullanıcı ve paydaşlarımın ihtiyaçlarını anlıyorum.
  • Paydaşların ihtiyaçlarını anlamak ve taleplerini yönetmek için onlarla düzenli iletişim halindeyim.
  • Paydaşlar tarafından yetkilendirildiğime ve bana güvenin tam olduğuna eminim ve Ürün sahibi olarak çalışmaktan dolayı motiveyim.
  • Takımımın hızı ve çıktı performansı doğrultusunda paydaşlarıma taahhütte bulunurum.

Ürün Kapsamı

  • Paydaşlar ve tüm takımın rahat bir şekilde ulaşabildiği, net ve açık ifadelerle düzenlenmiş bir ürün kapsamım var.
  • Ürün kapsamı hakkında karar verme yetkisi bana ait.
  • Ürün kapsamını en azından her Sprint planlama toplantısı öncesinde düzenli olarak güncelliyorum.
  • Ürün kapsamındaki maddeleri değer, bağımlılık, riski gözeterek doğru şekilde sıralıyor ve önceliklendiriyorum.
  • Ürün kapsamındaki maddeler net bir şekilde açıklanmış ve yakın sprintlerde alınacak işler takım tarafından rahatlıkla anlaşılacak detayda düzenliyorum
  • Takımla birlikte düzenli şekilde ürün kapsamı yenileme seansı yapıyoruz.

Değer

  • Takımla beraber yarattığımız değeri ölçümlemek için doğru şekilde set edilmiş KPI larımız var.( sadece hız değil, kalite, technical debt gibi birçok boyutu ele alan)
  • İşlerin fayda anlamında getirisini en yüksek seviyeye çekmek, hızlı ve erken teslimatı sağlarken kaliteli işler çıkması sağlamak için takımla beraber tanımlamdığımız BİTTİ tanımı ve ürün kapsamındaki her iş tanımı için Sprint kapsamı öncesinde çalıştığımız kabul kriteri var.
  • BİTTİ kriteri daha kaliteli sonuç üretmek ve yetkinliğimiz geliştirmek için zaman içinde gelişme gösterir.
  • Çevik ürün/ servis geliştirme sürecini sürekli iyileştirerek değeri optimize etmek için uygula-ölç-öğren döngüsünde çalışıyorum.

Takım

  • Takımın bana rahatlıkla ve her an ulaşabilir.
  • Ürün kapsamında nihai söz yetkisi bana ait ve takımıma ürün kapsamı dışında farklı yerlerden iş talebi ulaşmamakta, tüm paydaşlar taleplerini bana ileterek ürün kapsamı tarafından yönetilmektedir.
  • Takımımım geliştirme yetkinliğine güveniyorum.
  • Ürün kapsamının erken, kaliteli ve hızlı teslimatı için takımda yeterli yetkinlik olmaması halinde eğitim, doğru takımla çalışma gibi gereken aksiyonları alırım.
  • Ürün kapsamındaki işlerle ilgili tahminlemeyi takım yapar.
  • Önceliklendirilmiş ürün kapsamından Sprint kapsamına alınacak işleri takımım seçer, onlara iş atamam.

Scrum Master

  • Takımın ve benim güvendiğimiz ve inandığımız bir Scrum Masterımız var.
  • Scrum Masterla uyumlu bir işbirliğimiz var.

Scrum Aktiviteleri

  • Sprint planlama toplantılarına katılırım,   takım tarafından ürün kapsamının net anlaşılması için gerekli açıklamaları veririm.
  • Sadece Sprint değerlendirme toplantısında değil Sprint boyunca takımla beraber çalışarak gelişime yönelik geribildirim veririm.
  • Sprint değerlendirme toplantısında paydaşlarımıza takımla beraber çıkarttığımız ürün parçasının üstünde gözlem yapıp geribildirim alırız, Sprint değerlendirme toplantılarına paydaşların katılımını sağlarım.
  • Sprint kapsamındaki işlerin BİTTİ ve kabul kriterlerine uygun olacak şekilde ürün parçasına dönüşmesini teyit ederim.
  • Süreç gözden geçirme toplantılarına katılarak takımımdan geribildirim alır, ürün sahibi olarak işimi gözlemleyip geliştirmek üzere aksiyon alırım.
  • Scrum’ın değerlerini biliyor ve bunları uyguladığıma taahhüt ediyorum.( Taahhüt, odak, açıklık, cesaret, saygı)

Toplam skor :31                 Gerçekleşen:(kişisel skorum)

Deneyimlerime göre PO Scrum çerçevesinde yer alan bir rol olarak bilinmekle birlikte doğru ürün/hizmet geliştirmek için yöntem ve çerçeveden bağımsız başarıyı destekleyen en kritik rollerden biri. Bu yazıda bir nebze olsun bunu hissettirmek istedim, sonraki yazılarda diğer roller ve ipuçları devam edecek.

Görüşmek üzere,

 

 

9. Uluslararası Bilgi Güvenliği ve Kriptoloji Konferansı

ODTÜ EEE mezunu, yüksek lisanslı telekom mühendisi, Agile tutkunu. Bir ara 'Alamancı', şimdi Türkiyeli, voleybolda smaçör ve acemi sörfçü. ~~ METU EEE Alumni, MSc. Telecomm. Engineer, Agilist. Long-term expat in Germany, now back to TR; wing spiker & amateur surfer.

ISC Turkey 2016

ISC Turkey 2016

Türkiye’de ve dünyada bilgi güvenliği ne durumda? Internet ortamında paylaşılan verilerin güvenliği, mahremiyetin korunması ve güvenli iletişim teknolojilerine dair yenilikler nelerdir?  Kişi ya da kurum olarak, bilgi güvenliğini sağlamak için neler yapabiliriz? Bu ve benzeri sorulara yanıt arayan, konuya ilgili ve alanında uzman kişilerin bir araya geldiği “Uluslararası Bilgi Güvenliği ve Kriptoloji Konferansı” ISC Turkey 2016, geçtiğimiz hafta Ankara’da gerçekleşti.

Katılan Firmalardan Türk Telekom

Katılan Firmalardan Türk Telekom

Bilgi Güvenliği Derneği’nin (BGD), Ulaştırma Bakanlığı’nın ve ODTÜ gibi üniversitelerin katkılarıyla bu yıl dokuzuncusu düzenlenen konferansta, Havelsan ve ASELSAN gibi kuruluşların yanında, halihazırda agile ekipleri bulunan ve agile çalışma modelini uygulamakta olan NETAŞ, Türk Telekom, Vodafone dahil pek çok firma da yer aldı. Avrupa Siber Güvenlik Ayı etkinlikleri arasında olan bu konferans, Avrupa Ağ ve Bilgi güvenliği Ajansı (ENISA) tarafından destekleniyor.

Gerek katılımcıları, gerekse içeriği ile oldukça ilgi gören, ve bilim insanları, araştırmacılar ve uygulayıcılar arasında bilgi alışverişinin sağlandığı en önemli etkinlik olarak kabul edilen bu konferansa, agile42 Türkiye‘yi temsilen ben de katıldım. Bu yazıda, sizlerle izlenimlerimi paylaşacağım.

ODTÜ - Bilim Ağacı

ODTÜ – Bilim Ağacı

ODTÜ Kültür & Kongre Merkezi’nde gerçekleşen, ve bu yılki ana teması “Siber Güvenlik ve Nesnelerin Interneti” olan iki günlük konferansın açılışı, BGD Yönetim Kurulu Başkanı ve Havelsan genel müdürü sayın Ahmet Hamdi ATALAY tarafından yapıldı.

2016 Ana Teması: Siber Güvenlik ve Nesnelerin Interneti

ISC 2016 Ana Teması: Siber Güvenlik ve Nesnelerin Interneti

Yakın zamanda bir örneğine şahit olduğumuz, Türkiye de dahil tüm dünyayı etkileyen DDoS saldırılarına değinen Ahmet Bey, evimizdeki ve elimizdeki pek çok cihazın bizlerden habersiz bu ataklara alet edilebildiğinden söz ederken, “zombi” terimini kullandı.

DDoS Saldırısı

DDoS Saldırısı

Hatırlarsanız, 21 Ekim Cuma günü, botnet tabanlı olduğuna kesin gözüyle bakılan bir DDoS saldırısı nedeniyle, Amerika’nın büyük bir bölümü Internetsiz kalmıştı. Etki alanı geniş olduğu ve ‘ses getirdiği’ için olsa gerek, sıkça örnekleri görülen ve dünyaca belki en çok tanınan DDoS, bilinen siber saldırı yöntemlerinden yalnızca bir tanesi.

 

Açılış konuşmalarından sonra günün akışı, davetli konuşmacılar, poster oturumu, sözlü sunumlar ve panellerle devam etti. Çok çeşitli konuların ele alındığı salonlarda, özellikle “Sosyal Mühendislik” konusuna ilgi büyüktü.

Geçtiğimiz yıllarda binden fazla katılımcı sayısına ulaşan etkinliğin bu yılki ilk gününde, bir diğer dikkat çeken nokta ise, öğrencilerin yoğun ilgisiydi. Kimi salonlarda oturumları dinlerken, kimiyse firma standlarında bilgi alıyordu. “Bizler de buradayız” diyerek grup resmini paylaşanlar da vardı:

Bilgi güvenliği ve bilişim sektöründen firmaların katılımı, uzman kişilerden sunumlar ve etkileşimli öğrenme fırsatı sunan eğitim seanslarıyla yoğun ilgi gören konferansta, ikinci gün ise daha çok “IoT ve Kişisel Güvenlik”, “Veri Mahremiyeti”, “Kriptografik Protokoller”
gibi konulara yer verilmişti.
(Etkinlikle ilgili tüm Tweet’ler için: )

Dileyenin ücretsiz siber güvenlik eğitimleri alabildiği, yabancı konuşmacıların da davetli olduğu ikinci günde benim en çok ilgimi çekenlerden biri, Dr. Vladimir Soukharev’in “Post-Quantum Elliptic Curve Cryptography” konulu sunumu oldu.
Post-Quantum Cryptography

Post-Quantum Cryptography

Telekomünikasyon yüksek lisansı yaptığım RWTH Aachen‘da, “Elliptic Curve Cryptography”, master tezimin konusuydu. Yıllar sonra bu konudaki gelişmeleri uzmanından dinlemek; olası quantum bilgisayar tabanlı saldırılara karşı ileri kriptografik metodlarla önlem alarak, hazırlıklı olabileceğimizi öğrenmek güzeldi.
Eski okulum ODTÜ’ye gelmişken, Hocam Piknik’e uğramamak da olmazdı elbette : )
Bir ODTÜ Klasiği - Hocam Piknik

Bir ODTÜ Klasiği – Hocam Piknik

Gerek firmalar, gerekse katılımcılar için oldukça etkin ve verimli geçen, katılımcıların iletişim aralarında aktif diyalog kurma şansı bulduğu bu konferansın, bir sonrakini merakla bekliyor olacağım.

Benzer etkinliklerde bizlerle tanışmak ve bilgi almak için, turkey@agile42.com adresinden iletişime geçebilir, sosyal medya hesaplarımızı takip edebilirsiniz:

   

Görüşmek dileğiyle!

~ Eda COŞKUNER ~

Agile-Scrum Mini Teste Hazır mısınız?

 

scrum-gorsel

Agile ve Scrum özelindeki sizin ve takım arkadaşlarınızın bilgisini ve kendinizi test etmek ister misiniz? İşte size bunun için minik bir egzersiz. Aşağıdaki çoktan seçmeli soruları yanıtlayın, cevap anahtarı aşağıda, kopya çekebilirsiniz, kopya çekmekte öğrenmenin bir başka yolu:)

Unutmayın “açıklık” Scrum’ın 5 temel değerinde biri, nerede olduğumuzun farkında olarak daha iyisini hedeflemesi kendi elimizde.  Scrum öğrenmesi kolay, kuralları net olmakla birlikte uzmanlaşması zor bir çerçevedir, çoğu zaman teoride bildiğimizi iş ortamımıza yansıtmakta güçlük yaşayabiliriz ama neyi referans olarak alacağımızı ve çerçevenin detaylarını doğru bilmek, ne kadar bildiğimizin farkına varmak iyi bir başlangıç noktası.

Bu sorulara katkıda bulunmak isteyebilir siniz, ya da sorular hakkında daha detaylı bilgi almak isterseniz turkey@agile42.com adresinden bize ulaşabilirsiniz.

 

Testte başarılar…

S1) Bir sprint’in uzunluğunun üst limiti nedir?

timebox

a)1 hafta

b)1 ay

c)2 ay

d)3 ay

S 2) Hangisi Scrum Kılavuzuna göre Scrum’ın 5 Temel Değerinden biri değildir?

a)Cesaret

b) Açıklık

c) Taahhüt

 d) Kendi kendine organize olma

S 3) Aşağıdakilerden hangisi Çevik BİLDİRİNİN temelindeki 12 ilkeden biri değildir?

a) Çalışan yazılım ilerlemenin birincil öçüsüdür.

b) Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.

c) İş süreçlerinin sahipleri ve yazılımcılar proje boyunca ihtiyaç duyulduğunda birlikte çalışmalıdırlar.

d) Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.

S4 ) Scrum’daki Deneysel (Ampirik) Süreçlerin dayandığı üç temel bacak nedir?

a) Şeffaflık, Disiplin ve Adaptasyon

b) Takım için güven, Gözlem ve Dürüstlük

c) Şeffaflık, Denetleme ve Adaptasyon  

d) Disiplin,Denetleme ve Adaptasyon

S5 ) ‘Günlük Scrum’ toplantıları neden aynı saatte ve aynı yerde yapılır?

standup2

 

a) Toplantı salonlarının rezerve edilmesi zor olduğu için

b) Tutarlılık karmaşıklığı azalttığı için

c) Ürün sahibi öyle talep ettiği için

d) ScrumMaster öyle karar verdiği için

 

S6 ) Hangisi Scrum Master’ın sorumlulukları arasında yer almaz?

 

a) Ürün sahibine koçluk yapmak

b) Takımın kendi kendine çözemediği engelleri ortadan kaldırmak

c) Takımı her sabah Daily Stand up toplantısına çağırmak

d) Takımın Scrum’ı doğru bir şekilde uyguladığından emin olmak

 

S7)  Hangisi Agile Manifesto içerisinde yer almaz?

a) Süreçler ve araçlardan ziyade bireyler ve etkileşimler daha önemlidir.

 b)  Kapsamlı dökümantasyondan ziyade çalışan yazılım daha önemlidir.

  c)   Müşteri ile işbirliğinden ziyade sözleşme pazarlığı daha  önemlidir.

  d)   Bir plana bağlı kalmaktan ziyade değişime karşılık vermek daha önemlidir

S8) ‘Ürün kapsamı’ ile ilgili olarak aşağıdakilerden hangisi yanlıştır?

product-backlog

 

a) Gereksinimlerin yer aldığı öncelikli iş listesidir.

b) Geliştirme takımı tarafından yönetilir.

c) Aynı ürün üzerinde yapılacak geliştirmeler için birden fazla Scrum takımı çalışabilir ve gruplandırarak tek ürün listesi üzerinde takip edebilirler.

d) Net bir şekilde ifade edilmesi gerekir.

 

S9) Hangisi Retrospektif toplantısıyla ilgili doğru değildir?

a) Ayda 1 yapılır.

b) Tüm Scrum takımı katılır.

c) Son Sprintin süreç, araçlar, insanlar ve ilişkiler açısından nasıl geçtiğini gözlemlemek için yapılır.

d) Scrum takımı  işyapış tarzını iyileştirecek bir plan oluşturur.

S10) Aşağıdaki gruplardan hangisi Scrum Kılavuzuna göre doğru unsurları içeren bir gruptur?

a) Daily Stand up, Proje Yöneticisi, Sprint Backlog,  ScrumMaster

b) Sprint Review, Product Owner, Geliştirme takımı, Proje planı

c) Bitti tanımı, Retrospektif, Scrum Takımı

d) Yarı Sprint Değerlendirme toplantısı, ürün parçası, Backlog yenileme

Mini testimiz bitti, geçmiş olsun:)

Scrum kılavuzunun orjinaline buradan ulaşaiblirsiniz.

Agile ve Scrum’a dair daha detaylı okuma içinde Güney Afrika’dan deneyimli CST arkadaşım Peter’ın kitabına linki tıklayarak ulaşabilirsiniz.

Cevaplarınızı kontrol etmek için sabırsızlanıyor musunuz ? İşte size cevap anahtarı;

1 b, 2 d , 3 c, 4 c, 5 b, 6 c, 7 c , 8 b, 9 a, 10 c

Eğlenceli mini egzersizlerimizin devamı gelecek, farklı sorular ya da bu sorular hakkında daha detaylı bilgi almak isterseniz turkey@agile42.com’dan bize ulaşın.