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."

Great PO

A new article from our contributor Faisal Mahmood about Product Owner role in Scrum Framework. He discusses about what are the activities of the Product Owner role, misunderstandings about the PO's activities and the core responsibility of the Product Owner in a Scrum Team.

"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 is one thing the Product Owner must do, that is to maximize product value.

The Product Owner must focus on maximizing return on investment. This is the end goal. All the activities that Product Owner carries out should lead to maximizing value. Product Owner manages the Product using the product backlog, works with the stakeholders, collaborates with the team, plans, inspects and adapts to meet this goal.

A great Product Owner maximizes return on investment by using value driven development techniques. The Product Owner can maximize value by..."

Çevik Yazılım

Bugün yeni yazarımız Yusuf AYTAŞ'ın "Çevik Yazılım" başlıklı yazısını yayınlıyoruz. Kendisine ScrumTurkey platformuna hoşgeldin diyor, katkılarından dolayı teşekkür ediyoruz.

Çevik yazılım geliştirme, bir takım yazılım geliştirme yönteminden ibarettir. Bu yöntemler, yazılımın ve gereksinimlerin biri biriyle etkileşim halinde tutarak ortaya koyulmuş süreçlerin tekrarlanmasına ve aşamalı bir şekilde ilerlemeye dayanır. Yöntemlerin uygulanmasında, zamana dayalı ilerleme, evrimsel geliştirme ve teslim süreci ve değişime karşı esnek yapı ön plana çıkar. 2001 yılında yayımlanan Agile Manifesto, yöntemlerin temelini oluşturan belgedir. Yazımın devamında, çevik yazılımı doğuran süreç ve çevik yazılım geliştirme üzerinde duracağım.

Aşamalı ilerleme yöntemleri çok eskiye dayanmakmaktadır. Aslında çoğu mühendislik biliminde de karşımıza çıkan bir uygulamadır. Ama, yazılım dünyasında çevik diyebileceğimiz algı, 1974 yılında E. A. Edmonds tarafından yayımlanan uyarlanabilir yazılım geliştirme süreci (adaptive software development process) adlı makaleye dayanmaktadır. Fakat, çevik yazılımı ortaya çıkmasındaki en büyük etken, klasik mühendislik yöntemlerinin bilgisayar biliminde yeterli olmamasıydı. Klasik mühendislik methodları, ürünün her bir parçasının geliştirme sürecine girmeden önce tek tek ele alınıp tasarımı yapılıp sonrada üretim bandına sokulmasını öngürür. Halbuki, yazılım dünyasında ürün her an değişebilir nitelikte olmalıdır. Bu durum, daha dinamik bir yöntem olan çevik yazılım geliştirme kavramını ortaya çıkardı.

Çevik yazılım geliştirme klasik anlayıştan vazgeçerek, değişime her zaman ayak uydurmaya dayanan bir anlayış. Çevik yazılım, projenin safhalara bölünerek, her safhada çalışan bir ürün elde etmeyi hedefler. Her bir safha kendine özgü tasarım, kodlama ve test etme faaliyetlerinden oluşur. Safhanın bitiminde elde edilen ürün, varolan gereksinimleri karşılayamıyor yada gereksinimleri değiştiyse bir sonraki safhada düzeltilir. Yeni safhada müşeteri ile müzakere edilerek, safhanın planı yapılır. Ürün tamamlanana kadar bu döngüye devam edilir. Çevik yazılımın etkin bir şekilde uygulanması için aşağıda anlattığımız bir kaç unsurun uygulanması önem taşımaktadır.

İhtiyaçların anlaşılması ve değişikliklerin iyi yorumlanması için müşteri yada çalışma alanında uzman biri(domain expert) ile birlikte çalışılması en önemli unsurlardan biridir. Çünkü, gerekli bilgilerin en doğru ve hızlı aktarımı gereksinimlerin birinci ağızdan duyulmasına bağlıdır. Bu yapılmadığında yazılımcılar kendi anladıklarını hayata geçirerek, bir sonraki safhada geliştirilen ürünü fazlaca değiştirmeye hatta sil baştan yapmaya sebep olabilir. Dolayısıyla, çevik yazılımda müşteri de yazılım ekibinin bir parçası olmalıdır.

