Management 3.0 Eğitimi

Geleneksel çevik süreçler eğitimlerinden sıkıldınız mı? O zaman bu eğitim tam size göre! ScrumTurkey olarak büyük uğraşlar sonucunda dünyanın sayılı Agile Coach'larından olan Jurgen Appelo'yu Türkiye'ye gelmeye ikna ettik ve Management 3.0 kursunu 29 - 30 Ocak 2013 tarihlerinde Ankara'da düzenleyecek. Bu büyük fırsatı kaçırmayın!
 

For English description of the course, please follow this link
 

Management 3.0 Agile Leadership Practices Eğitimi Türkiye'de
 
Eğitim İçeriği
 
Çevik Yönetim (Agile Management) genellikle çevik yöntemlerin gözden kaçan kısmıdır. Çevik yazılım ve test mühendisleri, ve proje yöneticileri için yeterince bilgi bulunurken, geliştirme yöneticileri ve takım liderleri için çok az bilgi bulunmaktadır. Ancak bir organizasyon çevik yazılım geliştirmeye adapte olurken, yeni pratikleri öğrenme ihtiyacı olanlar sadece geliştiriciler, test mühendisleri ve proje yöneticileri değildir. Geliştirme yöneticileri ve takım liderleri de mutlaka çevik organizasyonları yönetme ve rehberlik etme yaklaşımını öğrenmelidirler.
 
 
Bir çok çalışma göstermiştir ki, eski tip yöneticiler, Çevik Yazılım Geliştirme dönüşümlerinde en büyük engeldir. İşte bu nedenle Geliştirme Yöneticileri ve takım liderleri de çevik yazılım geliştiren organizasyonlardaki yeni rollerini öğrenmelidirler. Bu 2 günlük kurs geliştirme yöneticileri, takım liderleri, proje yöneticileri, ve ileride çevik yazılım geliştirme yapılan organizasyonlarda yöneticilik yapmak isteyen herkes için tasarlanmıştır.
 
 

Hedef Kitle

Management 3.0 eğitimi, çevik zihniyeti benimsemek isteyen girişimcileri, liderleri, yöneticileri, bilgi işçilerini ve organizasyonlarda liderlik ve yönetim süreçlerine dahil olan diğer paydaşları hedeflemektedir.



Management 3.0 eğitimine katılanların dağılımı şu şekildedir: Takım Liderleri (%15), Yöneticiler (%15), mentörler ve girişimciler (%15), Scrum Master’lar (%15), Proje Yöneticileri (%10), Ürün Sahibi (Product Owner) ve Ürün Müdürleri (%10), yazılım ve test mühendisleri (%10) ve üst seviye yöneticiler (%10)

 
Eğitimin Amaçları

Konular (Gün 1)
  1. Çevik Yazılım Geliştirme, yazılım geliştirme takımları için yeni altın standarttır. Bu konu başlığı altında farklı çevik metodolojileri, popüler en iyi pratikleri, yazılım projelerinin 7 boyutunu, dünyadaki çevik metodolojilere adaptasyon süreçlerindeki zorlukları ve yöneticiler ile takım liderlerinin çevik organizasyonlara katkılarını öğreneceksiniz.

  2. Çevik anlayışın köşe taşları Karmaşıklık Bilimi ve Sistem Düşüncesi'dir. Bu konu başlığı altında nedensel döngü diyagramını, karmaşıklık teorisinin ne olduğunu, sistem bakış açısı ile nasıl düşünüleceğini, karışık ile karmaşık arasındaki farkı, ve geleneksel lineer düşünme yönteminde farkına vardığımız 7 yanlış düşünceyi öğreneceksiniz.

  3. İnsanlar bir organizasyonun en önemli parçalarıdır ve yöneticiler insanların faal,yaratıcı ve motive kalmaları için ellerinden geleni yapmalıdır. Bu konu başlığı altında içsel ve dışsal motivasyon arasındaki farkı, 10 içsel arzu, takımlarınızdaki insanlara göre neyin önemli olduğunu anlamak için yaygın teknikleri, birebir görüşme, kişisel degerlendirmeler, en önemli 12 soru ve 360 derece görüşme tekniklerini öğreneceksiniz.

  4. Takımlar kendi kendine organize olabilmeye muktedirdirler. Bu durum imkan verme, yetkilendirme ve yönetici güveni gerektirir. Kendi kendine organize olmanın nasıl yapılacağını, bir organizasyonda yetkinin nasıl dağıtılacağını, yetkilendirmedeki zorlukları, güven ilişkilerinin nasıl geliştirileceğini ve dağıtımlı kontrol için birkaç yöntemi, yetkilendirmenin 7 aşaması ve otorite kurulları gibi konuları öğreneceksiniz.
 
 
Konular (Gün 2)
  1. Kendi kendine organizasyon, hiçbir şeye öncülük edemez, bu yüzden, insanları ve paylaşılan kaynakları korumak ve insanlara net bir hedef ve tanımlı amaçlar vermek gereklidir. Bu başlık altında ne zaman yönetmeli, ne zaman liderlik etmeli, tarafsızların yönetim etrafındaki itirazları hakkında faydalı amaçlar oluşturmak için farklı ölçütler nasıl kullanılmalı, insanları ve paylaşılan kaynakları kendi kendine organizasyonun kötü etkilerinden nasıl koruyacağınızı ögreneceksiniz.
     
  2. Eğer takım üyeleri yeterince yetenekli değilse, takımlar amaçlarına ulaşamazlar. Bu yüzden yöneticiler yetkinliklerin gelişmesine katkıda bulunmalıdırlar. Bu konu başlığında yetenek ve disiplin aşamaları, yetkinlik gelişiminin yedi yaklaşımına nasıl ve ne zaman başvurulacağını, karmaşık bir sistemde gelişimin nasıl ölçüleceğini, nesnel optimizasyon etkisi ve faydalı ölçümler için birkaç ipucu ögreneceksiniz.
  3.  
  4. Bir çok takım karmaşık organizasyon yapısında çalışır ve bu nedenle iletişimi geliştirici yapıları dikkate almak önemlidir. Bu konu başlığında organizasyonel yapının nasıl geliştirileceğini, özelleştirme ve genellemeyi nasıl dengeleyeceğinizi, gayri resmi liderlik ve ünvanları genişletme ve takımları degerli bir ağda değerli birimler olarak ele alma hakkına, fonksiyonel ve çapraz fonksiyonel takımlar arasında nasıl seçim yapılacağını öğreneceksiniz.
     
  5. İnsanlar,takımlar ve organizasyonlar başarısızlığı mümkün olduğunca uzun süre ertelemek için sürekli olarak gelişmeye ihtiyaç duyarlar. Bu pratikte şu anlama gelir; yöneticiler ve liderler etraflarındaki sosyal karmaşık sistemi değiştirmeye çalışan değişim etkenleri olarak hareket etmek zorundadırlar. Bu başlık altında değişim yönetiminin sistem, bireyler, etkileşimler ve sistemin sınırlarını kapsayan 4 boyutunu ögreneceksiniz.

Oyunlar ve Uygulamalar
 
Yukarıdaki 8 başlığın her biri, katılımcıların beş veya altı kişilik gruplar halinde eğitimin fikirlerini uygulamaya koyabileceği en azından bir oyun veya uygulama içerir. Bu oyunlar ve uygulamalar sayesinde katılımcılar bazen birbirlerine karşı farklı yöneticiler olarak oynayacaklar, bazen hep birlikte bir problem üzerinde çalışırken farklı düşüncelerini paylaşan birer yönetici olarak davranacaklar.

 
 
 
 Trainer
 

