Agile Yolculuğunda Yapılan Ortak Yanlışlar

Yazarımız Osman Sönmez'in tecrübelerini paylaştığı yazı sonrası, Türkiye'de bir çok kurumun/organizasyonun, Agile dönüşüm sürecinde yapmakta olduğu ortak yanlışları sizlerle paylaşmak istedim.
 
Öncelikle Agile dönüşüm sürecinin, uzun ve yorucu bir yolculuk olduğunu belirtmem gerekir. Bu yolculuk sırasında inişler, çıkışlar olabilir. Bu nedenle başlangıçta bu tip durumlar için hazırlıklı olmak gereklidir.

Yanlış Metodoloji Seçimi
Genellikle kurumlar ve organizasyonlar Agile dönüşüm sürecine, kullanılması planlanan metodolojinin eğitimlerini tamamlayarak başlamaktadırlar. Eğitimler sonrasında, farklı stratejiler kullanılarak, bu metodolojinin uygulamasına geçilmektedir. Ancak burada seçilen metodolojinin kurum kültürüne, iş yapma şekline, takım yapılarına vb. uygun olup olmadığı değerlendirilmeden, sadece popüler olduğu için kullanılması durumu ile karşılaşabiliyoruz. Dolayısı ile bu tür durumlarda başarısız sonuçlar ortaya çıkabilmektedir. Eğitim verdiğim kurumlara, öncelikle tüm metodolojilerin mümkün olan en üst seviyede incelenmesini ve kurum kültürüne en çok uyan metodolojiyi seçmelerini özellikle öneriyorum.
 
 
Sürece Çok Fazla Odaklanılması
Türkiye'de, Agile uygulayan organizasyonlara baktığımızda genellikle Scrum metodolojisinin kullanıldığını görüyoruz. Scrum'ın bir çoğunuzun bildiği gibi belirli kuralları bulunmaktadır. Bu kuralları sağladığı faydalara göre değerlendirmektense, sadece yapmış olmak için uygulamak yapılan en büyük yanlıştır. Bu durumda iş birimleri, yönetim ve diğer paydaşlar, takımların üründen daha çok sürece odaklandığını düşünmeye başlar ve bu durum kırılmak istenen mevcut bürokrasinin, farklı bir şekilde karşımıza çıkmasına neden olur.
 
 
Takım Hızını Arttırmaya Odaklanmak
Üretim metodolojileri, genellikle verimliliğe odaklanır. Bu yaklaşım geleneksel yazılım geliştirme metodolojilerinde de görülür. Ancak buna karşılık olarak bütün Agile metodolojiler, verimlilikten daha çok etkililiğe odaklanmaktadır. Daha fazla ürün ortaya çıkarmaktansa, müşterimize değer katan ürün ortaya çıkarmayı amaçlar. Verimliliğe odaklanma olduğu durumda, yöneticiler takımların hızlarını arttırmaya çalışırlar ve bu nedenle de etkililik azalır. Başlangıçta takımların kullanılan metodolojiye uyum sağlamasını destekleyici bir ortam oluşturulmalı ve belli bir süre az ürün çıktısı sağlanabileceği göz önünde bulundurulmalıdır.
 
 
Scrum Çerçevesinin Yeterli Olduğunu Düşünmek
Scrum çerçevesi, bildiğiniz gibi herhangi bir mühendislik pratiğini zorunlu kılmaz. Takımlar, Scrum çerçevesinin içeriğini kendileri doldurur ve uygulanacak pratikleri kendileri belirler. Ancak dünyadaki örnekleri incelediğimizde, Scrum çerçevesini tek başına kullanmak Agile olmak için yeterli değildir. Scrum'ın yaratıcısı Jeff Sutherland, eğitimlerinde de bu konuya özellikle değinmektedir. Scrum, Agile dönüşüm için tek başına yeterli olmayabilir. Özellikle XP Programlama pratiklerini Scrum ile birlikte kullanmak, Agile dönüşümün daha sağlıklı ve başarılı olması konusunda yardımcı olmaktadır.
* Bu yazıda kullanılan resimler Henrik Kniberg'e aittir.

Yeni Yazarımız: Sevgi Korkmaz

Scrum Turkey ailesi büyümeye devam ediyor! Bizimle aynı vizyonu paylaşan yeni bir yazarımız var. Aramıza katılan en son yazarımız Sevgi Korkmaz'a hoşgeldin diyor, bizimle paylaşacağı bilgi ve deneyimleri için kendisine şimdiden teşekkür ediyoruz.
 
 
Scrum Turkey, bildiğiniz üzere herkese açık olan bir bilgi paylaşım platformu. Scrum Turkey misyonu gereği, bilgi platformu oluşturmayı en öncelikli amacı olarak belirledi. Bu amacımızı gerçekleştirmek için sizlerin katkıları bizim için çok değerli.
 
