Agile Leaders 4. Bölümü Gerçekleştirildi

Agile Leaders etkinliğinin 4. bölümü gerçekleştirildi. Bu bölümdeki konuğumuz Pınar Ayorak'tı. Kendisine keyifli sohbeti ve katkıları için çok teşekkür ediyoruz.

 

Sizlerin geri bildirimleri bizim için çok önemli. Etkinlikle ilgili düşüncelerinizi, etkinlikte görmek istediğiniz konukları, sorularınızı vb. bize Twitter üzerinden #AgileLeadersST etiketiyle iletebilirsiniz.

Agile Leaders 5. bölümü 17 Aralık 2014 tarihinde gerçekleştirilecek. Detaylarını önümüzdeki günlerde yayınlayacağız.

Agile Leaders Etkinliği - Episode 4

Agile Leaders 4. Bölümü ile sizlerle! Etkinliğimizin bu bölümünde 26 Kasım 2014 Çarşamba günü, saat 17.00'da Nice Teknoloji kurucusu Pınar Ayorak bizlerle olacak. Bu bölümümüzde "Scrum Master ve Agile Coach" başlıklı bir sohbet gerçekleştireceğiz. Bu keyifli sohbeti kaçırmayın!

 
Yayın öncesinde veya canlı yayın sırasında Pınar Ayorak'a yöneltmemizi istediğiniz soruları #AgileLeadersST etiketi ile Twitter üzerinden paylaşabilirsiniz.
 
 
 
Pınar Ayorak Kimdir?
 

  
Pınar Ayorak, graduated from Northeastern University in USA with a Bachelor of Computer Science degree and a minor in Business Administration.
Over 12 years of IT experience; from software developer, through software architect, project manager, program manager, IT director up to IT business owner; she has worked on every software tier from embedded to enterprise systems.
She has been introduced to Scrum in 2008. Within the same year, she was trained by Jeff Sutherland and Gabrielle Benefield respectively in Amsterdam and have become Certified Scrum Master (CSM) and Scrum Product Owner (CSPO).
She has worked with several teams and organisations using Scrum on multinational projects based in USA, England and Holland for a variety of business environments.
With hands-on experience, documented training, and proven knowledge of Scrum, she has become Certified Scrum Professional (CSP) in 2014 as well.
She has founded Nice Teknoloji in 2013 which provides Agile Transformation consultancy, Agile Coaching, Agility Assessment and Training to the organisations for the journey through Agility. 
She is also a contributor on www.scrumturkey.comTMMOB and sharing some of her time and experience to spread the knowledge on Scrum to the community as needed.

Sprint Retrospective

Yazarımız Barış Dere'nin ilk blog yazısı sizlerle.

Bu yazıda kendi tecrübelerimden yola çıkarak Sprint retrospectivelerde karşılaştığımız sorunları ve bunları çözmek için ne gibi yöntemlere başvurduğumuzu paylaşmaya çalışacağım.
 
Scrum Retrospective (Geçmişe yönelik iyileştirme toplantısı) Scrum Master tarafından her sprint sonunda düzenlenir ve en fazla 3 saatlik bir zaman ayırılır. Bu toplantıda sprint boyunca takım bireylerinin, geliştirme araçlarının, yönetimin vs ne derece başarılı olup olmadığı değerlendirilir. Bu değerlendirmeyi yaparken sprint içerisinde doğru yapılan şeylerin devamlılığı ve iyileştirmeyi gerektirecek şeylerin de bir sonraki sprint içerisinde uygulamaya geçilmesi çok önemlidir. Ana amaç takımın kendini ve çalışma ortamını nasıl devamlı iyileştirebilmesidir.


Fakat efektif bir retrospective yapmak sanıldığı kadar kolay değil. Bu konu hakkında kitaplar bile yazılmış olduğunu biliyor muydunuz? Bir çok Scrum takımı bu toplantıları enerjik ve kullanışlı bir şekilde geçirmek için yoğun çaba harcıyor. Hatta bazı takımlar bunu başaramadıklarından dolayı tamamen retrospective yapmayı bile bırakıyorlar. Bu tamamen Scrum anlayışına ters ve takımın kendini iyileştirmesinin önünü tıkıyor. Yazının devamında retrospectivelerde yapılan yanlışlıklar ve tavsiyeleri paylaşacağım.