Jurgen Appelo, Hollandalı konuşmacı, yazar, çizer, okur, eğitmen, girişimci, geliştirici, yönetici, blogger, lider, hayalperest ve özgür düşünen...
2008’den bu yana çok popüler olan www.noop.nl isimli blogta yazmaktadır. Blogunda Çevik Yönetim, Yazılım Mühendisliği, İş Süreçlerinin İyileştirilmesi, Kişisel Gelişim, ve Karmaşıklık teoremi ve daha bir konuyu ele almaktadır. Management 3.0: Leading Agile Developers, Developing Agile Leaders isimli kitabın yazarıdır. Bu kitapta yöneticilerin Çevik ve Yalın organizasyonlardaki rolünü anlatmaktadır. Ayrıca How to Change the World isimli küçük kitabında yazarıdır. Bu kitabında Değişim Yönetimi üzerine tanımladığı modeli anlatmaktadır.
 
Jurgen Appelo aynı zamanda dünyadaki bir çok iş semineri ve konferansa davetli konuşmacı olarak katılmaktadır.



Iran Agile Konferansı 2013

Iran Agile Konferansı 2013, İran'da düzenlenecek olan ilk özelleşmiş çevik yazılım geliştirme konferansıdır. Konferans birbiriyle ilişkili olan yazılım geliştirme, yönetim, inovasyon ve girişimcilik konularındaki çevik değerler ve prensipler üzerine yoğunlaşmıştır.
 
 
Etkinlik 19 Şubat 2013 tarihinde İran'ın başkenti Tahran'da, "Institute for Productivity and Human" da gerçekleştirilecektir. 1 gün boyunca sürecek etkinlikte 10'dan fazla oturum ve çalıştay düzenlenecektir.
 
Konferansta Organizasyon, Takım, ve Müşteri konuları işlenecektir. Bu üçü birbirini bilmeselerde ortak bir amaçları olmalıdır. Konferansta bu üç farklı yapının farklı vizyonlarının nasıl birleştirileceği ve bu üç farklı yapı için etkin işbirliğinin nasıl olması gerektiği konuları tartışılacaktır. Deneyimlerinizi paylaşmak ve katılımcıların fikirlerinden faydalanma fırsatını kaçırmayın.
 
Scrum Alliance'ın ana sponsorlarından, Scrum Turkey'nin topluluk sponsorlarından biri olduğu konferansın konuşmacıları, önemli tarihleri ve diğer detaylı bilgilere buradan ulaşabilirsiniz.

Ankara JUG Aralık Ayı Etkinliğindeydik

Ankara JUG'un düzenlemiş olduğu Aralık ayı etkinliğine katıldık. Etkinlik Bilkent Cyberpark Dr. Fikret Yücel Konferans Salonu'nda gerçekleştirildi.

 
"Agile, Adaptasyon ve Dönüşüm" başlıklı sunumumuzu paylaştığımız etkinliğe, T2 Yazılım da, Planning Poker kartları hediye ederek katkıda bulundu. Etkinlik katılımcılarının paylaşımları ile keyifli ve sıcak geçen organizasyon yaklaşık 1 saat sürdü.
 

Etkinlikle ilgili detaylı bilgilere Ankara JUG sayfasından ulaşabilirsiniz.
Etkinlikte gerçekleştirdiğimiz sunum dokümanlarına buradan ulaşabilirsiniz. Dokümanları kaynak belirterek ücretsiz olarak kullanabilirsiniz.

Bilkent IEEE Mobil Günler Konferansındaydık

Bugün Bilkent Üniversitesi IEEE Student Branch'in düzenlediği Mobil Günler konferansındaydık. Konferans genel olarak Mobil Teknolojiler ile ilgili olmasına rağmen, bir bölümü de Agile Metodolojilere ayrılmıştı. Bilkent IEEE grubuna bizi davet ettikleri için teşekkür ediyoruz.
 
 
"Agile, Adaptasyon ve Dönüşüm" başlıklı sunumumuzu paylaştığımız ve T2 Yazılım'ın da, Planning Poker kartları hediye ederek katkıda bulunduğu etkinlik, Bilkent Üniversitesi Güzel Sanatlar Fakültesi Binası'nda gerçekleştirildi. Etkinlik katılımcılarının paylaşımları ile daha da keyifli geçen organizasyon yaklaşık 1 saat sürdü.
Geri bildirim kapımız aracılığı ile düşüncelerini paylaşan katılımcılarımıza da ayrıca teşekkür ediyoruz. Aşağıda bir kaç yorumu sizlerle paylaşmak istiyoruz:
 
  • "Sunum içerik bakımından gayet başarılıydı"
  • "Etkili, enerjik ve yararlı bir konuşmaydı. Teşekkürler :)"
  • "Sunum olarak gayet başarılı olarak değerlendirebileceğim interaktif bir sunum oldu. Teşekkürler"
  • "Sunumlarınızda ilginç bir teknik daha kazandırmak isterseniz PowerPoint yerine prezi.com kullanın çok faydasını görürsünüz. İyi Çalışmalar." - Normalde iPhone ve iPad kullanıyoruz sunumlarımızı gerçekleştirirken, bu sefer bizden kaynaklı bazı aksaklıklardan dolayı bu şekilde gerçekleştirmek zorunda kaldık. Ancak bunu da değerlendireceğim. Teşekklürler ;)
  • "Sunum başında bilgi almadınız. Yazılım geliştiren bir ekip içinde olmama rağmen sunum biraz fazla felsefik geldi. Teşekkürler." - Bu yorumu çok önemsiyoruz. Bundan sonraki konuşmalarımızda dikkate almaya çalışacağız. Çok teşekkür ederiz.

Etkinlikle ilgili detaylı bilgilere buradan ulaşabilirsiniz.
Bilkent IEEE Student Branch'i bu organizasyondan dolayı tebrik ediyor, başarılarının devamını biliyoruz.

Çevik Liderlik Pratikleri Eğitimi!

Jurgen Appelo tarafından Ankara'da 29 - 30 Ocak 2013 tarihlerinde düzenlenecek olan Çevik Liderlik Pratikleri Eğitimi (Management 3.0: Agile Leadership Practices Course) erken kayıt süresi için az bir süre kaldı. Sınırlı kontenjan dolmadan yerinizi ayırtın.



Geleneksel çevik süreçler eğitimlerinden sıkılanlar, bu eğitim tam size göre! ScrumTurkey olarak büyük uğraşlar sonucunda dünyanın en ünlü Agile Coach ve Eğitmenlerinden olan Jurgen Appelo'yu Türkiye'ye gelmeye ikna ettik. Kendisi Management 3.0: Agile Leadership Practices kursunu 29 - 30 Ocak 2013 tarihlerinde Ankara'da düzenleyecek. Bu büyük fırsatı kaçırmayın!
 
 
Eğitim detaylarına buradan, kayıt sayfasına buradan ulaşabilirsiniz.

Bugün Proje Yönetim Derneği Söyleşisi'ndeydik!


