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

Agile Leaders etkinliğinin 5. bölümü gerçekleştirildi. Bu bölümdeki konuğumuz Hakan Danışık'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 6. bölümü 7 Ocak 2015 tarihinde gerçekleştirilecek. Detaylarını önümüzdeki günlerde yayınlayacağız.

Agile Leaders Etkinliği - Episode 5

Agile Leaders 5. Bölümü ile sizlerle! Etkinliğimizin bu bölümünde 17 Aralık 2014 Çarşamba günü, saat 17.00'da Comodo ArGe Direktörü Hakan Danışık bizlerle olacak. Bu bölümümüzde "Ürün Geliştirme Projelerinde Agile Yöntemler" 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 Hakan Danışık'a yöneltmemizi istediğiniz soruları #AgileLeadersST etiketi ile Twitter üzerinden paylaşabilirsiniz.

 
Hakan Danışık Kimdir?
 
 
1996 yılında ODTÜ Bilgisayar Mühendisliği bölümünden mezun olan Hakan Danışık, 15 yıl Siemens Türkiye ArGe grubunda çalışmıştır. 2008 yılında Siemens yazılım geliştirme süreçlerinin CMMI L3 uyumluluğu çalışmalarında aktif olarak rol almış, ve Ankara ArGe grubu olarak CMMI L3 sertifikasının alınması çalışmalarında yer almıştır.

2009 yılında Boris Gloger’dan aldığı uygulamalı eğitimler ile birlikte agile yöntemlerle tanışmış, bu yöntemleri kullanarak şirket süreçlerinin de Scrum temelinde güncellenmesi çalışmalarını yürütmüştür.

2013 Ocak ayından itibaren Comodo şirketinde ArGe Direktörü olarak çalışmaktadır. Comodo'nun yazılım geliştirme süreçlerinin tasarlanması ve yazılması işlerine öncülük etmiş, Comodo genelinde kullanılmak üzere agileComodo isimli çatı sürecin geliştirilmesine katkı sağlamıştır.

Bilişim Zirvesi'14 - Agile Approach to ERP by Pınar Ayorak

Yazarlarımızdan Pınar Ayorak, 30 Eylül - 1 Ekim tarihleri arasında Lütfi Kırdar Kongre Merkezi, İstanbul'da düzenlenen ICT Summit NOW - Bilişim Zirvesi'14 etkinliğinde konuşmacı olarak yer aldı. "Agile Approach to ERP" başlıklı sunumuyla, karmaşık olan ERP projelerinde Agile yaklaşımların kullanımına yönelik bilgiler aktardı. Bu etkinliği kaçıranlar için konuşmanın videosunu sizlerle paylaşmak istiyoruz. Keyifli seyirler.
 

Scrum Master Proje Yöneticisi Midir?

Yazarımız Sevgi Korkmaz'ın yeni yazısı sizlerle. İlk yazısına buradan ulaşabilirsiniz.

Klasik proje yönetiminden Agile’a geçiş sürecinde en çok merak edilen konulardan biri Proje Yöneticisine ne olacağıdır. Bir proje yöneticine ihtiyaç var mıdır? Üst yönetime zaman, kalite ve maliyet konusunda söz verebilecek birisi olacak mıdır? Proje süresince ve sonunda maliyet hesabını da içeren bir takım metrik ve raporları kim sağlayacaktır? Tedarik sürecini kim yönetecektir?  Scrum Master bir proje yöneticisi midir ya da product Owner ya da Takım,  Proje Yöneticisinin yerini alabilir mi? gibi sorular, organizasyonda Agile süreçlere geçişte cevaplanması gereken sorulardır.

Scrum metodolojisinde Proje Yöneticisinin sorumluluklarının bir kısmı Geliştirme Takımı, Scrum Master ve Product Owner tarafından üstlenilir. Burada bir kısım kelimesinin altının çizilmesi gerektiğini düşünüyorum çünkü bazı sorumluluklar Scrum metodolojisinin dışında kalmaktadır.


Rollere ve üstlenilen sorumluluklara kısaca bakalım.


