Category Archives: Extreme Programming

Scrum Master Gelişim Programı

Scrum Master Gelişim Programı

“If I have seen further, it is by standing upon the shoulders of giants.” – Isaac Newton

Newton, 1675 yılında arkadaşı Robert Hooke’a yazdığı bir mektupta yukarıdaki ifadeyi kullanmıştır. Newton’un bu cümleyle ifade etmek istediği şey; buluşlarını, diğer bilim insanlarının ışığında çalışarak yaptığıdır. Bu eğitimi hazırlarken omuzları üzerinde yükseldiğim devler; koç olarak Serkan Özdemir, eğitimci olarak İsmail Hakkı Tonguç ve Hasan Ali Yücel, koçluk kavramını iş dünyasına uyarlayan Timothy Gallwey ve Sir John Whitmore, Scrum’ın ruhunun anlaşılması ve Scrum Master rolünü aydınlatan çalışmalarıyla Barry Overeem, kültür üzerine çalışmalarıyla William Schneider, organizasyonel değişim çalışmalarıyla John Kotter, retrospektifi anlatan çalışmalarıyla Esther Derby ve Diana Larsen, psikolog Philip Zimbardo, toplum psikologları David Dunning ve Justin Kruger ve Çevik Bildiri’ye imza atanlardır. Her birinin çalışmalarından, kitaplarından faydalanarak eğitim programını oluşturmaya çalıştım. İki sınıfla yaptığımız çalışmalarda birçok iyileştirme aksiyonu ortaya çıktı. Gelecek sınıflarda bu iyileştirme aksiyonlarıyla eğitimi daha iyi bir seviyeye getirmeye çalışacağım.

Eğitime katılan Aylin Tütüncü, Burcu Demirel, Büşra Çayırlı, Cemre Aslan, Çağın Uludamar, Emine Yıldırım, Gizem Yalçın, Gökhan Kolancı, İlknur Sağlam, Kubilay Kulaoğlu, Malik Dersuneli, Merve Özdemir, Rabia Okumuş, Serap Aksoy Yılmaz, Serap Şen Geçici, Serhat Kolcu, Sinem Yıldırım, Şebnem Adıgüzel, Şenol Kanca, Yeşim Daşdemir ve geri bildirimde bulunan herkese çok teşekkür ederim.

Kitapçığı baştan sona pür dikkat okuyan, iyileştirme önerileri sunan ve kitapçığın Türkçe’ye daha uygun olmasını sağlayan Ayşenur Yılmaz’a çok teşekkür ederim.

Scrum Master Gelişim Programı
Scrum Master Gelişim Programı

Scrum Master Gelişim Programı, eğitim ve pratik temelli bir programdır. Programın hedefi karmaşıklığın ve belirsizliğin yüksek olduğu, hızla değişen ortamlarda yazılım geliştiren takımların Scrum Master’larının ihtiyaç duydukları yetkinlikleri kazanmaları ve var olan yetkinliklerini geliştirmeleridir.

Atölye serisi olarak gerçekleştirdiğimiz çalışmalarda aşağıdaki konulara değindik:

  1. Scrum Master’ın Sorumlulukları Nelerdir?
  2. Schneider Kültür Modeli ve Çevik Yaklaşımlar
  3. Kotter Değişim Modeli ve Scrum
  4. Retrospektif Çerçevesi ve Kendi Retrospektif Tekniğimizi Geliştirme
  5. Koç, Mentor ve Danışman Rolleri
  6. Performans = Potansiyel – Engeller
  7. Fasilitasyon Nedir ve Tersine Düşünme Tekniğini Kullanma

Scrum Master Gelişim Programı kitapçığını indirebileceğiniz bağlantı:  Scrum Master Gelişim Programı Kitapçığı (154 downloads)