Bugün Proje Yönetim Derneği'nin söyleşisine konuk olduk. "Agile, Adaptasyon ve Dönüşüm" başlıklı sunumumuzu paylaştığımız ve T2 Yazılım'ın da, Planning Poker kartları hediye ederek katkıda bulunduğu etkinlik, ODTU Vişnelik Tesislerinde gerçekleştirildi. Etkinlik katılımcılarının paylaşımları ile daha da keyifli geçen organizasyon yaklaşık 2 saat sürdü.

Başta dernek başkanı Sn. Filiz Eser Hanım ve dernek başkan yardımcısı Sn. Sadık Nazik Bey olmak üzere, dernek üyelerine ve tüm katılımcılara Scrum Turkey olarak çok teşekkür ediyoruz.

Our New Logo

Our new logo is launched! I would like to thank to my colleague Cem Altun, he is a great designer!


 
You can support us publishing our logo on your web site!

Schneider Culture Model Assessment

What kind of culture does your organisation have? Do you want to assess it? This list is for you, you can use it to assess your culture characterictics based on the culture model of William Schneider.

Translated versions:
Translators: Here is the pptx original, feel free to translate and send me a link when you are done. In addition, you are welcome to provide any comments or feedback. I will be much appriciated.

 

WHAT IS THIS?

The Schneider Culture Model Assesment is a simple tool to help Agile Coaches to assess an organisation's current culture, or to use in workshops. If you use this assesment as a discussion tool, it can generate useful ideas that may help you during transformation process. Each culture model defined has a descriptive quote and some words. You can add your own words, and if you share it with me I can add them to the tool.

Thanks

I would like to thank to Michael Sahota and Henrik Kniberg for their valuable comment. This assessment document is based on the same idea of Henrik Kniberg's Scrum Checklist.

Schneider Kültür Modeli ve Dönüşüm

Bir önceki yazımda bahsettiğim gibi Schneider Kültür Modeli'nde 4 farklı organizasyon kültürü tanımı yapılmıştır. Bu kültürler ve özet tanımlarını şu şekilde yapabiliriz:
 
Collaboration (İşbirliği Kültürü): İşbirliği kültüründe esas olan değerler yardımlaşma, sinerji, güven ve ilişkilerdir.
Control (Kontrol Kültürü): Kontrol kültüründe esas olan değerler güç, süreçler, düzen ve standartlardır.
Cultivation (İşleme Kültürü): İşleme kültüründe esas olan değerler adanmışlık, amaç ve yaratıcılıktır.
Competence (Yetkinlik Kültürü): Yetkinlik kültüründe esas olan değerler en iyi olma, profesyonellik, ve uzmanlıktır.
Schneider Kültür Modeli, herhangi bir kültürün bir diğerinden iyi olduğunu belirtmez, sadece her bir kültürün avantajlarını ve dezavantajlarını tanımlar. Eksenler odak noktalarını belirlemektedir.
 
Bir organizasyonda başarılı bir kültür dönüşümü yapılması için uygulanmasını ve dikkat edilmesini önerdiğim bazı önemli ayrıntılar şunlardır:
  • Dönüşüm stratejsini belirlemek için, organizasyonun nasıl bir kültüre sahip olduğu tanımlanmalıdır. Hangi kültüre ait karakteristiklerin dominant olduğu belirlenmelidir.
  • Kültür dönüşümü yaşanırken öncelikle mevcut kültürün çalışmayan yönleri değiştirilmeye çalışılmalıdır. Daha sonra daha iyi olduğu düşünülen kültüre geçiş yapılabilmelidir.
  • Dönüşüm sağlanırken, öncelikle komşu kültürlere geçiş yapılması denenmelidir.
  • Bir organizasyonun farklı birimlerinde farklı kültürler olabilir.
  • Dönüşüm öncelikle küçük bir takım, birim veya bölümden başlanarak yapılabilir.
Burada anlatmaya çalıştığım kültür ve dönüşüm ikilisinin, Agile dönüşümlerle ilişkisini daha sonraki yazılarımda detaylı olarak anlatmaya çalışacağım.

Schneider Kültür Modeli Değerlendirme Listesi'ne buradan ulaşabilirsiniz.

Adaptasyon mu? Dönüşüm mü?

Agile Coach'ların ve eğitmenlerin sürekli kullandıkları bir kelime var: Adaptasyon! Bir organizasyonun Agile olabilmesi için adaptasyonun gerekli olduğunu tekrarlar, dururlar. Ancak bu bir kurumun Agile olabilmesi için adapte olmak yeterli midir? Bu soruyu derinlemesine incelediğimiz de sorunun cevabının "Hayır!" olduğunu göreceğiz. Peki Adaptasyon neden Agile olabilmek için yeterli değil? Sorunun cevabını bulabilmek için öncelikle adaptasyonun ne olduğunu biraz daha detaylandırmak ve Adaptasyon ile birlikte neler yapılması gerektiğine de değinilmesi gerekiyor.
 
Adaptasyon, bir kişinin, bir takımın, veya bir organizasyonun yaptığı şeyi, yani uyguladığı pratikleri değiştirmesi olarak tanımlanabilir. Bir örnekle açıklamak gerekirse, bir takımın veya organizasyonun mevcut yazılım geliştirme pratiklerini terk edip, "Continious Integration, Test Driven Development (TDD), Pair programming" vb. pratikleri kullanmaya başlaması Adaptasyon olarak adlandırılabilir.
 
Organizasyon kültürü dendiğinde, o organizasyonun bütün yaptıkları, davranışları vb. herşeyi anlaşılmalıdır. Bir organizasyonun kültürünü tanımlamak için literatürde bir çok model tanımlanmıştır. Bu modeller arasında benim en çok beğendiğim William Schneider'in kitabında tanımladığı modeldir. Bu modele göre 4 farklı organizasyon kültürü (Competence, Cultivation, Collaboration, Control) tanımı vardır. Bunların kısa detaylarına başka bir yazımda değineceğim. Peki Dönüşüm tam olarak nedir?
 
Dönüşüm, bir kişinin, bir takımın, veya bir organizasyonun kendisini değiştirmesi ve olduğundan farklı davranışlar sergilemesi olarak tanımlanabilir. Bir örnekle açıklamak gerekirse, bir organizasyon düşünün bütün çalışanlar en iyi olabilmek için yarışıyor, her kişi sadece kendi yaptıklarına odaklanmış durumdayken; birbirine yardım eden, bir işin sorumluluğunu paylaşan bir organizasyon kültürüne geçiş yapması Dönüşüm olarak adlandırılabilir.
 
Organizasyon, takım vb. davranışlarını değiştirmediği sürece istenildiği kadar Adaptasyon uygulansın, bu Agile olunmasını sağlamaz. Sadece pratikler değişir ama Agile zihniyeti oluşturulamaz. Agile zihniyeti oluşturabilmek için, yani Dönüşümü sağlamak için öncelikle organizasyonun kültürü tanımlanmalı ve kültürün değişmesi sağlanmalıdır. Özetlemek gerekirse Adaptasyon ve Dönüşüm birlikte uygulandığı zaman daha başarılı sonuçlar alınabilir.
 
Bir sonraki yazımda Schneider Kültür Modeli ve başarılı bir Dönüşüm sağlanması için nelere dikkat edilmesi gerektiğinden bahsedeceğim. Ayrıca Agile Coachlar'ın ve eğitmenlerin kullanabilecekleri, bir organizasyonun hangi kültür tanımına uyduğunu ortaya koymasına yardımcı olacak bir değerlendirme listesi hazırlamaktayım. Bu listeyi de burada paylaşacağım.