Sevgi Korkmaz
Sevgi Korkmaz is graduated from Middle East Technical University in 2002. She has 12 years of experience in software development projects, and performed many roles, as software developer, business analyist, team leader, project manager, department manager.
 
She is a Java fan and believes in open source way. Met Agile in 2010, certified as CSM in 2012. She implements agile culture and approaches (scrum, xp, kanban) in her department.

Scrum Kılavuzu Yeni Evinde!

Scrum Kılavuzunun artık yeni bir evi var: www.scrumguides.org!
 
Scrum'ın yaratıcıları Jeff Sutherland ve Ken Schwaber ile Scrum Alliance'ın Genel Müdürü Carol McEwan'ın ortak çabaları ile, Scrum'ın temel bilgilerini içeren Scrum Kılavuzu, Scrum Guides sitesine taşındı. Scrum Kılavuzu bundan sonra bu platformdan ulaşılabilir olacak. Kılavuzun içeriğinden her zaman olduğu gibi Jeff Sutherland ve Ken Schwaber sorumlu olacaklar.
 

Scrum Guides sitesinde Scrum Kılavuzunun orijinal İngilizce versiyonunun yanında, çevirisini Scrum Turkey ekibinin yapmış olduğu Türkçe dahil olmak üzere, 30+ dildeki versiyonlarına da ulaşılabiliyor. Scrum'ın kısa tarihçesine de ulaşabileceğiniz sitede, kılavuzun bir de internet versiyonu da bulunuyor.
 
 
"Scrum'ın temellerini anlatan neden bu kadar çok dağınık kaynak olduğu", düzenlediğim seminer ve eğitimlerde özellikle sorulan sorular arasındaydı. Bu çalışma artık tartışmalara son noktayı koymuş oldu. Öğrendiğimiz kadarıyla Scrum Alliance Genel Müdürü Carol McEwan, bu çalışmada çok ciddi emek harcamış. Kendisine biz de özel olarak teşekkürlerimizi iletiyoruz.
 
Konuyla ilgili yapılan basın bültenlerine de aşağıdaki bağlantlardan ulaşabilirsiniz:

Yeni Yazarımız: Osman Sönmez

Scrum Turkey, bildiğiniz üzere herkese açık olan bir bilgi paylaşım platformu. Scrum Turkey misyonu gereği, Agile bilgi platformu oluşturmayı en öncelikli amacı olarak belirledi. Bu amacımızı gerçekleştirmek için sizlerin katkıları bizim için çok değerli.
 
 
Bizimle aynı vizyonu paylaşan yeni bir yazarımız var. Kendisini konuk yazar olarak paylaştığı Yazılımda Fast Food Scrum başlıklı yazısından hatırlayacaksınızdır. Yazarımız Osman Sönmez'e hoşgeldin diyor, bizimle paylaşacağı bilgi ve deneyimleri için kendisine şimdiden teşekkür ediyoruz.
 
Osman Sönmez
İstanbul Üniversitesi Elektrik-Elektronik Mühendisliği Elektronik ve Haberleşme mezunudur. 2002
yılında yarı zamanlı olarak çalışmaya başladığı yazılım sektöründe, 2004 yılından itibaren tam zamanlı olarak çalışmaktadır. Kariyerinin ilk zamanlarında mobil oyun geliştiriciliği ve barkod sistemleri üzerinde çalıştıktan sonra, yaklaşık 9 yıldır bankacılık sektöründe yazılım mühendisi olarak çalışmaktadır.
 
Çalıştığı bankalarda İnternet Şube, Call Center, IVR, IVN, Mobil Şube gibi kanalların ilk defa oluşturulması veya yenilenmesi gibi büyük projelerde geliştirici ve ekip lideri olarak yer almıştır. Şuan Türkiye’nin büyük bir bankasının İnternet Şube ekibinde kıdemli yazılım uzmanı olarak çalışmaktadır.

Agile Leaders Etkinliği 1. Bölümü Gerçekleştirildi!