Çevik yazılımda önemli olduğuna inandığım bir diğer unsur takım çalışmasıdır. Projedeki her bir birey, projenin ne doğrultuda olduğunu ve kendisinin ne yaptığını iyi anlaması gerekir çünkü ekipteki her elamanın farkındalığı ve dinginliği proje için önemlidir. Ayrıca, proje ekibinde elemanlar arasındaki farklar gözetilmelidir. Aksi takdirde, yapılan işlerde gecikmeler yada erken bitirme durumları ortaya çıkabilir. Önemli olan görevleri ekipçe zamanında bitirmektir.

Çevik yazılım, adından da anlaşılabileceği gibi kolay ve çabuk bir şekilde yeni gelen yada değiştirilen gereksinimlere ayak uydurmaktır. Varolan mühendislik yöntemlerinin, yazılım sektörü için uygun olmayışından ortaya çıkan bir yöntemdir. Ana felsefesi, yazılım sürecinin safhalara bölünerek, her bir safhada çalışan bir ürün elde etmektir. Bu felsefeyi uygularken, takım çalışması ve müşteri etkinliği dikkat edilmesi gereken unsurlardır. Sonuç olarak çevik yazılım, gereksinimlerin sürekli değiştiği yazılım dünyası için güzel bir yaklaşımdır.

Product Backlog Grooming

A new article from our contributor Faisal Mahmood about Product Backlog artifact. He discusses about why we need to groom the Product Backlog and the benefits of grooming.

"Product Backlog is a living document that is updated continuously. It contains all the requirements, functional and non-functional. After a while, it tends to become messy. It needs regular upkeep, or grooming.

Why Groom The Product Backlog

Product Backlog grooming is crucial. It helps,
  1. The Team and the Product Owner to break-down larger items into smaller items, so that they share a better understanding of the scope of these items.
  2. The Team and the Product Owner avoid long winded discussions during the Sprint Planning. It saves time.
  3. The Product Owner as she orders the Product Backlog as new items are added and existing items are broken down into smaller items.
  4. The Team estimate the Product Backlog easily. Smaller items are easier to estimate.
  5. The Product Owner to share the vision and direction of the Product with the Team. This helps the Team in understanding the big picture and make valuable decision about architecture and design.
  6. The Team and the Scrum Master understand the resource requirements and composition of the Team..."
See full article on Product Backlog Grooming.

Why Agile?

I have 8-years of professional career on software development in a diverse range of roles such as software developer, and technical analyst (in other words systems engineer) in defense industry. In defense industry, as you can imagine, most of the contracts are huge. At the end, the contractors delivers very big systems such as fighter aircrafts, command and control systems, and missile systems etc.

Let's have a brief look at how today's defense industry companies develop softwares. It's obvious that this is based on my experience and what I saw during my career.

First of all, after the bidding phase there is a CAW (Contract Award) milestone which means the purchaser announces that you win the conract. Most of the contracts forces you to apply traditional approaches like waterfall. After the CAW, probably you will conduct a kick-off meeting with the purchaser. This means the project is started officially and your calendar is effective. During the project, you as the company should achieve some important milestones time to time:
  • Requirements Review Meeting: You need to baseline your requirements. This activity also requires very heavy documentation to reach this point.
  • Design Review Meetings: You will probably achieve two design meetings, one for preliminary design and one for critical design which both baselines your design on the very early stages of the project.
  • Test Review Meeting: You need to provide your full test cases to achieve this milestone. This means that you will start testing phase.
There are some mistakes in this approach:
  • You have to baseline your requirements and your design on the very early stages of the projects. For example, you should finalise your design in the first year of a 5-years long project.
  • Technology probably may change in 5-years time and you don't need to apply those changes to your software, because your contract may not force you to do this. What a shame for the company!
  • If you want to change your requirements and evolve the design, you need to apply another process, Change Management, to record and keep track of the changes. Of course again, heavy documentation.
  • Some companies try to apply agile methodologies like Scrum on a waterfall contract. I give a name for this type of methodology: Scrumfall! It sounds so funny! You need to achieve some milestones in a waterfall approach, at the same time you are saying that we are using Scrum. Are you kidding?