Geleneksel proje yönetiminde, proje yönetcisi, projenin çıktılarından sorumlu kişi olarak tanımlanır. Bu tanım Scrum’da “Product Owner” için yapılmaktadır. Product Owner, projenin başarısından sorumludur. Ancak Product Owner, proje yöneticisinin yerini almıştır diyemeyiz. Başarıya ulaşmak için uygulanan yöntemler tamamen farklıdır. Klasik proje yönetiminde proje yöneticisi gerekli yöntemi belirleme, plan yapma ve planı uygulama otoritesine sahipken Product Owner’ın böyle bir otoriteye ihtiyacı dahi bulunmamaktadır. Tek yapması gereken ürünle ve paydaşların beklentileriyle ilgili vizyonu ekibe sağlamak, bu vizyona göre önceliklendirme yapmak ve işin istenen kalitede kabulunu gerçekleştirmektir.  Yani Product Owner, Müşteri Yönetiminden, Kapsam Yönetiminden ve Kalite Yönetiminden sorumludur.
 
Entegrasyon Yönetimi, Insan Kaynakları Yönetimi, Satın Alma Yönetimi Scrum Master ve ilgili departmanlar tarafından gerçekleştirilir. Scrum Master, sürecin Scrum süreçlerine göre gerçekleşmesini sağlayan ve takımın önündeki engelleri kaldıran kişi olarak takım adına proje ile ilgili bir taahhüt vermez.
 
 
Proje planındaki işlerin günlük takibi, zaman yönetimi, proje sürdürülürken ortaya çıkan konuların ele alınması, projenin doğrulama aktiviteleri, risk yönetimi, Geliştirme Takımı’nın sorumluluğundadır. Bu konularda Scrum Master takıma destek olur.

Proje yönetiminin bilgi alanları ve rolleri aşağıdaki gibi eşleştirebiliriz.

Entegrasyon Yönetimi : Scrum Master
Zaman Yönetimi : Geliştirme Takımı
Maliyet Yönetimi : Geliştirme Takımı & Scrum Master & Product Owner
Kalite Yönetimi : Product Owner & Scrum Master & Geliştirme Takımı
İnsan Kaynakları Yönetimi : Scrum Master
Müşteri ve Paydaş Yönetimi : Product Owner
Risk Yönetimi : Scrum Takımı
Satın Alma Yönetimi : Scrum Master
 
Sonuç olarak, Scrum Master, Proje Yöneticisi değildir. Scrum’da projenin tüm sorumluluğunu takım adına üstlenecek bir proje yöneticisine ihtiyaç bulunmamaktadır. Takım, Scrum Master ve Product Owner bu sorumluluğu beraber yerine getirirler. Geçiş yapan firmaların bu konuda çekincelerini aşmak için, adaptasyon sürecinde Scrum Takımından gerekli verileri alarak geneleksel yöntemlerle raporlamaları yapan bir proje ofisi üyesi ekiple beraber çalışabilir. Zaman içerisinde sonuçlar elde edilip, güvenin artması ile beraber, iş yapma ve kontrat yapma şekli de agile olabilir ve bu rol ortadan kaldırılabilir.

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

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

Bir önceki yazımızda; PMBOK Kılavuzu, 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 demiştik.

Çevik bazlı metodların da PMBOK ile çerçevesi belirlenen proje yaşam döngüsü ve süreç gruplarını baz aldığını örneklendirmek için,  bu iki başlığı ayrı ayrı ele alalım.

Proje Yaşam Döngüsü
PMBOK ile tanımlanan proje yaşam döngüsü (Şekil-1) projeye dahil olan organizasyonların kontrol ihtiyaçları dikkate alınarak belirlenen sayıda ve isimde sıralı (sequential) proje fazlarından oluşur. Bu fazlar belirli bir teslimat ortaya çıkarmaya yönelik birbiri ile ilişkili aktivitelerin mantıksal gruplamasıdır.
Şekil-1 – Proje Yaşam Döngüsü Fazları (PMI)
Geleneksel yazılım geliştirme yaklaşımlarında, bu fazlar çoğunlukla şelale metoduna (Şekil-2) uygun olarak takip edilmiştir. Örneğin fazlardan birisi Tasarım olarak belirlenip, bu faz için teslimat olarak system tasarım dokümanı belirlenebilir. Çoğu zaman bir sonraki faza geçiş için onay ve imza (sign-off) gerekliliği vardır. Ancak tüm bu uygulamalar seçilen metodoloji ile ilgilidir, PMBOK tarafından zorlanan bir durum değildir.
 