Ankara JUG Kuruldu!

Ankara ve çevresinde yaşayan Java ve Java tabanlı teknolojilerle ilgilenen profesyonelleri, akademisyenleri, öğrencileri vb. bir araya getirmeyi amaçlayan Ankara Java User Group (Ankara JUG) kuruldu. İlk etkinlik 22 Kasım 2012 - Perşembe günü Bilkent Cyberpark Dr. Fikret Yücel Konferans Salonu'nda, saat 19:00'da düzenlenecek.


 Etkinlik detayları ve kayıt için: Ankara JUG Kasım 2012 Etkinliği
Ankara JUG'a kayıt olmak için: Ankara JUG Kayıt

Scrum Checklist - Türkçe

Merhabalar,

Agile ve Scrum metodolojileri ile çok yakından ilgilenen, bir çok firmaya agile dönüşümlerinde yardımcı olan Henrik Kniberg'in Scrum Checklist'inin Türkçe çevirisini sizlere sunmaktan büyük mutluluk duyuyorum.

Dokümana buradan erişebilirsiniz: Scrum Checklist (Kontrol Listesi) - Türkçe


Herhangi bir hata, yazım yanlışı vb. durumunda benimle iletişime geçebilirsiniz. Geribildirimleriniz çok değerlidir.

Eğer dokümanın orjinal versiyonu ile ilgileniyorsanız, buradan ulaşabilirsiniz.

Bugün İş Kalesi'ndeydik!

Ankara'nın ilk ve tek co-working ve girişimcilik merkezi olan İş Kalesi eğitim organizasyonları düzenliyor. Bu eğitim organizasyonunun bir oturumunu Scrum Turkey olarak bize ayırdılar.
 
 
 
Yazılım fikirlerini hayata geçirmek isteyen girişimci arkadaşlarla, çok keyifli bir eğitim gerçekleştirdik. "Scrum'a Giriş" eğitimi ile Scrum hakkında temel bilgileri anlatmaya çalıştık. Yaklaşık olarak 3 saat boyunca Scrum üzerine çok keyifli sohbetler gerçekleştirdik. Scrum'ı projelerinde nasıl kullanabilecekleri konusunda bilgiler paylaştık.
 
 
Biz bu eğitimden çok keyif aldık. Bu organizasyona bizi davet eden ve bu fırsatı bize sağlayan İşkalesi ve yöneticilerine çok teşekkür ederiz...
 
İşkalesi'nin bilgilerine buradan ulaşabilirsiniz: www.iskalesi.com

Scrum Turkey, Scrum.org Onaylı Türkçe Scrum Kılavuzunu Yayınladı!




Uzun zamandır beklediğimiz bir haberi sizlerle paylaşmak istiyoruz. Ken Schwaber ve Jeff Sutherland tarafından orjinali geliştirilmiş ve sürdürülmekte olan Scrum Guide dokümanının Türkçe çevirisini yaptık. Yapmış olduğumuz çevirimiz Scrum.org tarafından onaylandı ve yayınlandı.
 
Scrum Klavuzlarına bu adresten ulaşabilirsiniz: Scrum Guides
Scrum Klavuzunun Türkçe çevirisine bu adresten ulaşabilirsiniz: Scrum Klavuzu - Türkçe
 
Biz Türkçe çeviriyi yaptık ama güncel tutabilmek için sizlerin yardımınıza ihtiyacımız var. Bu nedenle her türlü düzeltme önerinizi bekliyoruz. İsteklerinizi iletmenize yardımcı olacak yöntemi ilerleyen günlerde buradan paylaşacağız.
 
Çevirinin yapılması esnasında çevirmen ve gözden geçirme aşamalarında katkılarından dolayı, İbrahim GÜNTAŞ, Mert ÇALIŞKAN, Hakan SÖZER, Mustafa KESKİN, Alp EKŞİOĞLU, ve Kerem ÖZEN'e teşekkür ederiz.

Dünyayı nasıl değiştirirsin

A great presentation by Jurgen Appelo,  A meta-model for changing social complex systems, like teams and organizations. This topic is part of the Management 3.0 course.



Jurgen Appelo "How to change the World"

He will teach Management 3.0 course on 29th - 30th January 2013 in Ankara, Turkey. Do not miss this big chance!


Management 3.0 Agile Leadership Practices Eğitimi Scrum Turkey Katkılarıyla Türkiye'de

Uzun zaman sonra tekrar merhabalar! Yaklaşık 3 senedir kullanamadığım izin haklarımı kullandım, bu nedenle biraz ara vermek zorunda kaldık. Yeni dönemde Scrum Turkey olarak daha aktif olacağız. Yeni dönemde daha çok tecrübelerimizi paylaşacağımız yazılarımızla sizlerle birlikte olacağız.
 
Bu yeni dönemle birlikte size yepyeni bir eğitim imkanını sunmaktan gurur duyuyoruz. Geleneksel çevik süreçler eğitimlerinden sıkıldınız mı? O zaman bu eğitim tam size göre! ScrumTurkey olarak büyük uğraşlar sonucunda dünyanın sayılı Agile Coach'larından olan Jurgen Appelo'yu Türkiye'ye gelmeye ikna ettik. Kendisi Management 3.0 kursunu 29 - 30 Ocak 2013 tarihlerinde Ankara'da düzenleyecek. Bu büyük fırsatı kaçırmayın!

Eğitim detaylarına buradan, kayıt sayfasına buradan ulaşabilirsiniz.

Görüşmek üzere...

Definition of Done

Our author Faisal Mahmood discusses "Definition of Done" in this article. A clear "Definition of Done" is very important for success of the Sprint and should be visible to all stakeholders in the team.

"The Sprint has just ended. The team has completed a lot of work and they feel comfortable going into the review meeting. The Product Owner has been working with the team, although not on consistent basis, but the collaboration is getting better. The team has been asking quite a few questions and the Product Owner was able to answer most of those questions during the Sprint. The Product Owner has felt that the team has made good progress. The Definition of Done has been agreed a few Sprints ago and it’s been visible. The team has been keen to complete all the work according to the Definition of Done.

The review meetings kicks off. The team and the Product Owner discuss the work completed during the Sprint. The discussion is lively. The Product Owner looks excited. She starts to discuss about the release schedule and the road ahead.

The Product Owner asks enthusiastically, when can we ship? Suddenly, the mood starts to change. The comfort level goes down. Team starts to get edgy and Product Owner starts to get irritated. According to the team, they have completed the work according to their Definition of Done. But, it’s still not ready to be shipped. Further work is needed.

The Product Owner is confused and frustrated. She thought the work was done and ready to be shipped. The team explained what was already completed, and what remains to be done. Later it turns out, the team would require another three Sprints to complete all work to make the product increment shippable. Ouch!"

You can find the rest of the article here

How to become a great Product Owner?

Our author Faisal Mahmood discusses becoming a great Product Owner. Product Owner is a key role in Scrum framework. He gives the highlights in this article about this role.

"Of all three Scrum roles, the Product Owner is by far the most misunderstood role. What’s the core responsibility of the Product Owner? The typical answers that come out are
  • Product Owner tells the what team what to do
  • Product Owner defines the product and the Product Backlog
  • Product Owner clarifies the vision