Retrospective’lerde yapılan yanlışlardan bazıları:

1. Retrospective yapmamak veya çok kısa yapmak
 
Hiç bir takım mükemmel değildir ve mutlaka iyileştirilmesi gereken şeyler vardır. Retrospective kesinlikle yapılması gerekmektedir ve takımın devamlı kendini iyileştirmesi gerekir.

2. Takım üyelerinin birbirlerine karşı yeterince açık olmaması
 
Bu tür toplantılarda takım üyeleri karşılaştıkları zorlukları söylemekten çekinir veya pasif bir tavır takınır. Bu yüzden toplantı sonunda sanki hiç bir sorun yokmuş gibi bir sonuç ortaya çıkar. Veya önemsiz bir konu sonraki sprint için iyileştirme olarak kullanılır. Takım üyelerinin birbirlerine karşı açık olmasını gerektiren bu toplantılarda her bireyin aktif bir şekilde konuşmalara katılması çok önemlidir. Bu olmuyorsa bunun nedeni takım içerisinde tartışılmalı ve bir çözüm bulunmalıdır. Unutulmaması gerekir ki Retrospective sorunların konuşulup tartışılması için en doğru yer.

3. Retrospectivelere yöneticilerin katılması
 
Bu toplantılar sadece takım üyeleri içindir ve yöneticiler kesinlikle katılamaz. Aksi taktirde bireyler yeterince açık olamaz ve gerçeği yansıtmayan bir sonuç ortaya çıkar. Ama takım içerisinde çözülemeyen bir sorun varsa yöneticilerin katılması olumlu olur. Bu sayede sorun enine boyuna tartışılır ve bir çözüm bulunur.

4. Retrospectivelerin çok sıkıcı ve rutin hale gelmesi

En çok görülen hatalardan biri retrospectivelerin sıkıcı hale gelmesidir. Her birinin birbirine benzediği ve aynı şeylerin konuşulduğu toplantılar haline döner. Aynı retrospective tekniği her seferinde kullanılır ve hiç bir yenilik katılmaz. Peki bu toplantıları nasıl enerjik ve efektif hale getirebiliriz?


5. Uygulanmayan iyileştirmelerin çoğalması
 
Diğer sık rastlanan hatalardan biri de takımın her seferinde uzun bir iyileştirme listesi yapması ve bu iyileştirmelerin bir türlü hayata geçirilmemesi. Her toplantıda diğer toplantıda yapılan liste ile başlanır ve aynı şeyler tekrar konuşulur. Toplantının sonunda yine uzun bir liste çıkar ve hepsinin iyileşemiyeceği için liste devamlı uzar durur. Peki bu uzun listenin yerine içinden sadece en önemli bir tanesini kullanmak ona odaklanmak daha yararlı olmaz mı?

6. Uygulanması zor veya imkansız şeylere yoğunlaşmak
 
Bir diğer hata ise takım bireylerinin uygulanması imkansız veya zor iyileştirmelere yoğunlaşması ve tüm enerjisini buna harcamasıdır. Bu tür toplantıları bireyler sadece şikayet ederek geçirirler ve çözüm odaklı düşünmezler. Bunun sonucunda toplantının sonunda memnun olmayan ve gerilmiş bir takım ortaya çıkar.

Yukarıda belirtilen hatalardan yola çıkarak bir kaç tavsiye:
 
1. Gerektiğinde yöneticileri davet edin
 
Takım içinde çözülemeyen sorunlar veya huzursuzluklar varsa bunların çözümünde yöneticileri de davet etmek yerinde olacaktır. Sonuçta takımın optimal şekilde çalışması yöneticilerinde sorumluluğundadır.
 
2. Sadece bir iyileştirmeye odaklanın

Retrospective sonunda ortaya çıkan iyileştirmelerden sadece en önemli birini alın ve geri kalanları çöpe atın. Çünkü atılan noktalar çok önemli ise zaten diğer retrospectivede tekrardan ortaya çıkar. Bu seçtiğiniz iyileştirmeyi sprint baklogunun en başına alın ve bu sayede sprint içerisinde ele alınacağından emin olursunuz.

3. Bir  hedef belirleyin
 
Retrospective başlamadan bir hedef veya bir konu belirleyin. Örneğin her sprint tekrarlanan sorunları nasıl çözebiliriz, veya retrospectiveleri nasıl daha az zamanda yapabiliriz. Böylelikle takımın dikkatini bir yöne vermiş oluruz ve farklı bakış açılarının ortaya çıkmasını sağlayabiliriz.