Şekil-2 – Yazılım Geliştirme Şelale Yaklaşımı (Royce, 1970)
Çevik proje yaşam döngüsü ise iterasyon adı verilen sıralı proje fazlarından oluşur ve her bir fazın sonunda teslimat olarak “çalışan bir kod” ortaya çıkarılır. Şelale yaklaşımında tüm proje için sıralı olarak uygulanan aşamalar – analiz, tasarım, geliştirme, test- çevik projelerde geliştirilen kodun artımlı olarak devam ettirilmesi hedefiyle her bir faz için uygulanır.

Proje yaşam döngüsü tanımında yer alan “organizasyonların kontrol aşamalarına uygun olarak belirlenen sayıda” proje fazı ise çevik projelerde iterasyon süresi ve sayısı ile birebir aynıdır. Çevik yaklaşımlarda, iterasyon sayısı müşterinin belirli bir sürüm için kabul edeceği minimum fonksiyonalite baz alınarak belirlenir (MMF-Minimum Marketable Features). Müşterinin hangi sıklıkta ürünü kontrol etmek istediğine bağlı olarak 1 ila 4 haftalık iterasyonlar kararlaştırılabilir. Iterasyon süresinin tespitinde piyasa koşulları, ilgili sektör, risk seviyesi, ürün vizyonunun net olup olmaması gibi farklı kriterler de devrede olur.

Çevik projelerde proje yaşam döngüsünün (Şekil-3) başlangıç (Initiation Phase) fazında, ilk iterasyonun parçası olarak planlama süreci yer alır ve teslimat olarak “çalışan bir kod” ile birlikte proje için üst seviye bir proje planı sunulur. Ara (Intermediate Phases) fazlar ise “çalışan artımlı kod” şeklinde teslimatların yapıldığı sürüm ve/veya iterasyonlardan oluşur. Çevik projelerin en son fazı (Final Phase) ise tüm isterleri karşılayan ürünün üretime geçiş için yapılan son hazırlıkları, en son proje retrospektif toplantısı ve proje kapanış aktivitelerinden oluşur.
 
Şekil-3 – Çevik Proje Yaşam Döngüsünde- Faz ve Altfazlar (Agile Fractal)
Çevik projelerdeki herbir iterasyon, bir proje olarak değil projenin bir fazı veya alt fazı olarak değerlendirilebilir. Her iterasyon sonunda artımlı yaklaşım sayesinde ortaya çıkan sonucun değerlendirilmesi ve bir sonraki iterasyon öncesinde elde edilen sonuçların dikkate alınması ile daha doğru ve öğrenerek planlama yapılması mümkün olmaktadır. PMBOK ile tanımlanan “progressive elaboration-aşamalı olgunlaşma” kavramı tam da çevik projelerin “contionus improvement-sürekli iyileştirme” kavramı ile eşleşmektedir.
 
Süreç Grupları
PMBOK Rehberi’nde yer alan süreç grupları ayrı birer faz değildir. Süreç grupları, proje süresince iteratif olarak uygulanan ve gerektiğinde güncellenen bütünleşik süreçlerdir.
Şekil-4 – Plan-Do-Check-Act PMBOK Rehberi Süreç Grupları
Proje yaşam döngüsü gibi PMBOK ile tanımlı süreç grupları da çevik yaklaşımların proje, sürüm ve iterasyon seviyesinde uygulanan süreçler ile birebir örtüşmektedir.
 