I can increase the number of such examples for the mistakes, but I guess this is enough. Let's go back to title of the article: Why Agile? I believe that, Agile is the only solution:
  • Agile improves customer involvement. You can involve your customer into the process at every stage of the project instead of only involving them to milestones.
  • Agile increases the quality of the product. In short time periods, developing some part of it, and getting the feedback from customer makes your product more qualified.
  • Agile drive down risks. If you develop the risky parts first, your customer can give feedback on earlier stages. This provides you a good way of mitigating the risks.
  • Agile increases operational awareness. Think of a 5-years project, you will deliver the whole software at the end of this period if you use traditional methods. The users of it will try to get used to how the system works after this long time period. Probably, you will need to conduct a lot of training sessions, follow-up meetings etc. On the other hand, if you use Agile, you may deploy small functional parts time to time, and at the end of 5-years, the users are already familiar to the software.
  • Agile simplify releases. Agile forces you to use continuous integration and automated test techniques to reduce the costs for integration and testing. So if you setup your environment at the beginning, this means that you don't need to spend to much time later.
Finally, Agile fits to today's fast changing nature of the software development. It increases your ability to respond the changes quickly and to meet the expectations of the customers. Therefore, defense industry companies should definitely change their software development methodologies with Agile one!

Are You Making These Retrospective Mistakes?

This's one of the big days of  ScrumTurkey. We have our first author, Faisal Mahmood. He is the author of Agile Adoption Mistakes. He provides Scrum Master Certification courses in London UK and around the world. We're so appriciated about his contribution. In future, he will post his articles on ScrumTurkey regularly. We would like to say him "Welcome..."

Here is his first article discussing about common mistakes on Retrospectives. He mentions the points that agile teams should avoid to have a good continuos improvement on their agile processes.

"Continuous improvement is at the heart of Agile. Retrospectives provide opportunities to the Teams to inspect their process, and continuously improve it. Many Teams fail to take advantage of this and thus fail to improve.

Common Retrospective mistakes are
  1. Infrequent Retrospectives
  2. Ignoring Improvement Actions
  3. Lack of Team Participation
  4. One Person Leading The Retrospective

1. Ignoring Improvement Actions

This is one of the most common Retrospective anti-patterns.
The Team goes into the Retrospective meeting and discusses the improvement ideas vigorously. It discusses the way things are working and how to turn around challenging issues. It uses many techniques to gather ideas. There is no shortage of ideas during the meeting, ideas keep flowing..."

See full article on Retrospective Mistakes.

The Guru: Mike Cohn

We guess this is the most exiciting post for us we've written since the start up of ScrumTrukey. I posted a tweet to Mike Cohn yesterday about supporting ScrumTurkey by retweeting. He showed his kindness and supported us. Also he posted another one about one of our articles. This made us very proud.
Let us give you some information about him... Mike Cohn has worked with Fortune 500 companies, small startups, and everything in between. With over fifteen years of experience with Scrum and agile, Mike has the expertise and depth of knowledge to help the organizations create and build high-performance teams. You can read more here.

By the way, the Guru, Mike Cohn also supported ScrumTurkey allowing us to share one of his posts from his blog. And we selected the most interesting one. It's an article about check-in and check-up the team members of a Scrum Team. He recommends the checking in, not the checking up. He discusses the four key things a good ScrumMaster or agile project manager can do to avoid crossing the line into micro-management while still checking in on a team. You can find the full article here.
Thanks a lot again for his kidness and best wishes for ScrumTurkey.

Scrum Series 3: Scrum Toplantıları