Agile Leaders etkinliğimizin 1. bölümünü gerçekleştirdik. Bu bölümdeki konuğumuz Lemi Orhan Ergin'di. Kendisine keyifli sohbeti ve katkıları için çok teşekkür ediyoruz. Kaçıranlar yayın kaydından etkinliği izleyebilirler.
 
 
Sizlerin geri bildirimleri bizim için çok önemli. Etkinlikle ilgili düşüncelerinizi, etkinlikte görmek istediğiniz konukları, sorularınızı bize Twitter üzerinden #AgileLeadersST etiketiyle iletebilirsiniz.


Agile Leaders 2. bölümü 15 Ekim 2014 tarihinde olacak. Detaylarını önümüzdeki hafta yayınlayacağız. Görüşmek üzere.

PMI TR Chapter'ın Düzenlediği Proje Yönetimi Zirvesindeydik!

Project Management Institute (PMI) Türkiye Chapter'ının 19 - 20 Eylül 2014 tarihlerinde İstanbul'da düzenlediği Proje Yönetim Zirvesi gerçekleştirildi. Turkcell CEO'su Süreyya Ciliv'in de konuşmacıları arasında yer aldığı etkinliğe, Scrum Turkey ailesinden Alper Tonga konuşmacı olarak yer aldı.
 

"Değişim" temalı etkinlikte "Çevik / Yalın Dönüşüm İçerisinde Dokümantasyon" başlıklı bir konuşma gerçekleştiren Alper Tonga, katılımcılar tarafından büyük beğeniyle karşılandı. Etkinlikte gerçekleştirilen sunum dokümanına buradan ulaşabilirsiniz.

 
PMI TR Chapter'a bu güzel etkinliği düzenlediği için teşekkür ediyor, başarılarının devamını diliyoruz. Etkinlik fotoğraflarına buradan ulaşabilirsiniz.

Serçelerimizden Birisi Olmaya Hazır Mısın?

Agile konusunda daha çok bilgi sahibi olmak ister misin? Bir takım içerisinde değişimi nasıl başlatırım, nasıl liderlik yaparım diye sorular kafanı kurcalıyor mu? Üniversite son sınıftasın veya mezuniyetinin üstünden en fazla 1 yıl mı geçti?

O zaman tam yerine geldin! Serçelerimizden birisi olmaya hazırsan, Agile Sparrow seni bekliyor! Programın detayları için www.agilesparrow.com adresini ziyaret edebilirsiniz.

Scrum’a Bir de Böyle Bakalım

Yazarımız Oğuz Tetik'in ilk blog yazısı sizlerle.
 
Scrum, karmaşık ürünlerin geliştirilmesi ve sürdürülmesi için bize, tanımlanmış bir çerçeve ve disiplin sunuyor. Evet bu çerçeve, günümüzde pek çok örgüt tarafından bir proje yönetim metodolojisi olarak kullanılıyor. Bununla birlikte Scrum, sunduğu özerk ve özgürlükçü yapısıyla da klasik yönetim anlayışına meydan okuyor. Ben de bu yazıda, Scrum’un metodoloji boyutunu ve bununla ilgili pratikleri bir kenara bırakarak, günümüzün yönetim düşünürlerinin -ana fikir- yorumlarıyla Scrum’un arkasındaki yönetim düşüncesine kapı aralamaya çalışacağım…
 
Daniel H. Pink, bizi gerçekte nelerin motive ettiğine dair, bildik tüm klişeleri kıran Drive adlı kitabında, oldukça ikna edici argumanlarla insan motivasyonuna dair farklı bir bakış açısı sunuyor. “Tip I” olarak adlandırdığı davranış kalıbı ile de bu bakış açısını ortaya koyuyor:
Tip I davranışı, üç gıda ile beslenir: özerklik, ustalık ve amaç. Tip I davranışı, kendi kendini yönetmek ister. Önemli gördüğü şeylerde hep daha iyi olmaya kendini adamıştır. Mükemmeli arama çabasını daha büyük amaçlarla ilişkilendirir.
 “…Tip I davranışını ve beraberinde getirdiği yüksek performansı teşvik etmenin ilk yolu özerkliktir. İnsanlar işlerini nasıl, ne zaman, kiminle ve hangi yöntemlerle yapacakları konularında söz sahibi olmak isterler.