Şekil-5 - Süreç Grupları ve Agile Fractal
Sonuç olarak; PMBOK Kılavuzu proje yönetiminde bilinen iyi pratikleri ve genel kabul gören standardları içermektedir.  Bu standardlar belirli bir metodolojiye özel oluşturulmamıştır. Maalesef, PMBOK ile sunulan pratikler ile yazılım geliştirme alanındaki farklı metodolojiler, özellikle şelale metodu birbiri ile ilişkilendirilmekte ve PMBOK Kılavuzunun şelale yaklaşımlara uygun pratikler sunduğu düşünülmektedir. Aslında doğru olan PMBOK Kılavuzu ile yazılım geliştirme metodolojileri karşılaştırmak değil, yazılım geliştirme metolodojilerini kendi aralarında kaşılaştırmaktır. Çevik yaklaşımlar uygulanırken de PMBOK ile sunulan genel kabul gören pratikleri ve önerileri dikkate alabiliriz.

Bir sonraki yazımızda; Çevik Proje Yönetimi ve Geleneksel Proje Yönetimi (şelale metodlara dayalı) yaklaşımları arasındaki temel farklılıkları “Agile Manifesto” ve prensiplerini dikkate alarak örneklerle açıklamaya çalışacağım.

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.

Sorumluluk Süreci (The Responsibility Process)

Agile felsefesinin temelinde kendi kendine organize olan takımlar yer almaktadır. Bu karakteristiğe uygun takımların oluşması zaman gerektiren bir süreçtir. Kendi kendine organize olabilen takımlar, bireysellikten daha çok, takım olgusuna sıkı sıkıya bağlıdırlar. Sorumluluk almaktan kaçınmazlar. Başarıyı ve başarısızlığı hep birlikte karşılarlar. 
 
Günümüz iş dünyasında, özellikle Agile felsefesinin benimsenmediği ortamlarda, en üst düzey yöneticilerden, en alt seviye takım üyelerine kadar tüm çalışanlarda, sorumluluk alma süreci ile ilgili bir çok problemle karşılaşmaktayız. Başarıların yöneticiler tarafından sahiplenildiğini, başarısızlıkların ise alt seviye çalışanlara fatura edildiğini hepimiz günlük hayatımızda sıklıkla tecrübe ediyoruz.
 
 
Sorumluluk alma yetisinin aslında bir karakter özelliği veya kusuru olduğu düşünülür. Aksine her insanda aynı şekilde işleyen mental bir süreçtir. Bu süreç gözlemlenebilir, öğrenilebilir ve geliştirilebilir. Bu süreci öğrenebilmek için NİYET, FARKINDALIK ve YÜZLEŞME anahtar unsurlardır.
 
Christopher Avery tarafından oluşturulan Sorumluluk Süreci, insanların sorumluluk almak ve sorumluluktan kaçmak ile ilgili düşünceleri nasıl işlediğini gösterir. Bu süreç alan çalışmalarından elde edilmiştir. Bu sürecin farkında olmak, öğrenme süreciniz için bir çerçeve sunar. Siz de süreci tanımlayan bu posteri, takımınızın bulunduğu ortama asarak bu sürecin ilk adımlarını atabilirsiniz.
 
Bu arada belirtmekte fayda var, yakın bir gelecekte Christopher Avery'nin kendisini bir liderlik çalıştayı için Türkiye'de görebilirsiniz. Şimdiden bu müjdeyi vermiş olalım.
NOT: Orjinal versiyonu Christopher Avery tarafından hazırlanan posterin Türkçe çevirisi Barış BAL tarafından gerçekleştirilmiştir.

İstanbul Yazılım Yöneticileri Zirvesi David J. Anderson'u Ağırlıyor!

İstanbul Yazılım Yöneticileri Zirvesi konferansı, 8 Kasım 2014 Cumartesi günü Bahçeşehir Üniversitesi Beşiktaş Kampüsü'nde gerçekleştiriliyor. Lean - Kanban University kurucusu David J. Anderson'un ana konferans konuşmacısı olduğu etkinlikte, Dimitar Bakardzhiev, Joshua Arnold, ve Lemi Orhan Ergin gibi ünlü konuşmacılarda yer alıyor.
 