4. Değişikliğe açık olun
 
Retrospective yaparken farklı teknikler ve yöntemler kullanın. Her seferinde değişik yönlerden ele almaya çalışın. Farklı kişiler başkanlık etsin, başka lokasyonlarda toplanın. Ya da takım olarak beraber yemeğe çıkın veya dışarıda başka bir ortamda toplanın. Retrospectivelerin neşeli ve enerjik ortamda geçmesini sağlayın.

Agile Dönüşüm - Şirket Yöneticisi Ne ister?

Yazarımız Yelda Gürbüz Erdoğan'ın ikinci yazısı sizlerle. İlk yazısına buradan ulaşabilirsiniz.

Şirket yöneticisi ne ister?
  • Bütçeyi aşmayan, zamanında biten ve beklenen kalitede olan ürünlerin sağlanması
  • Yüksek müşteri memnuniyeti
  • Yeni müşterilerin kazanılması
  • Yüksek karlılık
Yukarıda sıralanan beklentiler aynı zamanda şirketin hedefleridir ve herbiri üretilen "değer" ve bu değerin sürekliliği ile ilgilidir. Sürekliliği sağlamak için benzer ürünleri üreten şirketler ile rekabet gücünüzün olması gerekir. Rekabet gücünüzü arttıran ya da azaltan şey müşterinizin ya da kullanıcınızın üretilen değerden beklediği özelliklerdir. Bu özellikler şunlar olabilir:
  • Hatasız çalışması
  • Kolay kullanılması
  • Anlaşılır olması
  • Bakım tutum yapılabilir olması
  • Her zaman beklendiği şekilde çalışması

Şirket yöneticisinin en öneli sorumluluğu şirket hedefleri ile müşteri/kullanıcı beklentilerini sağlamaktır. Bu sorumluluğu yerine getirmek için kullanılacak yöntem ne olur? Buna kesin bir yanıt vermek zor. Bu soruya hap çözüm yok. Her şirket kendisine uygun yaklaşımı ortaya çıkarmalı. Bunu yaparken tabii ki de varolan çözümleri uygulayabilirler. Benim görüşüm, kendilerine en uygun ve acısız yöntemi seçmeleri, ilerlemelerini kolaylaştıracaktır.

Jack Welsh 1981 - 2001 yılları arasında General Electric CEO'su ve Yönetim Başkanı olarak çalıştı. Bu süre içerisinde GE'nin şirket değerini %4000 arttırdı. Peki bunu nasıl yaptı? Süreç iyileştirmeyi sağlayan araç ve teknikleri içeren Six Sigma ile bu ilerlemeyi sağladı.

Değişime açık fikirli olmakla başlayabiliriz. "Yönetici çalışandan daha iyi bilir" yerine "çalışan kendi işini daha iyi bilir ve bunu iyileştirmek için gerekli adımları atar" durumuna geçiş, tüm tarafların ve özellikle şirket yöneticilerinin açık fikirliliği desteklemesi ile mümkün olacaktır.

Çevikliğe giden yolda en önemli görev şirket yöneticilerine düşmektedir. Hedeflerin ne olduğunu ortaya koymalıdır. Elde edeceği sonucun başarı tarifini yapmalıdır. Varacağı nokta müşterilerine değer katmak ve kendi sürekliliğini sağlamak olacaktır.

Yeni Yazarımız : Barış Dere

Scrum Turkey ailesi büyümeye devam ediyor! Bizimle aynı vizyonu paylaşan yeni bir yazarımız daha var. Aramıza katılan en son yazarımız Barış Dere'ye hoşgeldin diyor, bizimle paylaşacağı bilgi ve deneyimleri için kendisine şimdiden teşekkür ediyoruz.
 
Barış Dere
Barış Dere, Hollanda da ikamet etmekte olup 2001 yılından bu yana yazılım sektöründe mimar, geliştirici, danışman ve eğitmen olarak kurumsal Java projelerinde calışmaktadır. Çoğunluklu olarak finans sektöründe rol aldığı projelerde başlangıç aşamasından bitiş aşamasına kadar bütün süreçlerde farklı rollerde yer almıştır.