Elbette, “özerklik, ustalık ve amaç” Pink açısından birbirini tamamlayıcı unsurlar. Ancak özerklik en önemli başlangıç noktası. Peki Scrum’un özerklikle ilgili yaklaşımı nasıl? Scrum Reference Guide deki şu ifadeler, bunu anlamamızı sağlıyor:
“Scrum Takımları, kendi kendine organize olabilmelidir ve farklı disiplinlerden (çapraz fonksiyonel) bireyler içermelidir. Kendi kendine organize olan takımlar, ekip dışındaki kişiler tarafından yönlendirilmek yerine, işlerini en iyi nasıl gerçekleştirebileceklerini kendileri seçerler. Çapraz fonksiyonel takımlar, ekip dışındaki kişilerden bağımsız olarak, görevlerini yerine getirebilecek bütün yetkinliklere sahiptirler. Scrum’ın önerdiği bu takım yapısı esneklik, yaratıcılık ve verimliliği en iyi duruma getirmek için tasarlanmıştır.”
Yirminci yüzyılın en etkili Yönetim düşünürü olarak kabul edilen ve “bilgi işçisi” terimini icat eden Peter F. Drucker ise özerklikle ilgili şunları söylüyor:
Bilgi işçiliği hem özerklik, hem de sorumluluk gerektirir.
Bilgi işçilerinden kendi görevlerini ve çalışmalarının sonuçlarını tanımlamlarını istemek şarttır; çünkü bilgi işçileri özerk olmak durumundadır.
Drucker, özerklik kavramının yanına -tamamlayıcı olarak- sorumluluk kavramını da ekliyor. Evet, işlerin nasıl, ne zaman, kiminle ve hangi yöntemlerle yapılması özerkliğinin sağlanması ne kadar önemliyse; iş sonuçlarının tanımlanması ve bunların sorumluluğunun üstlenilmesi de şüphesiz o kadar önemlidir. Scrum Takımları da, çalıştıkları ürünle ilgili tahminleme, planlama ve geliştirme süreçlerini kendileri yönetmekle beraber, taahhüt (commit) ettikleri çıktıyı beklenen kalitede ve zamanda üretmekten ve ürünün gelişiminden birinci derece sorumlu değil midir?
 
Jim Collins mükemmel şirketleri gerçekte mükemmel yapan faktörleri, uzun yıllar süren çalışmaları sonucunda topladığı somut verilerle ortaya koytuğu, ses getiren Good to Great adlı kitabında, disiplin kültüründen bahsederken şunları söylüyor:
Mükemmel şirketler net sınırları olan tutarlı bir sistem yaratmışlar ve bu sistem içinde insanlara özgürlük ve sorumluluk vermişlerdir. Yönetilmesine gerek olmayan, öz disiplinli insanları işe almış ve onları değil sistemi yönetmişlerdir.
Collins, bir best practise olarak ne kadar da güzel özetlemiş: “net sınırları olan tutarlı bir sistem içerisinde insanlara özgürlük ve sorumluluk vermek”. Sizce de Scrum ile yapılmaya çalışılan, tam olarak bu değil mi? Scrum da, temelindeki şeffaflık, gözlem ve adaptasyon ilkelerinden güç alarak ortaya koyduğu -sınırları belli olan- “çerçeve” ile, insanlara kendi kendilerini yönetmelerine olanak sağlayan ve aynı zamanda onları öz disiplinli olmaya sevk eden tutarlı bir sistem sunmuyor mu?
 
Günümüzün en etkili stratejistlerinden biri olarak gösterilen Gary Hamel, başarıyı yakalayabilecek örgütler kurmaya yönelik çok yönlü bir ajanda olarak nitelendirdiği Şimdi Ne Yapıyoruz adlı son kitabında, son derece kontrolcü ve  bürokratik bulduğu klasik yönetim anlayışına yönelik eleştirilerini sıraladıktan sonra şunları söylüyor:
Yönetim ideolojisini açıklığa kavuşturduğumuza göre, artık ikinci soruya geçebiliriz: Kontrolün hayatta kalabilecek bir felsefi rakibi var mı? Var elbette, özgürlük! İlgi alanlarını izlemekte, bağlılıklarını seçmekte ve kendi yükümlülüklerini üstlenmekte özgür olan insanlar serpilip gelişebilirler. Ve bugün her zamankinden çok gerek duyduğumuz şey, insanlara tam da bu olanağı tanıyan örgütlerdir. Bir örgüt tam anlamıyla insani olmadıkça, asla tam anlamıyla muktedir olamaz. İşin püf noktası kuşkusuz söylemin ötesine geçmekte. Çalışanları özgürleştiren, yukarıdan aşağıya hiyerarşiyi ortadan kaldıran ve yine de sağlam iş sonuçları üreten radikal ve güçlü bir ideolojiye ihtiyacımız var.
Hamel’in de ifade ettiği gibi, çalışanlarının her sabah işlerine coşkuyla geldiği örgütler inşa edebilmek için, böyle bir yönetim anlayışı gerçekten umut verici.