Scrum Series 2: Scrum Rolleri yazımızda Scrum metodolojisinin tanımlamış olduğu rolleri incelemiştik. Bu yazımızda Scrum çerçevesinde yapılması zorunlu olan toplantılar hakkında detaylı bilgiler paylaşacağım sizlerle. Scrum toplantılarının detayları ile birlikte ürün geliştirmenin yapıldığı zaman periyodu olarak tanımlayabileceğimiz Sprint konusuna da değineceğiz.
Bu yazımızda üzerinde duracağımız başlıkları şu şekilde listeleyebiliriz:
  • Sprint
  • Sprint Planlama Toplantısı
  • Daily Scrum Toplantısı
  • Sprint Review Toplantısı
  • Sprint Retrospective Toplantısı
Sprint:
Sprint, Scrum projelerinde her türlü geliştirme görevlerinin icra edildiği zaman dilimine verilen isimdir. Her Sprint "Sprint Planlama Toplantısı" ile başlar ve son günde yapılan Sprint Review ve Sprint Retrospective toplantıları ile biter. Sprintlerde her gün düzenli olarak yapılan ve 15 dakika ile sınırlandırılmış Daily Scrum Toplantıları yapılır.
Sprintler zaman olarak sınırlanmış bir periyottur ve bu zaman sınırı tamamlandığında Sprint biter. Scrum Klavuzunda belirtildiği üzere bir Sprint en fazla 1 takvim ayı olarak sınırlandırılmıştır. Ancak bazı kaynaklarda 1-4 hafta, bazılarında ise 2-4 hafta olarak tanımlanmaktadır. Kişisel görüşüme göre 2-4 hafta süren Sprintlerin gerçekleştirilmesi daha uygundur.
Sprintlerde geliştirilecek yetenekler Sprint Planlama toplantısında belirlenir. Product Owner ve Development Team bu konu üzerinde anlaşırlar. Ürünün geliştirilme sorumluluğu Development Team'e aittir.
Bir Sprint başladığında aşağıda listelediğim özelliklerde kesinlikle değişiklik yapılmamalıdır:
  • Ürünün belirlenen kapsamı
  • Development Team üyeleri
  • Sprint'in planlanan süresi
Sprint Planlama Toplantısı:
Her Sprint, bu toplantı ile başlar. Zaman olarak 1 aylık Sprintler için 8 saat olarak sınırlandırılmıştır. Süre olarak daha kısa planlanan Sprintler için aynı oranda bu toplantının süresi de kısaltılmıştır. Örneğin 2 haftalık Sprintlerde, Sprint Planlama Toplantısı en fazla 4 saat olacak şekilde yapılmalıdır.
Scrum Master toplantıyı düzenler ve bütün Scrum Takımı bu toplantıya katılmakla zorundadır. Bu toplantı esnasında 2 konu da konuşulmalıdır:
  • Sprint esnasında hangi yeteneklerin geliştirileceği
  • Bu yeteneklerin nasıl geliştirileceği
Toplantı doğası gereği iki bölüme ayrılmıştır. Birinci bölümde Development Team, Product Owner'a sorular sorarak yapılacak işin detaylarını sorgular ve Sprint'in kapsamı konusunda ortak bir karar alınır. Böylece Sprint amacı belirlenmiş olur. İkinci bölümde Development Team, tanımlanmış ve Sprint kapsamına alınmış olan yetenekleri görevlere böler ve tahminleme yaparak Sprint planını oluşturur.
Daily Scrum Toplantısı:
Daily Scrum Toplantısı, Sprint boyunca her gün düzenlenmesi gereken bir toplantıdır. Bu toplantı en fazla 15 dakika ile sınırlandırılmıştır. Scrum Takımının günlük olarak süreci gözlemlemesi sağlanmış olur.
Scrum takımındaki herkes bu toplantıya katılabilir. Ancak sadece Development Team'in konuşabilir. Scrum Master bu toplantılara, takımın bu toplantıyı düzenleyip düzenlemediğini kontrol etmek amacıyla katılması gerekmektedir.
Takım üyelerinin aşağıdaki 3 soruya cevap verir nitelikte konuşması gerekmektedir:
  • Bir önceki toplantıdan beri ne yaptım?
  • Bir sonraki tolantıya kadar ne yapacağım?
  • Önümde bir engel var mı?