Well, these are all valid activities that the Product Owner needs to carry out. The Product Owner role is associated with creating user stories, providing the team with the acceptance criteria, providing feedback in the review meetings. On top of all this, better Product Owners try to work with the team during the Sprints. But the key aspect of the Product Owner role is often forgotten.

The core responsibility of a Product Owner is to maximize value. If there’s one thing the Product Owner must do, that is to maximize product value."

You can find the rest of the article here

Sprint Zero - A Tool To Hide Waterfall Legacy

"Sprint zero is widely used antipattern to hide bigger and uglier issues. People using Sprint zero state different reasons for using Sprint zero. Some of the very common reasons include
  1. We don’t have a plan yet
  2. We don’t have a Product backlog
  3. We need to get a handle on architecture and design
We don’t have a plan yet
People are used to having a project plan outlining all the details. They think they ‘need’ these details to get started. People using Sprint Zero provide various combinations of reasons including the need to figure out schedule, deliverable, risks, assumptions, dependencies, resource plan and other such artifacts.

A heavy upfront planning phase is one of the biggest legacy of waterfall process. Having a plan calms nerves. It provides people with an illusion of control. They feel like they know what they are doing.
In Scrum, we do plan. However, we don’t spend a whole ‘Sprint’ or more just planning. We plan, we act and we adjust our plans as we move forward. This ‘thin’ planning upsets people. They get scared. They no longer have that ‘illusion of control’.

This fear leads to Sprint zero. During Sprint zero, they can ‘plan’. They can do almost all the things done at the start of a waterfall project while ‘doing Scrum’."

You can find the rest of the article here

Advantages of Agile and Scrum

A new article from our author Faisal Mahmood. He discusses advantages of Agile Methodologies and Scrum.

" Curious about benefits of Agile and Scrum?

Agile and Scrum enable you to
  1. Respond to market changes while controlling risk
  2. Increase ROI (return on investment)
  3. Continuously improve your process
  4. Increase quality of your products
  5. Work at a sustainable pace "
You can find the details and explanations of those items here

Is Agile for project delivery only?

This is the new article from our author Faisal Mahmood. He discusses the position of the Agility in the project lifecycle.

"In many organizations Agile is considered a solution to their project delivery problems. They are struggling with long delivery cycles, low quality and higher costs. Their competition is responding faster to customer needs and changing market dynamics and is releasing new features frequently.
The obvious solution they find is to adopt Agile in their delivery organization without changing any other part of the organization.

Traditionally, these organizations follow a well defined process which guides people how take an idea from vision till launch and maintenance. This process consists of cascade of phases, based on traditional processes. The number of step vary from one organization to another. Most organizations have three to five phases. These include..."

You can read the rest of the article here.

Scrum Master Hataları

Bazı Scrum Masterlar için hizmetkar lider rolüne sadık kalmak zordur. Bu Scrum Masterlar, sınırlı deneyim sahibi olmak ve organizasyonel desteğin az olması nedeniyle, iyi bildikleri geleneksel yönetim metodlarına geri dönüşte bulunurlar. Bilerek veya bilmeyerek, Scrum Masterlar bu tuzağa düşerler. Bu kişiler Scrum Master'dan daha çok bir Proje Yöneticisi gibi davranmaya başlarlar. Bu durum takımların kendi kendine organize olmasını zorlaştırır.

Buna neden olan bir çok Scrum Master hatası bulunmaktadır. Bu yazımızda bunların en önemli olarak gördüğüm 3 tanesini inceleyeceğiz:
  • Takım üyelerine iş ataması yapması
  • Takım adına kararlar alması
  • Geliştirme Takımı ile Product Owner arasında köprü vazifesi görmesi
Şimdi bu hataların detaylarını inceleyelim...

Takım Üyelerine İş Atamsı Yapmak
Daily Scrum toplantılarında, Geliştirme Takımı bir araya gelir ve günlük planlarını paylaşırlar. Bitirdikleri işleri, ve bir sonraki toplantıya kadar yapacakları işleri tartışırlar. Bir sonraki toplantıya kadar yapılacak işlerin Scrum Master tarafından atanması ve nasıl yapılacağının anlatılması, Scrum Masterların yapmaması gereken bir hatadır. Bu durum takımların kendi kendine organize olma yeteneğinin gelişmemesine veya körelmesine neden olur. Scrum Masterlar bu hatayı yaparak, eski tekniklerdeki Proje Yöneticisi gibi davranmaya başlamış olurlar.

Takım Adına Karar Almak
Geliştirme Takımları planlama toplantılarında veya Sprint süresince zor kararlar almak zorundadırlar. Scrum Masterlar geleneksel yöntemlerde olduğu gibi, bu tip kararlarda takımlar adına karar almamaları gerekir. Takımlar adına karar almaları durumunda takımın kendi kendine organize olmasını engellemiş olur. Bu durum takımın yaratıcılığını ve buna bağlı olarak üretkenliğini kısıtlar. Scrum Masterlar tasarım ve geliştirme konusunda çok tecrübeli olabilir ancak takım içerisinde karar verici olmamalıdırlar. Aksine takımı karar alma konusunda cesaretlendirmelidirler.

Takım ve Product Owner Arasında Köprü Olmak
Takım, Sprint Planlama toplantısında Sprint süresince yapılacak işleri belirler ve Sprint başlar. Geliştirme aktiviteleri başladıktan sonra, Geliştirme Takımı geliştirilecek yeteneklerle ilgili detay bilgiye ihtiyaç duyabilir. Scrum Masterlar, Geliştirme Takımı ile Product Owner arasında köprü olarak, bu bilgileri Product Owner'dan alıp, takıma iletmek gibi bir pratik uygulayabilirler. Bu yanlış bir pratiktir. Geliştirme Takımları, direk olarak Product Owner'a danışmalı, gerekli bilgileri bu kişiden almalıdırlar. Scrum Masterlar kendilerini Product Owner ile Geliştirme Takımı arasında taşıyıcı olarak değil, takımın içerisinde konumlandırmalıdırlar.

Scrum in 10 Minutes

A very good video which describes Scrum briefly. It is prepared by Hamid Shojaee. I would like to share it for you.

3 Reasons Why a Cross Functional Team is Hard to Find?

Another article from Faisal Mahmood which discusses about Cross Functional Teams. It's sometimes hard to understand the real meaning behind the term "Cross Functional". So this article is a very good discussion to understand that term.

" A cross functional Team is crucial to get items to Done. However, not many Agile Teams become a cross functional Team. Some of the most important reasons they struggle to become a cross functional Team are
  1. Waterfall setup of the organization
  2. Lack of required skills
  3. “Hard roles” on the Team
1. Waterfall Setup of the Organisation

This is typically caused by the way projects are financed and resourced. Finance and resourcing units in many organizations work traditionally, although these organizations have adopted Agile. The way project Teams are set up hinder Teams from becoming a cross functional Team.

In these cases, the project financing teams do not understand or appeciate Agile. They require detailed project scope, resourcing, cost and schedule information. They have set up their processes based on traditional waterfall model. They struggle to understand the Agile notion of an emerging requirement, namely, the Product Backlog, emergent architecture, Sprint, and self-organizing Teams.

Project Teams are forced to produce detailed requirements, to predict resourcing needs, and to predict schedules based on fixed scope."

You can find the details of other reasons here.

7 Reasons Why Your Team Does not Get to Done