Scrum Turkey olarak destekçileri arasında bulunduğumuz etkinliğe katılım ücretsizdir. Etkinlikle ilgili tüm detaylara etkinlik web sayfasından ulaşabilirsiniz.
 
 

David J. Anderson Kimdir?

 
David J. Anderson, teknoloji geliştirme yönetimi konusunda dünyanın önde gelen liderlerinden bir tanesidir. Kendisi danışmanlık, eğitim ve yazılım dünyası için çok değerli sürdürülebilir yönetim yaklaşımları geliştirmektedir.

David J. Anderson, yazılım sektöründe 30 yıllık tecrübeye sahiptir. Motorola ve Microsoft gibi dünyaca ünlü bir çok firmalarda çevik yaklaşımlarla yıllarca büyük yazılım takımlarına önderlik yapmış bir liderdir.

Tam ismi "Kanban for Software Developement" olan, ancak yazılım dünyasında kısaca Kanban olarak bilinen yöntemin yaratıcısı olarak kabul edilmektedir. Lean ve Kanban yaklaşımları yaygınlaşmasını amaçlayan Lean - Kanban Üniversitesi'nin kurucusudur.

Agile Leaders Etkinliği - Episode 3

Agile Leaders etkinliği devam ediyor! Etkinliğimizin üçüncü bölümünde 5 Kasım 2014 Çarşamba günü, saat 19.00'da Optimist Payments Consulting kurucusu Hakan Erdoğan bizlerle olacak. Bu bölümümüzde "Agile Pratikler ve Girişimcilik" 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 Hakan Erdoğan'a yöneltmemizi istediğiniz soruları #AgileLeadersST etiketi ile Twitter üzerinden paylaşabilirsiniz.
 
 
Hakan Erdoğan Kimdir?


 
Hakan has 7 years of experience in Payment Systems in different views and accomplishments such as core software development and management positions.
 
He has developed SOA based payment systems of GittiGidiyor / eBay in 2007. He also developed and managed iPara alternative payment system with his highly qualified team in 2011.
 
Hakan contributed in business development, brainstorming, UX design and architectural design of many alternative payment systems in Turkey. He also adapted many alternative payment systems in Otto Group Private Shopping e-commerce site (Limango)'s checkout page with his team.
 
He began his career in 2005 at Eteration A.S. as Software Engineer based on JavaEE and SOA consultancy. He has worked as Senior Software Engineer (2007-2008), as Software/Product Development Manager (2008-2012) at GittiGidiyor / eBay and as IT Director (2012-2014) at Limango/Otto Group for the last 7 years.
 
He has started his own business, Optimist Payment Consulting in April 2014 to help companies about payment solutions, basket conversion optimization, payment systems integration, architectural infrastructure setup, training and mentoring who accept payments over internet.
 
He is sharing his experiences as an author in his Turkish Payment Systems blog odemesistemleri.org, and as an instructor in various programs and lectures.

Serçelerimiz Belirlendi!

Uzun ve yorucu bir değerlendirme süreci sonunda Agile Sparrow programının ilk katılımcıları belirlendi. Bu sürecin bu kadar zor olacağını hiç düşünmemiştik! Başvuru yapan yaklaşık 150 arkadaşımıza çok teşekkür ediyoruz.


İşte Serçelerimiz!

Ankara Takımı
Burcu Sarı - Bilkent Üniversitesi
Simge Erzurumlu - Bilkent Üniversitesi
Mustafa Can Kurnaz - Ondokuz Mayıs Üniversitesi
Uğur Temiz - ODTÜ
Asena Ok - ODTÜ

İstanbul Takımı
Elif Şenyürek - İTÜ
Esma Mine Türkyılmaz - İTÜ
Çiğdem Yakıcı - İTÜ
Muhammed Özdemir - Doğuş Üniversitesi
Mesut SARAN - YTÜ

İzmir Takımı
Mustafa Melih Karaduman - İzmir Yüksek Teknoloji
Mert Can Kurum - Dokuz Eylül Üniversitesi
Gözde Karadağ - Yaşar Üniversitesi
Kaan Burak Şener - İzmir Üniversitesi
Erdi İzgi - İzmir Üniversitesi
 