Daily Scrum toplantıları bir durum güncelleme veya durumu gözlemleme toplantısı değildir. Takımın yaptıkları işleri senkronize etmesi açısından önemlidir.
Sprint Review Toplantısı:
Sprint Review toplantısı her Sprint'in sonunda yapılan işin gözden geçirilmesi ve bir sonraki Sprint'te geliştirilecek yeteneklerin belirlenmesi için düzenlenir. Diğer toplantılar gibi bu toplantının belirli bir zaman içerisinde bitirilmesi zorunludur. 1 aylık Sprint'lerde 4 saat, daha az süreli Sprint'lerde 4 saat'ten daha az bir süre de sonlandırılması gerekmektedir.
Genel olarak demo olarak yapılsa da, bu bir çalışma oturumudur. Bütün ekip geliştirilen ürün üzerinde fikirlerini söyler ve bu fikirler çerçevesinde tartışmalar sürdürülür.
Bu toplantı sayesinde takım, teknolojik, ürün stratejisi veya ürünün market değeri konularında tartışma fırsatı bulur. Bu tartışmaların sonucu olarak ürün yeteneklerinde güncelleme yapılabilir.
Sprint Retrospective Toplantısı:
Sprint Retrospective Toplantısı, Sprint sonunda yapılan toplantıdır ve bu toplantının bitmesi ile Sprint'te tamamlanmış olur. Bu toplantıda yine diğer toplantılarda olduğu gibi yine zaman olarak sınırlandırılmış bir toplantıdır. Ancak bu zaman sınırı hakkında çeşitli kaynaklarda, farklı zaman birimleri belirtilmektedir. Scrum Klavuzunda 1 aylık Sprint'ler için en fazla 3 saat olarak tanımlanmıştır. Başka kaynaklarda 15 dk ile 30dk arasında da yapılabileceği belirtilmektedir.
Scrum Takımı, bu toplantı sayesinde süreci iyileştirme ve sürekli olarak geliştirme fırsatı yakalamış olur. Bu toplantı esnasında uygulanan süreç kapsamında tartışmalar yürütülür. Bu toplantıda şu üç soruya cevap verilir:
  • Neleri iyi yaptık?
  • Neleri kötü yaptık?
  • Süreci geliştirmek için neler yapabiliriz?
Bu toplantı sonucunda bir sonraki Sprint için yapılacak iyileştirmeler ortaya konulur.
Bu yazımızda Scrum Toplantıları'nın detaylarını incelemeye çalıştık. Bir sonraki yazımızda (Scrum Series 4: Scrum Çıktıları) Scrum sürecinin çıktılarının detaylarını inceleyeceğiz.
Görüşme üzere.

Fancy Scrum Planning Poker Cards!

Planning Poker is my favourite tool which is introduced as a Scrum planning and estimation practice. There are two ways of playing it, automated and manual with planning poker cards. The automated way is also divided in two:
  • Planning Poker on web: You can reach it here. It's brought to community by Mountain Goat Software as a free tool, but in my opinion it's a kind of boring way to play Planning Poker.
  • Planning Poker on mobile: There are a few mobile applications that you can install on your smart phones like iPhone. You can find those on iTunes application, if you perform a simple search with "Scrum" keyword.
My favourite way of playing Planning Poker is the manual one since it makes me feel like having fun while working. Meetings are mostly boring activities for me (I guess you feel in the same way). However if it is a Sprint Planning one, it is not anymore.
I have a colleague, named Cem Altun, who is a very talented Graphics Designer. We were talking about Scrum and Planning Poker tool last week. Then we decided to design our own custom planning poker cards. He designed 4 sets of fancy decks, and I cannot decide which one is the best, because all of them seem to me as perfect artwork. So, I would like to have your comments.
Style 1

Style 2

Style 3
Style 4
They are so funny, aren't they? By the way, if you would like to have one, just let me know!
NOTE: You can also see Cem's Portfolio here.