A new article from our author Faisal Mahmood about the Scrum Development Teams. He discusses why teams do not achieve to get the things done. Teams run sprints and sprints. At the end they cannot deliver any shippable product. Faisal mentions seven reasons of it.

" Seven reasons lead to Teams not getting to Done
  1. Team is not cross functional
  2. Unclear or absent Definition of Done
  3. Technical debt
  4. Overworked Team
  5. Late integration
  6. Change of scope during Sprints
  7. Ineffective planning
1. Team is not cross functional
Non cross functional Teams tend to struggle with getting Done by the end of their Sprints. They simply lack skills to turn the selected items to Done increments of functionality. They might lack business analysis, design, development, testing, database design or any other such skills. Team members might be unwilling to learn anything other their own well defined roles.

In many cases Teams end up with a mini waterfall within their Sprints where initially the business analysts do the analysis and clarify the requirements, then the designers design, the developers develop and if there is time left at the end the testers test the system. In case they find issues at the end, and they usually do, those remain unfixed and are pushed to following Sprints. All this undone work is pushed to the following Sprints. They just struggle to get to Done.

All the undone work leads to long, painful and expensive “stabilization phase” at the end."

You can find the details of other 6 reasons here.

3 Reasons Why Scrum Masters Struggle to Become Servant Leaders

Another article from Faisal Mahmood about Scrum Master role. He discusses three reasons of the hard parts of becoming a servant leader. "Servant Leader" term is my favourite about Scrum Master role and I think that every Scrum Master must have this attitude.
"It seems it is rather hard for some of the Scrum Masters to stick to their servent leader role. This is one of the most common pitfalls. The lure of being a manager is too strong. Knowingly, or unknowingly people keep falling into this trap. They behave more like project managers than ScrumMasters.
Several symptoms indicate that the ScrumMaster is struggling to let the team self organize and thus acting more as a manager, than a ScrumMaster. Three keys ones are
  1. ScrumMaster assigns tasks
  2. ScrumMaster acts as go between the Team and the Product Owner
  3. ScrumMaster makes decisions on behalf of the team
We’ll use Sally, as an example ScrumMaster to explain this anttipattern."

You can find the rest of the article here.

3 Common Scrum Master Mistakes - Part II

This is the second part of the article 3 Common Scrum Master Mistakes - Part I from our author Faisal Mahmood. In this article he discusses the consequences of these mistakes, typical causes and a few ideas that can help you to avoid making these mistakes. We think that this is one of the best articles that we've read before about Scrum Master role.

"The Team becomes reliant on a single person making decisions on its behalf. It kills self-organization. The quality of the decision making takes a sound beating. The Team has to live with the decision made by one person instead of leveraging collective intelligence of all the Team members.

These decisions might work fine, at times, because of the individual experience of the Scrum Master. However, over the long term a single person struggles with making quality decisions on his or her own, compared with the Team conducting a healthy discussion and utilizing its collective experience and intelligence in making such decisions..."

You can find the rest of the article here.

Tech Leads will Rule the World?

Here is the next contribution of Assembla. As you can remember from their webinar, they have a different approach to Agile Methodologies. In this article, they discuss the necessity of Technical Lead role in an Agile Team who works in a distributed environment. They have the argument of that Agile Teams cannot afford management roles in the organisation. It's a very interesting discussion but as ScrumTurkey we still believe in some management roles like Scrum Master in Agile Teams. What do you think? Here is the article:

"At a Google office the other day, I heard someone say “Tech Leads make all the decisions at Google.” They also make the decisions here at Assembla. If you do distributed software development, they should be making the decisions at your company
A Technical Lead or Tech Lead is a software engineer who also leads a team. The Tech Lead picks the important tasks, answers questions, solves problems, assembles a release, helps new team members – and does development.
We think that distributed teams require Tech Leads. These teams communicate with code and other deliverables. They need to work with a developer who can read the code...."

3 Common Scrum Master Mistakes - Part I

Another article from our author Faisal Mahmood, he discusses common Scrum Master Mistakes. He mentions three common ones and he says that "That person is acting more as a manager than as a Scrum Master". This is the Part I of the article, we will share the others in the following days.

"It is difficult for some Scrum Masters to stick to their servant leader role. Because of lack of support and limited experience, they fall back on what they know best – traditional management. Knowingly, or unknowingly, Scrum Masters keep falling into this trap. They start to behave more as project managers than as Scrum Masters.
Several symptoms indicate that the Scrum Master is struggling to let the Team self-organize. That person is acting more as a manager than as a Scrum Master. Three keys symptoms are
  • the Scrum Master assigns tasks
  • the Scrum Master makes decisions for the Team
  • the Scrum Master acts as a go-between for the Team and the Product Owner..."
You can find the rest of the article here. Enjoy your reading.

Bu Retrospective Toplantısı Hatalarını Yapıyor Musunuz?

Merhabalar, bu yazımızla birlikte artık Scrum metodolojisinin detaylarına, daha ileri seviye konulara, uygulanması veya uygulanmaması gereken pratiklere vs. değinmeye çalışacağız. Bu yazı serimizi eğitmenimiz Faisal Mahmood'un katkıları ile hazırlıyoruz. Kendisine bir kez daha teşekkür ederiz. Bu yazımızda Retrospective Toplantıları ile ilgili yapılan bazı yanlışlar üzerinde duracağız:

Sürekli gelişim, Agile metodolojilerin kalbidir. Retrospective Toplantıları, geliştirme takımlarına süreçlerini gözden geçirme ve süreçleri sürekli olarak iyileştirme fırsatı sağlar. Bir çok geliştirme takımı bu avantajı kullanma konusunda başarısız olurlar. Bu nedenle süreçlerini geliştirme konusunda da başarısız olurlar.

Ortak olarak karşımıza çıkan Retrospective toplantısı hatalarını şu şekilde sıralayabiliriz:
  1. Gelişim Aktivitelerini Dikkate Almamak
  2. Seyrek Düzenlenen Retrospective Toplantıları
  3. Takım Katılımındaki Eksiklik
  4. Retrospective Toplantısına Sadece Bir Kişinin Öncülük Etmesi
Şimdi gelin bu hataların detaylarını inceleyelim:

Gelişim Aktivitelerini Dikkate Almamak
Gelişim aktivitelerinin dikkate alınmaması en çok karşılaşılan Retrospective hatalarından birisidir. Takımlar Retrospective toplantısına katılıp, süreçlerini iyileştirmek üzere fikirler üzerine dinamik bir şekilde tartışmalar yürütürler. Bu tartışmalarda sürecin çalışan yönleri ve problemli yönleri konuşulur. Fikir üretmek için bir çok yöntem kullanılır. Bu sayede fikir noksanlığı yaşanmaz, aksine bir çok fikir ortaya atılır. Bu sayede takımlar Retrospective bir düzine fikir üzerine tartışma fırsatı bulurlar. Fikirlerin tartışılması sonrası toplantı sonlandırılır. Takım gelecek Sprint süresince aksiyon alacağı maddeleri seçmez. Ne Scrum Master, ne de Geliştirme Takımı, tartışılan fikirleri not almazlar. Fikirler ve alınacak aksiyonlar toplantıda bırakılır.

Sonuç olarak, takımlar Retrospective Toplantısı sonuçlarının, Sprint süresince herkes tarafından görünür olması konusunda başarısız olurlar. Geliştirme Takımı Sprint ile ilgili geliştirme yapmaya başladığında, Sprint Backlog'ta tanımlı görevler içinde boğulurlar. Takım üyeleri bu arada Retrospective toplantısında neler tartışıldığını unuturlar. Çünkü bütün dikkatlerini ellerindeki işlere vermişlerdir.