2010 yılından bu yana Scrum ve DevOps takımlarında Scrum Master ve Scrum/DevOps Engineer rollerinde calışmakla beraber, WaterFall metodundan Scrum ve DevOps metodlarına geçiş süreçleri hakkında geniş tecrübeye sahiptir. Bloguna bu linkten ulasaşabilirsiniz.

Çevik (Agile) Proje Yönetimi ve PMBOK Kılavuzu - I

Yazarımız Dilek Çıplak'ın ilk blog yazısı sizlerle.

Yaklaşık 15 yıldır yazılım geliştirme ve ERP (Kurumsal Kaynak Planlama) alanlarında pek çok projede Proje Yöneticiği yapmış birisi olarak; geleneksel şelale (waterfall) modeli, iteratif ve artımlı (incremental) yaklaşımlar, prototip oluşturmaya dayalı yöntemler ve çevik (agile) bazlı farklı yöntemleri deneyimleme fırsatım oldu.
 
Özellikle son yıllarda Türkiye’de bilinirliği ve uygulamaları artmaya başlayan çevik bazlı metodlar ile birlikte ortaya çıkan “doğru bilinen yanlış”lardan birini düzeltmemiz gerektiğine inanıyorum.
 
Maalesef daha çok yazılım geliştirme projelerinde yaygın olarak karşımıza çıkan bu yanlış kanı sonucu; PMBOK (Project Management Body of Knowledge- PMI-www.pmi.org) ile tanımlı süreç ve pratiklerin çevik yaklaşımlara uygun olmadığı düşünülmektedir.
 
Hatta çevik yöntemlere uyum sağlamak içim PMI ve PMBOK rehberinin ve PMP sertifikasının bir kenara konulması gerektiğini düşünenler bile vardır. Aslında çevik projeler de PMBOK ile çerçevesi belirlenen proje yaşam döngüsü ve süreçlerini baz almaktadır.
 
PMBOK; proje yönetimi bilgi alanları, süreç ve pratiklerini tanımlayan ve herhangi bir metodoloji dikte etmeyen bir kılavuz dokümandır. Sadece yazılım geliştirme proje yöneticilerinin değil, farklı alanlardaki proje yöneticilerinin de başvurduğu bu kılavuzda yer alan süreçlerin tümünün projelerde uygulanması söz konusu değildir. Kurumların ve gerekirse projelerin niteliklerine uygun olarak PMBOK ile çizilen çerçevedeki ilgili süreç ve tekniklerin özelleştirilmesi ve uyarlanması gerekmektedir. PMBOK, proje yönetimi için “en iyi pratikleri” içeren ve şelale ya da çevik yaklaşımların tümü için uygulanabilir bir çerçeve sunan bir rehberdir.
 
PMBOK Süreç Grupları

Bu nedenle çevik olmak için PMP sertifikanızı bir kenara koymanız gerekmemektedir. Yapmanız gereken tek şey pratikleri uygulama yönteminizi ve odağınızı değiştirmektir.
 
Bir sonraki yazımızda bunu nasıl yapacağımızdan ve PMBOK ile tanımlı proje yaşam döngüsü ve süreçlerinin çevik proje yaşam döngüsü ve süreçleri ile birebir nasıl örtüştüğünden örneklerle bahsedeceğiz.

Introduction to Scrum Sunumunun Türkçesi Yayınlandı

Yöneticilerinize Scrum çerçevesini anlatmak istiyorsunuz ama elinizde dokümantasyon mu yok? Takımınıza Scrum eğitimi vermek istiyorsunuz ama sunum hazırlamak için vakit mi bulamıyorsunuz?
 
 
Bu probleminizi ortadan kaldırmak için, Mike Cohn tarafından hazırlanmış olan "Introduction to Scrum" sunumunun Türkçesini sizler için hazırladık. Sunum dokümanına buradan ulaşabilirsiniz. Sunum içerisinde karşılaştığınız hataları bize iletebilirsiniz.

Agile Sparrow Başlangıç Kampı Gerçekleştirildi!