Evet, benim Scrum’da gördüklerim ile kitaplarından esinlendiğim yönetim düşünürlerinin yukarıda anlattığım fikirleri arasındaki çağrışımlar bunlardan ibaret. Umarım biraz kapı aralayabilmişimdir. Başta da söylediğim gibi, Scrum’u tek başına, uyarlanması gereken bir proje yönetim metodolojisi olarak görmeyip, örgütün genel yönetim anlayışının tamamlayıcı bir aracı olarak değerlendirmenin daha sağlıklı olduğunu düşünüyorum. Yönetim düşüncesi ile proje yönetimi metodoloji bileşkesi, kulağa hoş geliyor…

Yeni Yazarımız: Oğuz Tetik

Sizleri yeni yazarımız Oğuz Tetik ile tanıştırmak istiyoruz. Kendisine hoşgeldin diyor, bizimle paylaşacağı bilgi ve deneyimleri için kendisine şimdiden teşekkür ediyoruz. İlk yazısı yarın burada olacak, takipte kalın!

 
Oğuz Tetik
10 yıl boyunca üretim sektöründe yazılım geliştiricisi ve veritabanı yöneticisi olarak Bursa'da çalıştı. Burada farklı kurumsal uygulama geliştirme projelerinde, karar destek sistemi oluşturulmasında, ve ERP proje implementasyonlarında görev aldı. 1.5 yıl geliştirme ekibi yöneticiliği yaptı.

2010 yılından bu yana İstanbul'da danışmanlık sektöründe Teknik Lider olarak çalışıyor. 2013 yılı sonlarında başladığı Scrum yolculuğuna Scrum Master olarak devam ediyor. Yönetim, liderlik, motivasyon, özel ilgi alanları.

Yazılımda Fast Food Scrum

Konuk yazarımız Osman Sönmez'in kendi kişisel tecrübelerini aktardığı blog yazısını sizlerle paylaşıyoruz. Keyifli okumalar.
 
Baştan söyleyeyim yanlışım varsa düzeltin lütfen. 1.5 seneden fazladır projelerimizi Scrum metedolojisi kullanarak yapıyoruz ama ben hala Scrum'ın faydasını anlamış değilim. Scrum ile ilgili ilk bilgileri edindiğimde faydalı bir şey olduğunu düşünmüştüm. Japonlar kullanmışsa iyidir demiştim. Her ithal ettiğimiz şeyi amacına uygun kullanmadığımız gibi galiba bunu da amacına uygun kullanmıyoruz.
 
Scrum'ın ülkemizde veya kendi kullandığımız projelerde uygulanış biçimini Fast Food satan yerlere benzetiyorum. Kısa zamanda çok iş :). Biri yağı döksün, aynı anda biri ocağın altını yaksın, aynı anda biri köfteleri hazırlasın, aynı anda biri siparişleri alsın, aynı anda  biri patatesleri kızartsın, biri ekmekleri hazırlasın, biri patatesleri paketlesin, biri köfteleri paketlesin vs... Herkes koşturuyor, çünkü müşteri buraya geldiğinde 5 dakika içerisinde yemeğini almak istiyor. 5 dakikada bütün bunların hazır olması gerekiyor. 6 dakika  olmaz deniyor, mutlaka 5. dakikada bu müşteriye verilecek. Müşteri memnun mu? Eh... Evet, yemeğini almış mutlu :). Kalite mi? Çok da önemli değil biz müşteriye hızlı bir şekilde yemek vereceğiz demişiz. Mutfaktakiler mi? Çok yorulmuşlar ve şunu anlamışlar ve öğrenmişler: Biz bu şekilde hizmet vereceksek malzemenin önceden  hazır olması gerekiyor, ne yapalım biz geceden malzemeleri hazırlayalım veya bir yere hazırlatalım. Hızlı pişmesi için de yarı pişmiş olsun. Müşteri farklı birşey talep ederse ne yapacağız?
 
 
5 dakikada Hünkar Beğendi yapacak halimiz yok. Elimizdeki malzeme bu. Yeni birşey yapmak için zaman olması gerekiyor. Mutfaktakiler çok yoruluyor, bir ürün çıkıyor ama kalitesi ve geliştirilebilirliği tartışılır, müşteri memnun gibi ama yeni bir şey isterse tecrübeli adam yok, çünkü herkes hızlı köfte üzerine uzmanlaşmış, başka bir şeye vakit verilmemiş.
 