Atölye çalışmalarının bir ana konusu ve bunu destekleyen yan konuları oldu. Örneğin üçüncü atölye çalışmasında Kotter Değişim Modeli ana konuyken, Scrum konusuna derinlemesine girilmeden Scrum Master’ların Scrum konusundaki bilgileri tazelenmeye çalışıldı. Her atölye çalışmasında o günün atölye çalışmasını destekleyen makaleler, videolar ve kitaplar katılımcılarla paylaşıldı. Bununla birlikte katılımcıların konuyu kendi bakış açılarıyla anlatacakları bir sunum, blog yazısı ya da vlog2(video blog) oluşturmaları ve sınıfla paylaşmaları beklendi. Ayrıca katılımcıların organizasyon içinde kendi takım üyeleri dışındaki kişilerle çalışmaları teşvik edildi. Örneğin dördüncü atölye çalışmasında katılımcıların kendi takımları dışında bir takımın retrospektif etkinliğini fasilite etmeleri ve bu konuda sunum, makale paylaşmaları beklendi. Altıncı atölye çalışmasından sonra katılımcılardan koçluk yapabilecekleri birini bulup, buldukları kişinin belirlediği bir konu hakkında onlara koçluk yapmaları ve bu tecrübelerini yine bir makale ya da sunumla anlatmaları istendi.

Sınıf içinde gerçekleştirilen atölye çalışmalarında izlenen yol geleneksel yaklaşımdan farklıydı. Geleneksel yaklaşımda eğitimi veren kişi anlattığı konu hakkında bir sunum hazırlar ve bu sunuma sadık kalarak konuyu işlemeye çalışır. Bilgiyi sadece aktarmak istediğiniz yerlerde kullanabileceğiniz basit, maliyeti düşük ve efektif bir yoldur. Fakat öğrenmenin bu şekilde gerçekleşmesi ve öğrenilen şeyin hayata aktarılması zordur. Öğrenmenin gerçekleşmesi ve öğrenilen şeyin hayata daha kolay aktarılabilmesi için farklı bir yol seçtim. Programın birçok bölümünde katılımcılarla grup çalışmaları yapıldı, bu grup çalışmalarının amacı katılımcıların işlenen konu hakkında düşünmesini ve hali hazırda var olan bilgilerini, fikirlerini ortaya çıkarmaktı. Konuları bu şekilde işlemenin başka faydalarını da elde ettik. Bu faydalar:

  • Katılımcıların dikkat dağınıklığının önüne geçilmesi ve odaklanmalarının kolaylaştırılması.
  • Fasilitator olarak eğitmeni gözlemlemeleri ve fasilitasyon konusunda kendi yetkinlik setlerini genişletebilmeleri.
  • Eğitimi veren kişinin konuşmaya harcadığı sürenin azalması böylece katılımcıların öğrenmeye harcadığı sürenin artması.
  • Eğitim odağının eğitmenden ziyade katılımcılar olması.
  • Sınıf içinde katılımcıların gerçekleştirdikleri çalışmaları diğer katılımcılarla paylaşmaları ve geri bildirim almaları.
Öğrenen ve dinleyen arasında fark bulunur.

Scrum Master’ın sorumluluklarından biri; “Organizasyon içinde Scrum’ın etkisini artırmak için diğer Scrum Master’larla çalışmaktır3”. Bu vizyonu Scrum Master’ın organizasyon içindeki herkesle çalışması yönünde genişlettik. Sekizinci atölye çalışmasında her Scrum Master sevdiği, bilgisinin ve deneyiminin olduğu bir konuyu tüm organizasyona açık bir etkinlikte anlattı. Bununla en az iki kazanım elde ettik. Birincisi hali hazırda organizasyon içinde bulunan bilgi herkesle paylaşıldı. İkincisi bilgi paylaşımında bulunan kişiler güçlenmiş ve başarılı hissettiler. Bu etkinlikte paylaşımı yapılan konuları birer makale olarak ve atölye çalışmaları içinde katılımcıların geliştirdiği retrospektif tekniklerinden bazılarını yine bu kitapçıkta bulabileceksiniz.

Scrum Master Gelişim Programı’nın tamamında eğitim ve pratik bir aradadır. Sınıfça yapılan atölye çalışmaları, paylaşılan makaleler, videolar ve hazırlanması beklenen sunum ya da makaleler bilgiyi derinleştirmek için birer araç olarak kullanılırken, organizasyon içindeki diğer kişilerle çalışma, takımların retrospektiflerini fasilite etme, organizasyondaki kişilerle koçluk seansları düzenleme öğrendiklerini pratiğe dökmek ve diğerlerinin de bundan faydalanmasını sağlamak içindir.