Scrum Turkey olarak, Agile fikrinin bilinirliğinin arttırılması ve yaygınlaştırılması amacı ile başlatmış olduğumuz Agile Sparrow programının başlangıç kampını 1 - 2 Kasım 2014 tarihlerinde, güzel İzmir'in Alaçatı ilçesinde bulunan Solto Otel'de gerçekleştirdik.
 
 
Programa başvuruda bulunan 150 üstündeki arkadaşımız arasından seçilen 15 serçemiz ile yorucu ama bir o kadar da keyifli bir haftasonu geçirdik.
 
 
Kamp sırasında uygulamalı Agile ve Scrum eğitimleri ile birlikte serçelerimizin kişisel gelişimlerini destekleyen Etkili Sunum Yapma Teknikleri, Liderlik ve Takım Çalışması seminerleri gerçekleştirildi.
 
Serçelerimiz kamp sonucunda projelerini belirleyerek çalışmalarına başladı. Yakın bir zamanda hem serçelerimizin, hem de projelerinin detaylarını buradan sizlerle paylaşacağız. Bu programın gerçekleşmesinde emeği geçen başta sponsorlarımız olmak üzere, herkese teşekkür ediyoruz.
 
Etkinlik fotoğraflarının tümüne Agile Sparrow Facebook sayfasından ulaşabilirsiniz.

Yeni Yazarımız: Dilek Çıplak

Scrum Turkey ailesi büyümeye devam ediyor! Bizimle aynı vizyonu paylaşan yeni bir yazarımız daha var. Aramıza katılan en son yazarımız Dilek Çıplak'a hoşgeldin diyor, bizimle paylaşacağı bilgi ve deneyimleri için kendisine şimdiden teşekkür ediyoruz.
 
Dilek Çıplak
Dilek Çıplak, Ortadoğu Teknik Üniversitesi Bilgisayar Mühendisliği'nden 1994 yılında mezun oldu. Kamu ve özel sektörde bankacılık, finans, veri güvenliği ve veri iletişimi gibi farklı alanlarda yazılım geliştirme uzmanı olarak görev yaptı. Yaklaşık 15 yıl yazılım geliştirme ve ERP (Kurumsal Kaynak Planlama) alanlarında pek çok farklı projede Proje ve Program Yöneticiliği yaptı. Proje Yönetim Ofisi kurulması, PMI® ve CMMI uyumlu bir Proje Yönetim Metodolojisinin geliştirilmesi ile proje yönetiminde firmanın ihtiyaçlarına uygun bir aracın uyarlanması çalışmalarında görev aldı.

2010 yılından itibaren Oracle Türkiye danışmanlık ekibine, Proje Yöneticisi olarak katıldı ve kurumsal firmaların e-İş Çözümleri (Oracle ERP-eBS) implementasyon projelerinde görev aldı. İş Geliştirme Yöneticisi ve Program Yöneticisi olarak devam eden kariyerinde çevik bazlı proje yönetim metodolojileri ve özellikle Scrum ile yakından ilgilenmekte ve bu konuda eğitim ve danışmanlık hizmetlerine devam etmektedir.

Merkezi ABD'de bulunan Project Management Instute (PMI) üyesi olup, bu kurumdan PMP ve REP derecelerine sahiptir.

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

Agile Leaders etkinliğinin 3. bölümü gerçekleştirildi. Bu bölümdeki konuğumuz Hakan Erdoğan'dı. Kendisine keyifli sohbeti ve katkıları için çok teşekkür ediyoruz.


Sizlerin geri bildirimleri bizim için çok önemli. Etkinlikle ilgili düşüncelerinizi, etkinlikte görmek istediğiniz konukları, sorularınızı vb. bize Twitter üzerinden #AgileLeadersST etiketiyle iletebilirsiniz.

Agile Leaders 4. bölümü 26 Kasım 2014 tarihinde gerçekleştirilecek. Detaylarını önümüzdeki günlerde yayınlayacağız.

Agile Fluency Makalesinin Çevirisi Yayınlandı

Agile dönüşüm çalışması yapmak isteyen ekiplerin yaşadıkları en büyük problem, süreç içerisinde nasıl ilerlenmesi gerektiğinin bazen bilinmiyor olmasıdır. Bu nedenle Agile dünyasında, bu süreci modellemeye çalışan bir çok çerçeve ortaya konulmuştur. Bu modellerden bizce en kolay anlaşılır ve uygulanabilir olduğunu düşündüğümüz Agile Fluency modelinin Türkçe çevirisini hazırladık.
 
 
 
James Shore and Diana Larsen tarafından hazırlanan bu modelin sizler için faydalı olacağını umuyoruz. Agile Fluency modeli dokümanına buradan ulaşabilirsiniz.