Evet biz Scrum yapmaya başlarken, geleneksel yemekleri bırakmış Fast Food yapmaya başlamışız. Çünkü bize sunulan ve istenen şey tam olarak bu.  Niye Scrum yapıyoruz? Şelale yönteminde işler çok yavaş, bitmiyor, isterleri toplamak çok uzun vs. kaygılarla Scrum yapıyoruz. Aynı iş Scrumda daha çabuk oluyor diyorlar. Hem de mesai yapmadan oluyor diyorlar. Mesai yapmama olayına inanmıyorum çünkü fazla fazla yapıyoruz. Aynı iş oluyor mu? Oluyor gibi ama aslında Akçaabat  Köfte yapmamız beklenirken, biz daha hızlı pişmesi için aynı görünümde başka bir köfte yaptık, daha az lezzetli ama görünümü aynı Akçaabat.
 
 
Evet şimdiye kadar gördüğüm bu. Aslında bize anlatılan Scrum, Akçaabat köfte yap ama kaliteden ödün verme, organizasyona değer ver ve devamlı geliştir değil miydi? Problemlere hemen müdahele et ve süreçleri geliştir değil miydi? Development açısından baktığımda daha içler acısı bir durum görüyorum. Development takımlarına daha çok iş düştüğünü görüyorum. Scrum'da analiz var ama dökümantasyon pek yok diyorlar. Dökümante etmek zaman alırmış :). Developer soru sorar: Bu konuda analiz dökümanı var mı? Şunu ne yapacaktık acaba? Cevap: Ara sor veya yüz yüze sor, tam olarak ne istiyorsunuz? Ara sor veya yüz yüze konuş, mailleş ve bir sürü  mailden ne yapılacağını çıkar, bol bol "Ben sana söylemiştim hatırlamıyor musun?" diyalogları. Scrum yapmak için biyonik developer olmak gerekiyor. Hafızaya al ve bir daha unutmamak üzere kaydet. Çünkü Scrum'da, Şelale yöntemindeki gibi döküman yazılmaz, öyle öğrendik biz. İşimize de geliyor aslında :). Biz  söyledik developer yapsın işte.
 
İsterler pat diye geliyor ya 7.sprint geliyor biz şöyle bir ekran istiyoruz deniyor. Uçsun kaçsın. Biz bunu yaparız ama biraz araştıralım. 2 haftada bitmesi lazım :). Jquery.UI diye bir şey varmış onunla yaparız herhalde. Başlıyoruz yapmaya, yaptık yaptık iyi birşeylerde çıktı. Allah Allah IE8 de çalışmıyormuş bu. Tüh yaparız da dedik. Nerden bileceksin IE8'de çalışmadığını. IE8 müşteri için olmazsa olmaz deniyor. Bir o kadar da IE8 için uğraş. Gece gündüz yetiştirmeye çalış. Keşke buna benzer bir şey isteyeceklerini çok daha önce söyleselerdi, ya da bir analist bunu çok önceden sorgulasa mıydı? Bütün Scrum böyle geçiyor, bitiyor.
 
Sonunda şunu söylüyoruz: Biz ya Scrum'da birşeyleri yanlış yapıyoruz, ya Scrum yanlış ya da bizde bir sorun var. Scrum bizi çok yoran, çok daha kısa sürede aynı işi yapmaya çalıştığımız, düzensiz ve dökümansız çalıştığımız ve en önemlisi çok dağınık bir kodlama yapılan bir ortama doğru götürüyor gibi. Bu şekilde yapılan çalışmaların uzun vadede özellikle development takımlarının gelişimine ciddi negatif etkisi olacağını düşünüyorum. Birilerinin Scrum yapılırken  gerekli Ar-Ge faaliyetleri ve development gelişimi için nelerin yapılması gerektiğini, Scrum içerisinde bir yere koyması gerekir diye düşünüyorum.
*Bu yazı Osman Sönmez'in kendi blogundan alıntıdır.

Thoughtworks Turkey Summit Gerçekleştirildi