Etkinliklerimizle ilgili bilgilere Twitter ve Facebook sayfaları üzerinden ulaşabilirsiniz. Görüşmek üzere.

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

Agile Leaders etkinliğinin 2. bölümü gerçekleştirildi. Bu bölümdeki konuğumuz Burcu Güzel'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ı vb. bize Twitter üzerinden #AgileLeadersST etiketiyle iletebilirsiniz.


Agile Leaders 3. bölümü 5 Kasım 2014 tarihinde gerçekleştirilecek. Detaylarını önümüzdeki günlerde yayınlayacağız. Görüşmek üzere.

Agile Dönüşüm - Şelaleden Çevikliğe : Agile Geçişi

Yazarımız Yelda Gürbüz Erdoğan'ın ilk blog yazısı sizlerle.

Şelaleden Çevikliğe : Agile Geçişi

Bir yazılım şirketinin geleneksel yazılım geliştirme yaşam döngülerinden bir hayır gelmediğini (!) düşünüp, yepyeni bir yöntem denemeye karar veren şirketlerden bir tanesinden bahsedeceğim. Bu şirketin kesinlikle sizin şirketiniz olmadığını da şimdiden belirteyim :)

Sıradan bir şirkette yaşanlar:
  • 2 aylık proje için 2 ayda sözleşme hazırlanıyor :/
  • Test süreci (hiç) bitmiyor!
  • Gerçek ortamda patladık!!!
  • Doküman hazırlamaktan iş yapamıyorum
  • Benim makinamda çalışıyor.
Peki çevik (agile) yöntemler?

Dönüşüm ihtiyacı ya da Varolan Problemler / Agile Evrilme

Yapılan operasyonel işlerde ya da projelerde aşağıdaki problemlerden hangilerini yaşadınız?

  • Projenin zamanında bitmemesi
  • Fazla mesai saatlerinin "düzenli olarak" planlanması
  • Bir çok değişiklik isteğinin ortaya çıkması
  • Ortaya çıkan bu değişiklik isteklerinin hepsinin kabul edilmesi -ve fakat ek hiçbir kaynak sağlan(a)maması
  • Tüm bu değişiklik isteklerinin kabul edilmesine rağmen müşterinin mutsuz olması
  • Çalışanların motivasyonlarının düşmesi ve mutsuz olmaları
  • Müşteriye teslim edilen ürünün her zaman beklenen şekilde çalışmaması
Bunlardan birini ya da bir kaçını yaşıyorsanız eğer "Agile yapalım" cümlesi de sizin hayatınızda duyduğunuz cümlelerdendir.
Peki bu sorunların kök sebebi gerçekten sadece geleneksel yöntemle iş yapmanızdan mı kaynaklanıyor acaba? Kök sebep fazla bürokrasi de olabilir, tüm proje süreçlerinizi deyim yerindeyse "kafanıza göre yapmaktan" da kaynaklanabilir, genel geçer yöntemlere kulak tıkamanız da bir neden olabilir.
Görünen o ki, sorunlarınızın kaynağını bulmak yerine agile yöntemlere evrilmek daha kolay geliyor size. Peki, bu girişi unutmayalım ve agile dönüşüm çalışmamıza başlayalım. Daha sonra bu konuya tekrar döneceğimizi de belirtelim.
Agile Dönüşümü ile ilgili olarak ilerleyen günlerde aşağıdaki başlıkları inceleyeceğiz.


Bir sonraki yazımızda görüşmek üzere.