Scrum Master Gelişim Programı ile hedeflenen katılımcılarda farkındalık oluşturmaktır. Bu farkındalık oluştuktan sonra yapılan iş hakkında bilgiyi daha da derinleştirme ve yapılan işte anlam bulma katılımcıların motivasyonu ve bireysel hedefleriyle ilgilidir. İlerleyen bölümlerde detaylı bir şekilde değineceğimiz “Öğrenmenin Aşamaları” modeli üzerinden bu konuyu anlatırsam; Scrum Master Gelişim Programı’nın hedefi, Öğrenmenin Aşamaları modelindeki ikinci aşama olan “farkındalık” aşamasını başarılı bir şekilde gerçekleştirmektir. Üçüncü aşama olan “öğrenme, uygulama, hayata aktarma” aşaması katılımcılara kalmıştır. Bu kitapçığın amacı üçüncü aşamaya yardımcı olmaktır.

Kitapçığı Kimler Okumalı?

Eğitimin ve kitapçığın adı Scrum Master Gelişim Programı olsa bile çok farklı konulara değinilen bu kitapçığın herkesin faydalanabileceği bilgiler içerdiğini düşünüyorum. Örneğin aktif dinleme yapmak sadece Scrum Master’ın sahip olması gereken bir yetkinlik değil, karşısındakini daha iyi dinlemek isteyen, karşısındakine onu dinlediğini hissettirmek isteyen herkes için yararlıdır. Ayrıca çalıştığı organizasyonun kültürünü anlamak sadece Scrum Master’ın işine yarayacak bir bilgi değildir. Ürün Sahibi, yazılım geliştirme uzmanı, genel müdür ya da genel müdür yardımcısı rollerine sahip olsanız bile içinde bulunduğunuz organizasyonu anlamak işinizi yapmanızı kolaylaştıracaktır. Bu bakış açısıyla bakılırsa bu kitap herkes içindir ve herkes faydalanabilir, sadece Scrum Master’lar biraz daha fazla. 🙂

Çevik Retrospektif Teknikleri – 4L Retrospektif Tekniği

Çevik Retrospektif Teknikleri – 4L Retrospektif Tekniği

4L Retrospektif Tekniği

4L retrospektif tekniği, retrospektif toplantısını eğlenceli bir hale getirmek için bir başka tekniktir. Mary Gorman’ın kullandığı 3L retrospektif tekniğinden türetilmiştir.

3L retrospektif tekniğindeki L’ler aşağıdaki gibidir:

Liked / Loved – Hoşlandıklarım / Sevdiklerim

Lacked – Eksik Olduğunu Düşündüklerim

Longed For – Özlemini Çektiklerim

3L tekniğinden sonra Ellen Gottesdiener tekniğe bir L(Learned) daha ekleyerek 4L retrospektif tekniğini oluşturmuştur.

4L şu şekilde sıralanır:

Liked / Loved – Hoşlandıklarım / Sevdiklerim: Geçtiğimiz döngüde sevdiğim şeyler.

Learned – Öğrendiklerim: Geçtiğimiz döngüde öğrendiğim şeyler.

Lacked – Eksik Olduğunu Düşündüklerim: Geçtiğimiz döngüde eksik olduğunu düşündüğüm şeyler.

Longed For – Özlemini Çektiklerim: Geçtiğimiz döngüde keşke olsaydı diye düşündüğüm şeyler.

Continue reading Çevik Retrospektif Teknikleri – 4L Retrospektif Tekniği

Çevik Retrospektif Teknikleri – MAD, SAD, GLAD Tekniği

Çevik Retrospektif Teknikleri – MAD, SAD, GLAD Tekniği