Scrum Turkey, Thoughtworks ve Hepsiburada'nın ortak olarak düzenlediği Thoughtworks Turkey Summit, 11 Eylül 2014 Perşembe günü İstanbul Hilton Otel'inde gerçekleştirildi. Yazılım sektöründen 400'den fazla kişiyi bir araya getiren etkinliğin onur konuğu Türkiye'ye ilk ziyaretini gerçekleştiren dünyaca ünlü yazılım üstadı Martin Fowler'dı.
 
 
Keynote konuşması sırasında Continuous Delivery, NoSQL ve Microservices gibi güncel konulara değinen Martin Fowler, katılımcılar tarafından büyük beğeni topladı. Etkinliğin devamında Thoughtworks Türkiye ve Hepsiburada ekibinden konuşmacılar sunumlarını gerçekleştirdiler.
 
 
Türkiye IT sektörünün gelişimine katkıda bulunmayı amaçlayan Scrum Turkey olarak, bir ilki daha başarmaktan büyük mutluluk ve gurur duyuyoruz. Yine ilkleri gerçekleştirmek için çalışmalarımıza devam edeceğiz. Bizi takip etmeye devam edin.
 
Etkinlik fotoğraflarına Facebook sayfamızdan ulaşabilirsiniz.

Agile Pratikler - Ne Var Ne Yok Toplantısı (Daily Scrum)

Agile Pratikler serisinin bir önceki yazısında bir Information Radiators çeşidi olan Niko Niko Takvimi pratiğine değinmiştik. Bu yazımızda hemen hemen her Agile takımın kullandığı Ne Var Ne Yok Toplantısı (Daily Scrum) pratiği ile ilgili bilgiler paylaşacağız.
 
 
Türkçe olarak, Ne Var Ne Yok Toplantısı olarak adlandırılan bu pratik, literatürde Daily Scrum (Scrum terimi) veya Daily Standup Meeting olarak bilinir. Her gün, aynı saatte, aynı yerde ve ayakta yapılan kısa bir toplantıdır. Maksimum 15 dk. olarak gerçekleştirilmelidir. Scrum Master ve diğer paydaşlara rapor verme ve problem çözme toplantısı değildir. Takım, günlük planındaki senkronizasyonu sağlamak amacıyla bu toplantıyı düzenler. Aşağıdaki üç soruya takım üyeleri sırayla cevap verir:
  • Dün ne yaptım?
  • Bugün ne yapacağım?
  • Önümde herhangi bir engel var mı?
Scrum Kılavuzu'nun 2013 ylında yayınlanan yeni versiyonunda bu üç soruda güncelleme yapıldı ve aşağıdaki şekilde güncellendi:
  • Dün takımın Sprint hedefine ulaşması için ne yaptım?
  • Bugün takımın Sprint hedefine ulaşması için ne yapacağım?
  • Önümde takımın Sprint hedefine ulaşmasını etkileyecek bir engel var mı?
Gördüğünüz gibi, yapılan bu güncelleme ile, sorular kişisel bakış açısından çıkarılarak, takım bakış açısı kazandırıldı. Bu güncellemenin etkilerini önümüzdeki günlerde daha net görebileceğimizi umuyorum.
 
 
Ne Var Ne Yok Toplantıları, sadece ayakta durup, takım içerisinde bilgi paylaşımının sağlanması için yapılmaz. Bununla birlikte Sprint içerisinde küçük yön değişimlerinin yapılmasına olanak sağlar. Çok görünür olmasa da, takım üyeleri arasında güven duygusunun oluşması ve kişisel planlamayı cesaretlendirmesi açısından da fayda sağlamaktadır.
 
Ne Var Ne Yok Toplantısı sırasında iki temel problemle karşılaşılır. Bunlardan birincisi, bu toplantının durum raporu verme şeklinde gerçekleştirilmesidir. İkinci problem ise, bu toplantıda bahsedilen problemlerin, bu toplantı süresince çözülmeye çalışılmasıdır. Bu iki temel problemin aşılması için, Scrum Master sorumluluğu üstlenmeli ve toplantının doğru şekilde gerçekleştirilmesini sağlamalıdır.

 
Bu toplantıyı daha etkin yapabilmenizi sağlayacak bazı yöntemler bulunmaktadır. Bunların bazılarını kendi Agile yolculuğum sırasında deneme yanılma yöntemi ile bulduğumu belirtmeliyim:
  • Toplantıda ilk kimin konuşacağını veya hangi sırayla konuşulacağını belirlemek bazen problem olmaktadır. Bu problemin aşılması için, konuşma sırasını belirleme görevini toplantının düzenleyicisi üstlenmelidir. Toplantı düzenleyicisi, "Son Gelen İlk Konuşur" veya "Takım Maskotu Kimde ise O Konuşur" kuralları ile toplantının etkin işletilmesini sağlayabilir.
  • Toplantının, takımın çalıştığı yerde yapılmasının enerji seviyesini yükselttiği söylenir. Ancak kendi denediğim, toplantının rahatsız ortamlarda (Yangın merdiveni, asansör boşluğu vb.) yapılması da, ekip içerisinde bir aciliyet duygusu oluşturmakta ve toplantının etkin yapılmasını sağlamaktadır.
  • Toplantının belirtilen zaman sınırı içerisinde tamamlanması da zaman zaman problem olmaktadır. Bu problemi aşmanız için, toplantının yapıldığı yerde eğer projeksiyon cihazı var ise, online bir zamanlayıcı kullanarak, toplantıyı tamamlamak için ne kadar süreniz kaldığını takım üyelerinin görmesini sağlayabilirsiniz. Böylece takım, zamanla bu süreye uymayı alışkanlık haline getirecektir.
  • Yukarıda belirttiğim gibi bu toplantının en temel problemi durum raporu verilmesi şeklinde yapılmasıdır. Burada Scrum Master olarak, konuşan kişi ile göz kontağını kesmenizi öneriyorum. Ben genellikle, o an konuşan kişiye odaklanmak yerine; çevreye, duvarlara veya tavana bakmayı tercih ediyorum. Bu sayede takımın birbiri arasında konuşmasını sağlayabilirsiniz.