Yeni Yazarımız: Yelda Erdoğan

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 Yelda Gürbüz Erdoğan'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.
Yelda Gürbüz Erdoğan
Yelda Gürbüz Erdoğan, İstanbul Teknik Üniversitesi Uzay Mühendisliği bölümünden 1998 yılında mezun oldu. Görev aldığı projelerde kalite yönetimi, sistem kurma, süreç analizi, konfigürasyon yönetimi, gereksinim yönetimi, proje yönetimi, proje dokümantasyonu ve çeşitli standartlarla ilgili deneyim kazandı. Bahçeşehir Üniversitesi, Mühendislik Yönetimi yüksek lisansını 2012 yılında tamamladı. Halen Huawei şirketinde Kalite ve Süreç Mühendisi olarak çalışmaktadır.
Erdoğan, merkezi ABD'de bulunan Project Management Instute (PMI) üyesi olup, bu kurumdan PMP (Project Management Professional) ve PMI-ACP (Agile Certified Practitioner) derecelerine sahiptir.

Adaptasyon ve Agile Organizasyonlar

Yazarımız Sevgi Korkmaz'ın ilk blog yazısı sizlerle.
 
 
Adaptasyon veya uyum, doğal seleksiyonda (doğal seçilim) başarılı olmuş, ona sahip olan organizmayı evrimsel olarak daha uyumlu kılan bir özelliktir. Sıfat olarak, yani böylesi bir özelliği tarif etmek için, adaptif (uyabilen) terimi kullanılır. Adaptasyn, yapısal, davranışsal veya fizyolojik olabilir.
 
Çevrelerine yeterince uyum sağlayıcı adaptasyonlara sahip olmayan organizmalar ya bulundukları ortamdan gitmek zorunda kalırlar ya da soyları tükenir.
 
Organizasyonları organizmalara benzetirsek, yukarıdaki paragrafları yeniden şöyle yazabiliriz:
 
Adaptasyon veya uyum, doğal seleksiyonda (doğal seçilim) başarılı olmuş, ona sahip olan organizasyonu evrimsel olarak daha uyumlu kılan bir özelliktir. Sıfat olarak, yani böylesi bir özelliği tarif etmek için, adaptif (uyabilen) terimi kullanılır. Adaptasyon, yapısal, davranışsal veya teknolojik olabilir.
 
Dünyanın çevresel koşullarının değişme hızı nedeniyle organizmalardaki adaptasyona günlük hayatımızda şahit olmamız belki çok mümkün değil ama söz konusu organizasyonlar olduğunda adaptasyon ve doğal seleksiyon örneklerini günlük hayatımızda gözlemlemek mümkün. Özellikle son 10 yılda, çevresel/piyasa koşullarının değişim hızının artması nedeniyle organizasyonlar sürekli olarak yapısal, advranışsal ve teknolojik değişiklikler yapmak zorunda.
 
Değişen çevre/piyasa koşullarına hızlı adapte olabilen, fırsatları değerlendirebilen firmalar, bu fırsatları kara dönüştürebilirken, değişime ayak uydurmada yavaş kalan firmalar rekabette geride kalmakta ve belki hayatlarına devam edememekteler.
 
İlerlemenin ve gelişmenin en hızlı olduğu bilgisayar teknolojileri departmanlarında adaptasyon becerileri ilk olarak kendisini, hızlı teslimat, hatasız teslimat, değişikliği kabul edip uyarlama, sürekli iyileştirme olarak ortaya çıktı. Standart yönetim şekillerinin bu ihtiyaçları karşılayamaması ardından daha çevik süreçler benimsendi ve sürekli adaptasyon ile başarının devamı sağlandı.
 
 
Teknolojinin ilerlemesi, internetin ve akıllı cihazların yaygınlaşması, ülkeler üstü marketlerin oluşmasına ve var olan ticari yaklaşımların sürekli değişmesine yol açtı. Şirketlerin iş yapış şekilleri artık teknolojik altyapılarının yetenekleri ile sınırlanıyor. Teknolojik altyapılarına bağımlılık nedeniyle yazılım sektöründe ortaya çıkan çevik yaklaşımların artık sadece yazılım ve teknoloji departmanlarının değil, bütün şirket kültüründe uyarlanması gerekiyor.
 
Çevik prensiplerin organizasyonların adaptasyon becerilerini nasıl artıracağını bir kaç “Çevik Prensipler”’in üzerinden geçerek değerlendirirsek.
 