Retrospektif, Çevik yaklaşımların hayatımıza soktuğu en önemli pratiktir. Retrospektiflerin hayatımıza girmesiyle sürekli olarak iyileşme şansı elde ettik. Geleneksel yaklaşımda iyileştirme şansı sadece proje sonunda “Öğrenilmiş Dersler” bölümünde yer alıyor. Geleneksel proje yönetimiyle geliştirdiğim projelerin hiç birinde “Öğrenilmiş Dersler” aktivitesini gerçekleştirmedim. Çünkü birkaç proje hariç çoğu için teslim tarihini geçmiştik. Teslim tarihini geçtiğiniz bir proje de “Öğrenilmiş Dersler” aktivitesini yapamıyorsunuz. Projenizi teslim ettikten sonra sıradaki projeye başlıyorsunuz. Halbuki Çevik yaklaşımlarla kendimizi her gün iyileştirme şansına sahibiz. Yukarıda geleneksel yaklaşımda bu şansın neredeyse hiç verilmediğini vurgulamam bu şansın ne kadar değerli olduğunu göstermek içindir.

İlerleyen bölümlerde farklı retrospektif tekniklerine, bu tekniklerin aktivite olarak nasıl gerçekleştirileceğine, gereksinimlerine değineceğim. MAD-SAD-GLAD ile başlıyoruz. 🙂

MAD-SAD-GLAD Tekniği

MAD-SAD-GLAD, en basit retrospektif tekniklerinden biridir. İçine kapanık, çok fazla konuşmayan takım üyelerinin bulunduğu takımlarda bu teknik kullanılarak takım üyelerinin retrospektife katkıları artırılabilir. Duygulara yönelik bir teknik olduğu için daha önce az katılım gösteren takım üyelerinin daha fazla katılım gösterdiğini gözlemleyeceksiniz. Bunu kesin bir bilgi gibi söylüyorum çünkü deneyimlerim hep bu yönde oldu. Eğer hali hazırda çok konuşan, iletişimi kuvvetli, içine kapanık olmayan takım üyeleriniz varsa bu retrospektif tekniği sizin için uygun olmayabilir. Zaten konuşkan kişileri daha da fazla konuşturarak iletişimlerine ve koordinasyonlarına çok fazla enerji harcamak doğru olmayabilir.
Continue reading Çevik Retrospektif Teknikleri – MAD, SAD, GLAD Tekniği

Sürekli Entegrasyon 4

Sürekli Entegrasyon 4

 

10. Herkes Ne Olduğunu Görebilir

Sürekli Entegrasyon iletişimdir. Böylece herkes sistemin son halini ya da şimdiye kadar neler yapıldığını rahatça görebilir. İletişimin yapıldığı birinci konu ise ana branch üzerinde gerçekleştirilen build işleminin durumunun ne olduğudur. Sürekli Entegrasyon için kullanılan araçlar bir web sitesi ile gelirler ve yapılan build’i, bu web sitesi üzerinden herkes izleyebilir. Kimi kurumlar bunun daha da görselleştirmek isterler başarılı build’ler için yeşil ışık sorunlu build’ler için kırmızı bir ışık yakarlar. Kimi kurumlar daha eğlenceli yaklaşırlar olaya ve build yapan yazılım geliştiricinin makinesinin üzerinde plastikten bir horoz bulunur. Herkes build yapıldığını ve kim tarafından yapıldığını bilmiş olur.

Web sitesinin diğer bir avantajı ise aynı ofiste çalışmayan kişilerin build’in son durumu hakkında kolayca bilgi edinebilmesidir. Ayrıca tarihçesi tutulan sistemlerin hangi build’lerinin başarılı olduğu hangilerinin olmadığı ve neden olmadığı bilgisi de bulunmaktadır.

Continue reading Sürekli Entegrasyon 4

Sürekli Entegrasyon 3

Sürekli Entegrasyon 3

6. Bozuk Build’i Hemen Düzeltin

Sürekli build yapabilmenin anahtarı ana branch’te gerçekleştirilen bir build hata aldıysa bunu hemen düzeltmektir. Sürekli Entegrasyon ile çalışmanın amacı stabil bir ortamda geliştirme yapmaktır. Ana branch’te bir build’in hata alması kötü bir şey değildir fakat sürekli olarak yaşanıyorsa bu yazılım geliştiricilerin yeterince dikkatli olmadıklarının göstergesidir. Yine de önemli olan nokta eğer bir build hata aldıysa bunun biran önce düzeltilmesidir. Böyle bir sorun genellikle ana branch’e gönderilen son kodun geri alınması ve kodu gönderen kişinin kendi makinesinde sorunu bulmasıyla çözülebilir.

Continue reading Sürekli Entegrasyon 3