Bu pratikleri siz de uygulayıp, sonuçlarını burada paylaşabilirsiniz.

Agile Pratikler - Niko Niko Takvimi

Bir önceki yazımızda Information Radiators konusuna değinmiştik. Bu yazımızda Information Radiators olarak kullanabileceğiniz bir Agile pratiğe değineceğiz. Bu pratiğimizin ismi, literatürde Niko Niko Takvimi olarak geçmektedir.
 
Niko kelimesi Japonca'da gülümseme (smile) anlamına gelmektedir. Niko Niko ise Japonca'da gülen yüz (smiley) anlamına gelmektedir. Niko Niko Takvimi, günlük seviyede takımın duygusal durumunu izlediği bir takvim olarak adlandırılmaktadır.
 
 
Niko Niko Takvimi, "Duygu Durumu Tahtası" olarakta bilinir. Bu pratik Agile yöntemler kullanan takımlar tarafından kullanılabileceği gibi, farklı metodolojilerde de kullanılabilir. İlk çıkışı 2001 yılıdır, ancak resmi olarak tanımı 2006 yılında Akinori Sakata tarafından yapılmıştır.
 
Takım, çalıştığı ortamın duvarına bir takvim asar. Bu takvimin formatı günlük bazda her üyenin duygusal durumunu belirtmesine izin verecek şekilde tasarlanmış olmalıdır. Her gün sonunda takım üyeleri kendi duygu durumlarını bu takvim üzerinde işaretler. Duygu durumu bilgisi; renkli kağıtlar, yüz ifadelerini belirten ikonlar (emoticon), veya basit renk kodları ile belirtilebilir. Skalayı istediğiniz gibi ayarlayabilirsiniz. Örneğin renk kodları kullanıldığını varsayalım. Bu durumda aşağıdaki renk kodları ile 3'lü bir skala kullanılabilir:
  • Mavi - Kötü bir gün
  • Kırmızı - Normal bir gün
  • Sarı - İyi bir gün
Takım motivasyonu ve duygusal durum bilgisi, genellikle öznel bir bilgi olduğu için ölçülemez olarak görülür. Bu yöntemin en önemli faydası, öznel olan bu durumun, nicel olarak ölçülebilmesini sağlamasıdır.
 
 
Takım üyelerinin kendi duygu durumlarını belirtmeleri her zaman risk olarak görülebilir. Bu yöntem de bu riski barındırmaktadır. Özellikle kötü olarak raporlanan günler için yönetimler, takımları "sızlanıyorlar" şeklinde suçlayabilirler. Ancak bu problemin gerçek anlamda Agile felsefesini benimsemiş takımlarda ve organizasyonlarda ortaya çıkmayacağını düşünüyorum.
 
Bu yöntemi bugüne kadar kullandığım bir takım olmadı. Ancak Scrum'ın yaratıcısı Jeff Sutherland, eğitimlerinde bu pratiğin kullanımını önermektedir. Ben de bu tavsiyeye uyarak, çalışmakta olduğum takımlara bu pratiği kullanmalarını tavsiye edeceğim.
 
Bu takvimi kullanmak isteyenler için buradan güzel bir şablona ulaşabilirsiniz.
 
Keyifli bir Agile yolculuğu diliyorum. Bir sonraki yazımızda görüşmek üzere.