Takım bir önceki Retrospective Toplantısında tartışılan iyileştirme fikirlerini uygulamazlar. Bu senaryo bir kaç Sprint devam eder. Takım pratiklerini iyileştirme yönünden başarısız olur. Takım bu sırada Retropective Toplantılarının anlamsız olduğu kanısına varır ve bu toplantları düzenlememeye başlar.
Takımlar, bir çok koşulda, Retrospective Toplantılarında tartışılan bütün iyileştirme fikirlerini uygulamaya çalışırlar. Çok sayıdaki iyileştirme fikirleri, takımı bunaltır ve bu nedenle limitli bir iyileştirme sağlanmış olur.

Seyrek Düzenlenen Retrospective Toplantıları
Bir çok takım Retrospective Toplantılarını düzenlemezler. Çünkü Retrospective Toplantılarının sürekli iyileştirme ile ilgili getirdiği faydayı anlamamışlardır. Retrospective ile Review toplantılarını birbirine karıştırırlar. Takımlar, süreçle ilgili iyileştirme fikirlerini Review toplantılarında tartışırlar. Review Toplantısının kapsamını Retrospective Toplantısınınkiyle karıştırarak, etkin bir Review toplantısı düzenleme konusunda başarısız olurlar. Retrospective Toplantılarını ihtiyaç olması dahilinde -genellikle bir yaygınlaştırmanın (release) veya projenin sonunda- düzenlemeyi seçerler.

Bir projenin sonunda büyük bir Review (gözden geçirme) toplantısı düzenlemek, geleneksel geliştirme süreçlerinin bir pratiğidir. Bir çok organizasyon proje sonu gözden geçirmelerini, Sprint Retrospective Toplantıları ile karıştırmaktadırlar. Bu nedenle bu toplantıyı genellikle proje sonunda düzenlemeye karar verirler.

Takım Katılımındaki Eksiklik
Retrospective Toplantılarında tüm takım üyelerine ihtiyaç duyulmadığı ortak bir yanlış anlaşılmadır. Özellikle Product Owner rolündeki kişilerin bu toplantılara katılması, bir çok takım tarafından yararlı görülmemektedir. Üstelik zaman zaman, Product Owner'ların bu toplantılara katılması konusunda cesaretleri kırılır.

Product Owner, bir Scrum takımında zorunlu bir roldür. O'nun katılımı olmadan Retrospective Toplantısı düzenlemek, bu toplantıların etkinliğini kısıtlamaktadır. Product Owner'ın katılımı olmadan Product Backlog'un temizlenmesi, Sprint Planlama, Sprint Review ve Product Backlog maddelerinin detaylandırılması konularındaki iyileştirmeleri tartışmak zordur. Takımın iyileştirme konularını belirlerken ve iyileştirme önerileri üretirken, Product Owner'ların bu aktivitlere katılımı çok önemlidir ve zorunludur.

Retrospective Toplantısına Sadece Bir Kişinin Öncülük Etmesi
Bir çok örnekte görüldüğü üzere, Scrum Master'ların Retropective Toplantılarında geri planda durması zor olabilmektedir. Bu durum, Scrum Master'ların bu toplantılarda Takım'ın tartışması gerektiği konuları ve problemleri fark etmelerinden kaynaklanmaktadır. Bu nedenle Scrum Master'lar kendilerini, Retrospective işlerini kendi başlarına yapmak mecburiyetinde olduklarını hissederler.

Takımla birlikte çalışmak ve takımın fikir üretmesi için onlara klavuzluk/koçluk etmek yerine, bütün işi Scrum Master'lar kendi başlarına yaparlar. Süreçte iyi giden noktaları tanımlarlar. Süreçteki problemli konuların nasıl iyileştireceğini belirlerler. Sonrasında bu fikirleri, Retrospective Toplantısında takımla paylaşırlar. Böylece bu toplantılar Scrum Master'ların takıma sunum yaptığı bir ders havasına bürünür.

Sonraki yazılarımız da bu hataları nasıl ortadan kaldıracağımıza yönelik ipuçları üzerinde durmaya çalışacağız.

Scrum Series 4: Scrum Çıktıları

Scrum Series 3: Scrum Toplantıları yazımızda Scrum metodolojisinin tanımladığı ve zorunlu kıldığı toplantıların detaylarına göz atmıştık. Bu yazımız da Scrum projeleri süresince hazırlanan ve yönetilen çıktıların detaylarını inceleyeceğiz. Scrum süresince geliştirilen ürün haricinde 3 tane çıktı bulunmaktadır:
  • Product Backlog
  • Sprint Backlog
  • Burndown Chart
Product Backlog:
Product Backlog, geliştirilecek olan ürünle ilgili bütün gereksinimleri içermektedir. Gereksinimler "Kullanıcı Hikayeleri (User Stories)" adı verilen formatta yazılmalıdır. (NOT: User Stories konusuna daha sonraki yazılarımız da detaylı bir şekilde değineceğiz.). Product Backlog proje boyunca ürünün sahip olacağı bütün yetenekleri içermelidir. Başka bir deyişle, Product Backlog'u ürünün spesifakasyonu olarak da adlandırabiliriz.
Product Backlog, Product Owner tarafından hazırlanır, önceliklendirilir ve yönetilir. Bu önceliklendirme işi her Sprint başında tekrar gözden geçirilir. Takım, eğer Product Owner'ı ikna edebilirse geliştirilecek yeteneklerin sırası değiştirilebilir ve Product Backlog güncellenebilir. Development Team ve Product Owner gereksinimlerin detayları üzerine tartışırlar ve detaylar tüm takım tarafından anlaşılır hale getirilir. Product Owner, Product Backlog hazırlanırken mutlaka ve mutlaka Müşteri ve diğer paydaşlarla da bilgi alışverişinde bulunmalı ve onların beklentilerine cevap verecek bir çıktı hazırlamalıdır.

Sprint Backlog:
Sprint Backlog, her Sprint için hazırlanır. İlgili Sprint'te geliştirilmek üzere seçilmiş gereksinimlerin alt kırılımlarını yani görevleri içermektedir. Ayrıca bu görevler için hazırlanmış planı da yansıtmaktadır.
Sprint Backlog, ilk olarak Sprint Planlama Toplantısı sırasında hazırlanır ve tahminleme yapılarak görevlerin planlaması yapılır. Sprint Backlog, aynı Product Backlog gibi yaşayan bir dokümandır ve Sprint ilerledikçe takım tarafından güncellenebilir. Gerçek uygulamalarda Sprint Backlog'un genellikle Sprint süresince bir çok değişikliğe uğradığını söyleyebiliriz. Ancak bu değişim geliştirilecek ürünün kapsamını değiştirmez, sadece yapılacak görevlerin detayları ve planda değişiklikler olur.
Sprint Backlog'u oluşturan görevler Development Team üyeleri tarafından kendi isteklerine göre seçilir ve geliştirilir.