Çevik Firmalar, müşterilerini kendileri için değerli ürünleri erken ve devamlı olarak teslim ederek memnun eden firmalardır.
 
Çevik Firmalar, ürün altyapılarını ve ürün geliştirme süreçlerini değişikliğin az maliyetli şekilde yapılabilmesine olanak verecek şekilde yatırım yapan firmalardır. Ürünlerin modüler tasarımı, çok biçimli kullanımı, bağlılığın az olması adaptasyon yeteneğini artıracaktır. Örnek olarak : Mutfak tasarımında modüler ve çok kullanıma sahip ünitelerin desteklediği çözümlerde, müşteri isteklerini değiştirebilmekte ve hızlı teslimat yapılabilmektedir.
 
Çevik Firmalarda insanlar süreçlerden daha önemlidir. Projelerin ve süreçlerin temelinde motive olmuş bireyler yer almaktadır. İşi başaracakları konusunda güven duyulan bu bireylere ihtiyaçları olan ortam ve destek sağlanır. Yorgun beyinler, hızlı ve efektif çözüm üretemezler. Motivasyonu yüksek çalışanların, verimli çalışması sonucunda daha akıllı kararlar alınabilir. Bu nedenle çevik firmalarda çok çalışma yerini verimli çalışmaya bırakacaktır. Yine ekiplere kendini örgütleme ve kendi işi ile ilgili karar alma yetkisi verilmelidir.
 
Önümüzdeki yıllarda değişimin ivmesinin artacağını tahmin etmek hiç zor değil. Hangi sektörde olursa olsun, organizasyonların hayatta kalmasında değişikliğe ve ilerleyen teknolojiye uyum sağlama becerileri başarı ya da hayatta kalma açısından önemli olacaktır. Çevik süreçleri şirket kültürüne dahil edebilen firmaların bu yetenekleri artıracaklardır.

Spotify Agile Kültürü - Video Versiyonu

Çok kısa bir süre önce sizlerle Süreçlerini İnceleyelim yazı serisinde Spotify Agile Kültürü ile ilgili bir çeviri paylaşmıştık. Bu makalenin yazarı Henrik Kniberg hazırlamış olduğu yazının yanı sıra, 2 bölüm halinde yayınladığı bir video hazırladı. Bu videoları sizlerle paylaşmak istiyoruz. Keyifli seyirler.
 
Spotify Agile Kültürü - Bölüm 1
 


 
 
Spotify Agile Kültürü - Bölüm 2
 

Agile Leaders Etkinliği - Episode 2

Agile Leaders etkinliği devam ediyor! Etkinliğimizin ikinci bölümünde 15 Ekim 2014 Çarşamba günü, Tmob'dan Burcu Güzel bizlerle olacak. Bu keyifli sohbeti kaçırmayın!

 
Canlı yayın sırasında Burcu Güzel'e yöneltmemizi istediğiniz soruları #AgileLeadersST etiketi ile Twitter üzerinden paylaşabilirsiniz.


Burcu Güzel Kimdir?


 
Burcu Güzel, 9 Eylül Üniversitesi, Bilgisayar Mühendisliği bölümünü 2003'te bitirmiştir. 2005 yılına kadar Meteksan Net - Ankara'da Java yazılım mühendisliği görevinden sonra İstanbul'da Netaş'ta çalışmaya başlamıştır. Netaş'ta geçen 8.5 senelik yazılım mühendisliği, Java web teknolojileri yazılım mimarlığı, agile/scrum yöneticiliği (ScrumOfScrums Master) ve departman yöneticiliği görevlerinin ardından mobil dünyaya Tmob'la birlikte geçişini yapmıştır.
 
Tmob'da mobil teknolojiler, yazılım geliştirme ve test metodolojileri ve işleyişleri konusunda yönetici olarak çalışmalarına devam etmektedir. Kurumsal mobil hizmetler konusunda agile proje ve sürüm yönetimi, yazılım geliştirme alanlarında sürekli iyileştirme ile birlikte pazar yeniliklerine kendini ve şirketini hep daha iyiye taşıma konusunda çalışmaktadır.

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.