Burndown Chart:
Burndown Chart, ilgili Sprint için tanımlanan görevlerin gözlemlenmesine yarayan bir araçtır. Günlük bazda güncellenmelidir. Bu sayede Sprint sonuna kadar tamamlanması gereken görev miktarı herkes tarafından izlenebilir. Her gün sonunda üzerinde çalışılan görevle ilgili güncelleme yapılır ve böylece Burndown Chart güncel tutulur. Zaman - İş Miktarı ikilisini gösteren bir grafik şeklinde hazırlanması, görsel olarak daha anlaşılır olması açısından önemlidir.

Bu yazımızda Scrum Çıktılarının detaylarını incelemeye çalıştık. Bu "Scrum Series" yazı dizisinin, Scrum'ın temellerini anlattığımız kısmının son yazısıydı. "Scrum Series" yazı dizisinin bundan sonraki bölümlerinde ileri seviye konulara değinmeye çalışacağız.
Görüşmek üzere.

Scrum Sertifikasyonları

Günümüzde IT sektöründe sertifikasyonların önemi gün geçtikçe artmaktadır. Sadece üniversite diploması yeterli olmamakta, aksine çalışacağınız alanla ilgili sertifikalara sahip olmanız beklenmektedir. Kişisel olarak sertifikasyonun çok gerekli olmadığını düşünsemde, çalıştığınız alanla ilgili sertifika sahibi olmanız, sizinle aynı yetenek ve tecrübeye sahip kişilere göre fark yaratmanızı sağlayabilmektedir. Günümüz endüstrisinde firmaların da bu tip sertifikalara ne yazık ki çok önem verdiğini görmekteyim. Bu nedenle bu yazımda sizlere Scrum ile ilgili ne tür sertifikalara sahip olabileceğiniz konusunda bilgi vermeye çalışacağım.

Scrum sertifikasyonu Scrum.org ve ScrumAlliance.org adlı iki organizasyon tarafından gerçekleştirilmektedir. Bu organizasyonlar aynı zamanda Scrum ile uğraşan kişilerin buluşma noktası olarakta adlandırılabilir. Bu organizasyonlar Scrum ile ilgilenen kişilere şu olanakları sağlamaktadırlar: 
  • Scrum ile ilgili kaynaklara ulaşabilirsiniz.
  • Fikir ve düşüncelerinizi diğer kişilerle paylaşabilirsiniz.
  • Scrum eğitimleri ile ilgili bilgi alabilirsiniz.
  • Scrum sertifikasyonu ile ilgili bilgilere erişebilirsiniz.
Aslına bakarsanız ikisi de aynı sertifikasyonları sağlamaktalar. Ancak sertifikasyon pazarının büyümesi ile bu iki organizasyon arasında ufakta olsa farklılıklar ortaya çıkmıştır. Bu farklılıkları şu şekilde listeleyebiliriz:
  • Scrum.org çoğu sertifika için (özellikle 1. seviye olanlar için) onaylı bir eğitim almadan sınavlara girmenize olanak sağlarken, ScrumAlliance.org malesef, sertifika almadan önce onaylı bir eğitmenden Scrum eğitimlerine katılmış olmanızı beklemektedir.
  • Scrum.org sertifikaları "Professional" kelimesi ile başlarken, ScrumAlliance.org sertifikaları "Certified" olarak başlamaktadır. Sanırım telif hakkı kısıtlarından dolayı aynı ismi kullanamıyorlar.
Dilerseniz öncelikle Scrum.org sertifikasyon süreci nasıl bir bakalım. Scrum.org sertifikasyonları, Scrum rollerine göre isimlendirilmiştir. Örneğin Scrum Master sertifikasyonu aldığınızda, "Professional Scrum Master" olursunuz. Belirli ücretler karşılığında, Scrum.org'un sağladığı sınavlara online olarak katılabilir ve sertifikanızı alabilirsiniz. Scrum.org'un sağlamış olduğu sertifikaları şöyle sıralayabiliriz:
  • Professional Scrum Master I ve II (PSM)
  • Professional Scrum Product Owner I ve II (PSPO)
  • Professional Scrum Developer (Java ve .NET) (PSD Java ve PSD .NET)
  • Professional Scrum Developer Java Trainer (PSDT Java)
  • Professional Scrum Developer .NET Trainer (PSDT .NET)
  • Professional Scrum Master Trainer (PSMT)
Scrum.org sertifikaları arasında bağlantılarda bulunmaktadır. Örneğin PSM II alabilmek için, önce PSM I almış olmanız gerekmektedir. Trainer sertifikalarını alabilmeniz için ise, belirli eğitimlere katılmış olmak zorunludur. Ayrıca her yıl Trainer'lar için yapılan yenileme eğitimlerine de katılmanız gerekmektedir.
Ayrıca şunu da belirtmek isterim, Scrum.org eğitimleri ScrumTurkey desteği ile sizlere sunulacak. Bu konuda detaylı açıklamaları ve bilgileri ilerleyen zamanlarda buradan yapacağız.

Şimdi sıra ScrumAlliance.org sertifikasyonlarının detaylarında! ScrumAlliance.org sertifikaları da Scrum.org ile benzer şekilde, Scrum rolleri kullanılarak isimlendirilmiştir. Örneğin Scrum Master sertifikasyonu aldığınızda "Certified Scrum Master" olursunuz. Belirli ücretler karşılığında, bu sertifikalar için düzenlenen sınavlara online olarak katılabilir ve sertifikanızı alabilirsiniz. ScrumAlliance.org bu sınavlara girmeden önce onaylı bir Scrum eğitimine katılmanızı şart koşmaktadır. ScrumAlliance.org'un sağlamış olduğu sertifikaları şöyle sıralayabiliriz:
  • Certified Scrum Master (CSM)
  • Certified Scrum Product Owner (CSPO)
  • Certified Scrum Developer (CSD)
  • Certified Scrum Professional (CSP)
  • Certified Scrum Coach (CSC)
  • Certified Scrum Trainer (CST)
ScrumAlliance.org sertifikaları da birbirine bağlıdır. Örneğin yukarıdaki ilk üç sertifikadan en az birisine (CSM, CSPO, ve CSD) sahip olmadan " Certified Scrum Professional" sertifikasına sahip olamazsınız.


Scrum sertifikasyonları ile ilgili daha detaylı bilgi almak için aşağıdaki adresleri kullanabilirsiniz.
Bu sertifikalara sahip olmak isteyenlere şimdiden kolaylıklar diliyorum. Görüşmek üzere.

Scrum, Kanban, and Scalable Agile Webinar

This is another big day for ScrumTurkey. We have a new contributor, it's Assembla! We would like to thank to them for their contribution and hope to meet them at one of their developers meeting.

Here is their first contribution, it's ScrumTurkey's first webinar. They have a different approach to Agile Methodologies and they are trying to provide a combined profit of Agile methods like Scrum and Kanban. The description of the webinar is as follows:

"This webinar covered how to accelerate software development by combining elements of Scrum (with fixed-length sprints), Kanban (continuous flow with rapid completion of each selected task), and Scalable Agile (multiple contributing teams working on a big project).

Agile expert Damon Poole describes how to introduce Kanban into a Scrum process, how to accelerate development with "One Piece Flow", and how to coordinate the work of multiple teams.

Assembla founder Andy Singleton previewed his vision of Scalable Agile, and showed two related features. The "Simple Planner" view of Assembla tickets with an AJAX UI helps you to move effortlessly between Scrum iteration planning and Kanban. The Advanced Merge Request feature can help you manage continuous development and release.

Questions ans answers from the webinar have been posted in a seperate blog post."