• HAKKIMIZDA
  • İLETİŞİM
Kaizen Hub
  • KEŞFET
OKR

OKR Döngüsü: Sürekliliği Sağlayan Etkinlikler

by mlap May 5, 2024
written by mlap

OKR (Objectives & Key Results), sadece hedeflerin yazılması değil; aynı zamanda bu hedeflere ulaşma yolculuğunun sürekli takip edilmesi, öğrenilmesi ve geliştirilmesidir. Agile takımlarda olduğu gibi OKR ekipleri de düzenli bir döngüyle ilerleyerek gelişimin sürekliliğini sağlayabilir.

Bu döngü, ekip var oldukça devam eder ve her dönemde öğrenilenlerle daha da olgunlaşır.


1. Planlama

  • Yeni dönemin (genellikle çeyrek) Objective ve Key Result’ları bu etkinlikte belirlenir.

  • Hedeflerin odaklı, ilham verici ve ulaşılabilir olmasına dikkat edilir.

  • Uzun dönemli planlamalar odaklanmayı zorlaştırabileceği için çeyreklik dönemler en idealidir.

  • Planlama sırasında ekibin tüm üyelerinin fikirlerini ortaya koyması, sahiplenmeyi artırır.

Örnek: E-ticaret şirketinde bir dönem için Objective → “Müşteri memnuniyetini artırmak”, Key Result → “NPS skorunu 45’ten 65’e çıkarmak”.


2. Weekly / Bi-Weekly Check-in

  • Bu etkinlikler OKR döngüsünün nabzıdır.

  • Katılımcılar 3 temel soruya odaklanır:

    1. Neler yaptık?

    2. Neler yapmayı planlıyoruz?

    3. Karşılaştığımız engeller neler?

  • Düzenli check-in toplantıları, hem ilerlemenin görünür olmasını sağlar hem de engellerin hızla kaldırılmasına yardımcı olur.

  • Ayrıca farklı ekiplerden gelen tecrübeler, alternatif çözümler ve yeni bakış açıları hızlı karar alınmasını sağlar.


3. Review (Dönem Sonu Değerlendirme)

  • Dönemin sonunda ekip, belirlenen OKR’ların ne kadarına ulaşıldığını değerlendirir.

  • Başarı oranları şeffaf şekilde paylaşılır.

  • Hedeflerin durumu hakkında geri bildirimler alınır.

  • Öğrenilen dersler, bir sonraki dönem için daha doğru OKR’lar yazılmasına katkı sağlar.

Örneğin: “Bu dönemde 3 Objective’in 2’sinde hedeflenen başarı oranına ulaşıldı, 1’inde ise %60 seviyesinde kaldık.”


4. Retrospective

  • Review daha çok “ne yaptık” sorusuna odaklanırken, Retrospective “nasıl yaptık” sorusuna cevap arar.

  • İletişim, süreçler, ilişkiler ve işbirliği açısından dönem değerlendirilir.

  • İyileştirme noktaları belirlenir, gelecek dönem için aksiyonlar netleştirilir.

  • Ek olarak olumlu konularda birbirine takdir ve teşekkür paylaşımı da yapılır.

  • Scrum’daki Retrospective teknikleri (Start-Stop-Continue, Mad-Sad-Glad, Plus-Delta vb.) bu toplantıda da kullanılabilir.

İpucu: Retrospective’in başında, bir önceki dönemde alınan aksiyonların durumu gözden geçirilirse öğrenme daha kalıcı olur.


Sonuç

OKR, yazılı hedeflerden çok daha fazlasıdır; ekiplerin sürekli öğrenerek geliştiği dinamik bir yolculuktur. Planlama → Check-in → Review → Retrospective döngüsü uygulandığında:

  • Hedeflere daha hızlı odaklanılır,

  • İletişim şeffaflaşır,

  • Öğrenme kültürü yerleşir,

  • Takım motivasyonu artar.

Böylece OKR, organizasyonun sadece hedef belirleme değil, aynı zamanda sürekli gelişim ve kültürel dönüşüm aracıhaline gelir.

May 5, 2024 0 comments
0 FacebookTwitterPinterestEmail
OKR

Doğru OKR (Objectives & Key Results) Belirleme Süreci

by mlap May 2, 2024
written by mlap

OKR, sadece hedefleri yazıp bırakmak değil; aynı zamanda bu hedeflere ulaşmayı sağlayacak ölçülebilir sonuçları ve düzenli takip mekanizmasını kurmaktır. Doğru bir süreçle belirlenen OKR’lar, ekiplerin odaklanmasını, stratejiyle hizalanmasını ve performanslarını en üst seviyeye çıkarmasını sağlar.

Aşağıda adım adım doğru OKR belirleme sürecini bulabilirsiniz:


1. Hedeflerin ve Stratejilerin Belirlenmesi

OKR sürecine başlamadan önce organizasyonun büyük resmini netleştirmek gerekir.

  • Amaçlar tüm organizasyonla şeffaf şekilde paylaşılmalıdır.

  • Stratejinin nedenleriyle birlikte anlatılması, çalışanların benimsemesini kolaylaştırır.

  • Net ve anlaşılır stratejiler, OKR ekibinin öncelikli işlere odaklanmasını sağlar.


2. OKR Ekibinin Oluşması

OKR’ların kağıt üzerinde kalmaması için süreci yürütecek bir ekibe ihtiyaç vardır.

  • Ekip; hedefleri belirler, aksiyonları tasarlar ve ilerlemeyi düzenli olarak takip eder.

  • Stratejiye inanmış ve sahiplenmiş kişilerden oluşması önemlidir.

  • Ekip üyeleri arasında farklı birimlerden temsilcilerin olması, daha bütüncül bir bakış açısı sağlar.


3. OKR Döneminin Belirlenmesi

Hedefler ne kadar sürede ulaşılmak üzere yazılacak?

  • Genellikle çeyrek dönemler (quarter) tercih edilir.

  • Bazı kurumlar yarıyıllık ya da yıllık OKR’lar da kullanabilir.

  • Kritik nokta: Objective ve Key Result’ların belirlenen dönemde ulaşılabilir olmasıdır.


4. Objective’lerin Belirlenmesi

Objective, “Nereye ulaşmak istiyoruz?” sorusunun cevabıdır.

  • İlham verici, motive edici ve net olmalıdır.

  • Çok sayıda olmamalı (en fazla 3–5 Objective önerilir).

  • Zorlayıcı ama ulaşılabilir hedefler ekiplerin sınırlarını aşarak daha fazlasını başarmasına yardımcı olur.

Örnek:
“Türkiye’de müşteri deneyimi en iyi e-ticaret platformu olmak.”


5. Key Result’ların Belirlenmesi

Key Results, “Objective’e ulaştığımızı nasıl anlayacağız?” sorusunun cevabıdır.

  • Mutlaka ölçülebilir ve rakamsal olmalıdır.

  • Herkes tarafından aynı şekilde anlaşılmalıdır.

  • Aktivitelere değil, sonuca odaklanmalıdır.

Örnek:
Objective: “Müşteri memnuniyetini artırmak.”

  • KR1: Net Promoter Score (NPS) değerini 40’tan 60’a çıkarmak.

  • KR2: Şikayetlere dönüş süresini 48 saatten 12 saate indirmek.

  • KR3: Tekrar alışveriş oranını %25’ten %40’a yükseltmek.


6. Aktivitelerin Belirlenmesi

Key Result’lara ulaşmak için yapılacak işler aktivite olarak tanımlanır.

  • Başlangıçta tüm aktiviteleri belirlemek zorunlu değildir.

  • Öncelikle kritik olan aksiyonlar yazılmalı, diğerleri düzenli gözden geçirmelerde netleştirilmelidir.

  • Böylece esneklik korunur ve değişen şartlara uyum sağlanır.


7. Düzenli Olarak Gözden Geçirilmesi

OKR’ların başarısı, sadece yazılmasında değil, takip edilmesinde yatar.

  • Düzenli periyotlarla (ör. haftalık veya iki haftada bir) gözden geçirilmelidir.

  • İlerlemeler, engeller ve yeni aksiyonlar masaya yatırılmalıdır.

  • Gerekirse Key Result’lar güncellenebilir.


Sonuç

Doğru OKR belirleme süreci:

  1. Stratejilerin netleştirilmesi,

  2. Sahiplenen bir OKR ekibi,

  3. Uygun dönemlerin seçilmesi,

  4. İlham verici Objective’ler,

  5. Ölçülebilir Key Result’lar,

  6. Net aktiviteler ve

  7. Düzenli gözden geçirmeler ile başarıya ulaşır.

Böylece OKR, sadece bir yönetim tekniği değil; aynı zamanda organizasyonun odak, şeffaflık ve uyum kültürünügüçlendiren bir araç haline gelir.

May 2, 2024 0 comments
0 FacebookTwitterPinterestEmail
OKR

OKR (Objectives and Key Results) Nedir?

by mlap April 28, 2024
written by mlap

OKR (Objectives and Key Results), Türkçesiyle Hedefler ve Anahtar Sonuçlar, organizasyonların, takımların ve bireylerin hedeflerini ortak bir doğrultuda yönetmelerini sağlayan bir yöntemdir.

En temel amacı:
👉 Organizasyonun stratejik hedefleriyle, takımların ve bireylerin günlük çalışmalarını bağlantılı ve şeffaf bir hale getirmektir.

OKR, sadece “nereye gitmek istediğimizi” değil, aynı zamanda “orada olduğumuzu nasıl anlayacağız?” sorusunun cevabını da verir.


OKR Tarihçesi

OKR’ın gelişiminde üç isim ön plana çıkar:

  • Peter Drucker: MBO (Management by Objectives – Amaçlarla Yönetim) yaklaşımıyla OKR’ın öncüsü oldu. Hedeflerin net tanımlanmasını ve yöneticiler ile çalışanlar arasında ortak anlaşmayı vurguladı.

  • Andy Grove (Intel CEO’su): Drucker’ın MBO yaklaşımını alıp geliştirdi ve OKR yapısını sistematik hale getirdi. High Output Management kitabında OKR’ın nasıl uygulanacağına dair detaylı sorular sundu.

  • John Doerr: Andy Grove’dan öğrendiği OKR’ı Google’a taşıdı. Google, 40 kişilik küçük bir ekipken OKR kullanmaya başladı ve bugün 150.000 kişilik dev organizasyonda bile OKR uygulanıyor.

Daha sonra LinkedIn, Spotify, Amazon gibi birçok teknoloji devi de OKR yöntemini benimsedi.


OKR’ın Faydaları

  1. Şeffaflık: Organizasyonun stratejileri tüm çalışanlara görünür olur. Bu şeffaflık kararların uyumlu alınmasını sağlar.

  2. Ortak Amaç: Herkes aynı hedefe doğru ilerlediği için hizalanma sağlanır.

  3. Doğru İşlere Odaklanma: Kaynaklar ve zaman, gerçekten stratejik önceliklere ayrılır.

  4. İletişimin Artması: Ortak hedefler, ekipler arası iletişimi ve iş birliğini güçlendirir.

  5. Büyük Resmi Görme: Agile takımlar yaptıkları işin organizasyon hedeflerine etkisini daha net fark eder.

  6. Çeviklik: Hedefe ulaşma yolunda yöntemler değişebilir, OKR bu esnekliğe uyum sağlar.


Objective (Hedefler)

Objective, “Nereye ulaşmak istiyoruz?” sorusunun cevabıdır.

İyi bir Objective’in özellikleri:

  • İlham verici, motive edici ve net olmalıdır.

  • Vizyonu tarif etmeli ve yön göstermelidir.

  • Şirket hedefleriyle uyumlu olmalıdır.

  • Sayıca az olmalı (odak için genellikle 3–5 Objective yeterli).

  • Nicelikten çok nitelik vurgusu taşımalıdır.

Örnek Objective:
“Türkiye’de müşteri deneyimi en iyi e-ticaret platformu olmak.”


Key Results (Anahtar Sonuçlar)

Key Results, “Objective’e ulaştığımızı nasıl anlayacağız?” sorusunun cevabıdır.

İyi bir Key Result’ın özellikleri:

  • Ölçülebilir ve sayısal olmalıdır.

  • Zamana bağlı (time-bound) olmalıdır.

  • Zorlayıcı ama ulaşılabilir olmalıdır.

  • Sonuca odaklanmalı, aktiviteye değil.

Örnek Objective ve Key Results:
Objective: “Müşteri memnuniyetini artırmak.”

  • KR1: Net Promoter Score (NPS) değerini 40’tan 60’a çıkarmak.

  • KR2: Müşteri şikayetlerine ortalama dönüş süresini 48 saatten 12 saate indirmek.

  • KR3: Tekrar alışveriş yapan müşteri oranını %25’ten %40’a çıkarmak.


Özet

OKR, yalnızca bir hedef belirleme aracı değil; aynı zamanda strateji, şeffaflık ve ölçülebilirlik üzerine kurulu bir yönetim sistemidir. Google’dan Spotify’a kadar birçok kurumun başarısında OKR’ın büyük payı vardır.

Doğru tanımlanmış Objectives ve net Key Results sayesinde:

  • Organizasyonlar daha odaklı olur,

  • Çalışanlar yaptıkları işin büyük resimdeki değerini görür,

  • Liderler ise stratejiyi günlük işlere daha kolay bağlayabilir.

April 28, 2024 0 comments
0 FacebookTwitterPinterestEmail
Sertifika

PSPO I (Professional Scrum Product Owner) Sertifikası Hazırlık Rehberi

by mlap April 21, 2024
written by mlap

Scrum.org tarafından verilen PSPO I (Professional Scrum Product Owner) sertifikası, birçok kurum için Product Owner rolünün sorumlulukları, ürün vizyonu ve backlog yönetimi bilgisinin ispatı niteliğindedir. Agile organizasyonlarda Product Owner rolü kritik bir noktada yer aldığı için, bu sertifika hem kariyer hem de pratik bilgi açısından güçlü bir referanstır.


Sınav Hakkında Bilinmesi Gerekenler

  • Online yapılmaktadır, istediğiniz zaman girebilirsiniz.

  • Ücret: 200 $

  • Süre: 60 dakika

  • Soru sayısı: 80 soru (%85 başarı → min. 68 doğru).

  • Soru tipleri: Çoktan seçmeli, çoklu doğru/yanlış, doğru-yanlış.

  • Dil: İngilizce.

  • Deadline yok: Satın aldıktan sonra istediğiniz zaman sınava girebilirsiniz.

  • Kaynak kullanımı serbest: Sınav sırasında Scrum Guide veya notlarınızı açabilirsiniz.

  • Sonuç anında açıklanır; geçtiğinizde sertifikanızı PDF olarak indirebilirsiniz.


Sınav İçeriği (Başlıca Konu Başlıkları)

  1. Understanding and Applying the Scrum Framework
    Empiricism, Scrum Values, Roles, Events, Artifacts, Sprint Goal, Definition of Done, Scaling Scrum

  2. Managing Products with Agility
    Forecasting & Release Planning, Product Vision, Product Value, Product Backlog Management, Business Strategy, Stakeholders & Customers

  3. Developing and Delivering Products Professionally
    Emergent Software Development, Managing Technical Risk, Optimizing Flow

  4. Evolving the Agile Organization
    Organizational Design and Culture, Portfolio Planning, Evidence Based Management

  5. Additional Practices
    Product Ownership için tamamlayıcı uygulamalar ve advanced seviyedeki pratikler


Sınava Hazırlık İçin Öneriler

1. Scrum Guide

  • Scrum Guide’ı birkaç kez mutlaka okuyun.

  • Sınav dili İngilizce olduğundan İngilizce versiyonunu tercih edin.

  • Çalıştığınız kurumda kullanılan ama Scrum Guide’da olmayan uygulamaları sınava taşımayın (örn. Sprint 0, Hardening Sprint).


2. Open Assessment’lar

  • Scrum.org’daki Product Owner Open Assessment’ı en az 5 defa %100 olacak şekilde çözün.

  • Ek olarak Scrum Open (PSM I) testlerini de çözün; çok benzer sorular çıkabiliyor.

  • Doğru cevabı bilseniz bile açıklamaları okuyun → kavrayışınızı derinleştirir.


3. Deneme Sınavları

  • Mikhail Lapshin (Learning Mode & Real Mode – özellikle Real Mode gerçek sınava çok benzer).

  • TheScrumMaster.co.uk denemeleri.

  • mPlaza deneme sınavları.


4. Ek Kaynaklar

  • Scrum.org Product Owner Learning Path

  • Scrum.org Forum → gerçek sınav mantığına yakın örnek sorular ve tartışmalar.

  • Evidence Based Management (EBM) Guide → mutlaka okuyun; sınavda EBM soruları çıkabiliyor.

  • Kitap önerileri:

    • The Professional Product Owner: Leveraging Scrum as a Competitive Advantage

    • The Lean Startup – Eric Ries

    • User Stories Applied – Mike Cohn


Kritik Konular (Dikkat Edilmesi Gerekenler)

  • Product Backlog: Tek sorumlu Product Owner’dır. İçeriğin şeffaflığı, önceliklendirme ve değer yönetimi en kritik konular.

  • Product Vision: PO’nun liderlik ettiği, takım ve paydaşları yönlendiren rehber.

  • Forecasting & Release Planning: Release burndown, velocity ve öngörü hesaplamaları.

  • Stakeholder Management: Paydaşlarla sürekli iletişim, beklenti yönetimi, “HAYIR” diyebilme becerisi.

  • Value Maximization: En yüksek değeri sağlayan işlerin önceliklendirilmesi (örn. Kano Model, MoSCoW).

  • Evidence Based Management: Hedeflere ilerlemeyi ölçmek için Key Value Areas (Current Value, Unrealized Value, Time to Market, Ability to Innovate).


Ek Öneriler

  • Günde 30–40 dakika Scrum Guide ve örnek sorulara çalışın.

  • 80 soruluk 60 dk’lık deneme yaparak zaman yönetimini test edin.

  • İngilizce’de kritik kelimelere dikkat edin:

    • “Accountable” → tek sorumluluk Product Owner’da.

    • “Forecast” vs. “Commitment” → Developer’lar sprint planlamada forecast yapar.

    • “Should” vs. “Could” → öncelik farkları.


Sınav Günü Tavsiyeleri

  • Sessiz bir ortam, güçlü internet → sınav öncesi test edin.

  • Yan sekmede Scrum Guide (EN) ve gerekirse Google Translate açık tutabilirsiniz.

  • Önce soru cümlesini okuyun, sonra şıkları inceleyin.

  • “NOT” gibi olumsuz ifadelere dikkat edin.

  • Bookmark özelliği ile emin olmadığınız sorulara geri dönün.

  • Yanlış doğruyu götürmüyor → her soruya mutlaka cevap verin.


Sonuç

PSPO I sertifikası, Product Owner rolünü derinlemesine anlamak isteyenler için önemli bir adım. Doğru kaynakları kullanarak ve bolca pratik yaparak kısa sürede başarıyla geçilebilir. Özellikle Scrum Guide + Evidence Based Management + Open Assessment’lar üçlüsü bu sınavın anahtarıdır.

April 21, 2024 0 comments
0 FacebookTwitterPinterestEmail
Sertifika

PAL I (Professional Agile Leadership) Sertifikası Hazırlık Rehberi

by mlap April 17, 2024
written by mlap

Scrum.org tarafından verilen PAL I (Professional Agile Leadership) sertifikası, bir liderin çevikliğin oluşturduğu değeri anlaması, uygulayabilmesi ve ekiplere liderlik desteği sağlayabilmesi konusundaki bilgisinin ispatıdır. Bu sertifika, çevik ekipleri desteklemenin neden kritik olduğunu ve liderlerin organizasyonel çevikliği artırmak için hangi davranışları sergilemesi gerektiğini ortaya koyar.

Agile dönüşüm sürecinde yalnızca ekiplerin değil, liderlerin de değişmesi gerekir. PAL I sertifikası da tam olarak bu noktada liderlere hem yön hem de ölçüm yapabilme becerisi kazandırır.


Sınav Hakkında Bilinmesi Gerekenler

  • Online yapılmaktadır, istediğiniz zaman girebilirsiniz.

  • Ücret: 200 $

  • Süre: 60 dakika

  • Soru sayısı: 36 soru (%85 başarı → min. 31 doğru).

  • Soru tipleri: Çoktan seçmeli, çoklu doğru/yanlış.

  • Deadline yok: Satın aldıktan sonra istediğiniz zaman sınava girebilirsiniz.

  • Dil: İngilizce.

  • Açık kitap: Sınav sırasında Scrum Guide veya notlarınıza bakabilirsiniz.

  • Sonuç anında açıklanır, geçtiğinizde sertifikanızı PDF olarak indirebilirsiniz.


Sınav İçeriği (Başlıca Konu Başlıkları)

  1. Understanding and Applying the Scrum Framework
    Empiricism, Scrum Values, Scrum Team, Events

  2. Developing People and Teams
    Self-Managing Teams, Facilitation, Leadership Styles

  3. Managing Products with Agility
    Forecasting & Release Planning, Product Value, Stakeholders & Customers

  4. Developing and Delivering Products Professionally
    Emergent Software Development

  5. Evolving the Agile Organization
    Organizational Design and Culture, Evidence-Based Management


Sınava Hazırlık İçin Öneriler

1. Scrum Guide

  • En az birkaç kez okuyun.

  • İngilizce versiyonu çalışmak daha sağlıklı olur, çünkü sınav dili İngilizce.

  • Kendi kurumunuzda gördüğünüz ama Scrum Guide’da olmayan pratikleri (ör. Sprint 0, Proxy PO) sınava taşımayın.


2. Open Assessment’lar

  • Scrum.org’daki Agile Leadership Open Assessment’ı en az 5 kez %100 yapacak şekilde çözün.

  • Ek olarak Scrum Open (PSM I) ve Product Owner Open testlerini çözmek de faydalı olur.

  • Açıklamaları mutlaka okuyun → sınavda işinize yarayacak ipuçları içeriyor.


3. Learning Path ve Forum

  • Scrum.org Agile Leader Learning Path → PAL sınavına yönelik temel içeriklerin toparlandığı yol haritası.

  • Scrum.org Forum → Çıkan örnek sorular ve deneyim paylaşımları.


4. Önerilen İçerikler

  • Evolution of Agile Manager

  • Evolution of Scrum Master

  • Evolution of Product Owner

  • Evolution of the Developers

  • 4 Secrets to Great Agile Leadership

  • 5 Agile Leadership Tips for Creating Mature Scrum Teams

  • 5 Metaphors to Explore the Value of Scrum Values

  • Twenty Top Fails in Executive Agile Leaderships


Kritik Konular (Dikkat Edilmesi Gerekenler)

  • Self-Managing Teams: Scrum 2020’de “self-organizing” → “self-managing” oldu. Liderlerin rolü, takımların kendi hedeflerine doğru hareket etmelerini kolaylaştırmak.

  • Leadership Styles: Kontrol eden yönetici → koçluk yapan, vizyon sağlayan, engelleri kaldıran liderliğe geçiş.

  • Stakeholder Management: Liderin paydaşlar ile Product Owner arasındaki köprü rolü.

  • Evidence-Based Management (EBM): Liderlerin organizasyonun çevikliğini ölçmek için kullanabileceği 4 Key Value Area (Current Value, Unrealized Value, Time to Market, Ability to Innovate).

  • Organizational Design: Agile kültür, hiyerarşiden ziyade ekip bazlı yapılanma, şeffaflık ve empowerment.


Sınav Günü Tavsiyeleri

  • Sessiz bir ortam + güçlü internet.

  • Scrum Guide (EN) + EBM Guide açık dursun.

  • Soru cümlesini dikkatle okuyun → “NOT” ifadelerine özellikle dikkat edin.

  • Çoktan seçmeli sorularda tüm doğru seçenekleri işaretlemeyi unutmayın.

  • Bookmark özelliği ile emin olmadığınız soruları işaretleyip sona bırakın.


Sonuç

PAL I sertifikası, Agile liderlik bakış açısını kanıtlayan güçlü bir göstergedir. Özellikle Scrum Guide + Evidence Based Management + Agile Leadership Open Assessment üçlüsüne odaklanarak kısa sürede başarıya ulaşabilirsiniz.

April 17, 2024 0 comments
0 FacebookTwitterPinterestEmail
Sertifika

PSM I (Professional Scrum Master) Sertifikası Hazırlık Rehberi

by mlap April 15, 2024
written by mlap

Scrum.org tarafından verilen PSM (Professional Scrum Master) I sertifikası, birçok kurum için Agile ve Scrum temel bilgisinin ispatı niteliğindedir. Bu sertifikayı almak düşündüğünüz kadar zor değil. Doğru hazırlıkla kısa sürede geçilebilir. İşte sınavla ilgili bilmeniz gerekenler ve hazırlık önerileri:


Sınav Hakkında Bilinmesi Gerekenler

  • Online olarak yapılmaktadır, istediğiniz zaman girilebilir.

  • Ücret: 200 $ (tek seferlik, şifre alındıktan sonra süre sınırı yok).

  • Süre: 60 dk, 80 soru (%85 başarı yani min. 68 doğru).

  • Soru tipleri: Çoktan seçmeli, birden fazla doğru cevaplı, doğru/yanlış.

  • Dil: İngilizce.

  • Kaynak kullanımı serbest: Sınav sırasında Scrum Guide veya notlarınızı açabilirsiniz.

  • Sınav sonucunu anında öğrenirsiniz, geçtiyseniz PDF sertifikanızı indirebilirsiniz.


Sınav Konuları (5 Başlık)

  1. Understanding and Applying the Scrum Framework
    Empiricism, Scrum Values, Roles, Events, Artifacts, Sprint Goal, Definition of Done, Scaling Scrum

  2. Developing People and Teams
    Self-Organizing Teams, Facilitation, Leadership Styles, Coaching and Mentoring

  3. Managing Products with Agility
    Forecasting & Release Planning, Product Vision, Product Value, Product Backlog Management, Stakeholders & Customers

  4. Developing and Delivering Products Professionally
    Emergent Software Development, Managing Technical Risk, Optimizing Flow

  5. Evolving the Agile Organization
    Organizational Design and Culture, Evidence Based Management


Hazırlık İçin Öneriler

1. Scrum Guide

  • Scrum Guide’ı mutlaka birkaç defa okuyun.

  • Sınav İngilizce olduğu için İngilizce versiyonu tercih edin.

  • Çalıştığınız kurumda gördüğünüz “best practice” uygulamaları (ör. Sprint 0) dikkate almayın, sınavda sadece Scrum Guide esas alınır.


2. Open Assessment’lar

  • Scrum.org’daki Scrum Open Assessment’ı en az 5 kez %100 olacak şekilde çözün.

  • Diğer assessment’ları da çözmek faydalıdır.

  • Doğru cevabı bilseniz bile açıklamalarını okuyun.


3. Deneme Sınavları

  • Mikhail Lapshin (Learning Mode & Real Mode – özellikle Real Mode)

  • TheScrumMaster.co.uk ücretsiz denemeleri

  • mPlaza deneme sınavları

  • Gerçek sınava en yakın deneyimi sağlar.


4. Forumlar ve Ek Kaynaklar

  • Scrum.org’daki forumlardaki tartışmaları okuyun.

  • Scrum Master Learning Path’i inceleyin.

  • Faydalı linkler:

    • Roles in Scrum

    • 5 Powerful Things About Sprint

    • Sprint Review is Much More Than a Demo

    • Scrum Values Poster


Ek Öneriler

Zorlanılan Konulara Dikkat

  • Sprint Cancellation: Kim iptal edebilir? (Sadece Product Owner).

  • Daily Scrum: Scrum Master yönetmez, Developer’lar sorumludur.

  • Definition of Done: Her Increment için geçerlidir.

  • Product Backlog Refinement: %10 kuralı resmi değil, sadece öneridir.

İngilizce Kalıplara Dikkat

  • Should vs. Could: Öncelik farkı vardır.

  • Attend vs. Participate: Katılım türünü ayırır.

  • Facilitation vs. Coaching: Farklı roller.

Gerçek Sınav Simülasyonu

  • 60 dk boyunca 80 soruluk bir deneme yapın.

  • Zaman baskısını test edin.

Peer Learning (Eşle Çalışma)

  • Çalışma arkadaşınız varsa birbirinize rastgele 5 soru sorun.

  • Bir bölümü seçip 2 dakikada özetlettirin.


Sınav Günü Tavsiyeleri

  • Sessiz bir ortamda olun, internetinizi test edin.

  • Yan sekmede Scrum Guide (İngilizce) ve Google Translate açık olabilir.

  • Uzun sorularda önce soru cümlesini okuyun, sonra metni tarayın.

  • NOT kelimesine dikkat edin.

  • Bookmark özelliğini kullanın, emin olmadığınız sorulara geri dönün.

  • Yanlış doğruyu götürmüyor → her soruya cevap verin.


Sonuç

PSM I sertifikası, doğru bir hazırlık planı ve pratikle kısa sürede alınabilecek bir sertifikadır. Scrum Guide’ın mantığını kavrayıp bolca deneme çözerek başarı şansınızı artırabilirsiniz.

April 15, 2024 0 comments
0 FacebookTwitterPinterestEmail
Ölçümleme

Scrum Takımlarında Lead Time ve Cycle Time Kullanımı

by mlap April 8, 2024
written by mlap

Daha önceki yazımda Kanban takımlarında kullanılabilecek Lead Time ve Cycle Time metriklerinden bahsetmiştim. Bu metrikler yalnızca Kanban’a özgü değil; Scrum takımlarında da oldukça faydalı bir şekilde kullanılabilir. Özellikle sprint bazlı ilerleyen Scrum takımlarında bu metriklerin ölçülmesi, israfın ve iyileştirme noktalarının görünür hale gelmesini sağlar.


Lead Time’ın Scrum’da Kullanımı

Scrum takımlarında Lead Time, talebin Product Owner tarafından backlog’a eklenmesiyle başlar. Sayaç, talebin tamamlandığı sprintin son günü durur.

  • Yani, talebin backlog’a alındığı tarih ile tamamlandığı sprintin son günü arasındaki süre Lead Time’dır.

  • Böylece bir talebin “müşteriden gelişinden ürüne dönüşmesine” kadar geçen toplam süre ölçülmüş olur.

Bu metrik, talep sahibinin gözünden değeri üretmenin ne kadar sürdüğünü gösterir.


Cycle Time’ın Scrum’da Kullanımı

Cycle Time ise daha dar bir süreyi kapsar. PBI’ın ilk kez alındığı sprintin başlangıcından, tamamlandığı sprintin sonuna kadar geçen süredir.

  • Bir PBI birkaç sprint boyunca tamamlanamıyorsa, bu durum Cycle Time ile net şekilde görünür hale gelir.

  • Bu da özellikle “tamamlanamayan işler” için farkındalık yaratır ve iyileştirme noktalarını belirlemeyi kolaylaştırır.


Detaylı Hesaplama Yöntemi

Genellikle sprint başlama ve bitiş tarihleri dikkate alınarak ölçüm yapılır. Ancak teknik olarak mümkünse daha hassas bir yöntem tercih edilebilir:

  • Board’da ilgili PBI’ın ilk taskının “In Progress” kolonuna taşınması Cycle Time’ın başlangıcı olarak alınabilir.

  • Son taskın “Done” kolonuna taşınması ise bitiş zamanını belirler.

Bu yöntem, sprint içindeki akışın daha doğru ölçülmesini sağlar.


Scrum Takımlarında Lead & Cycle Time Kullanımının Faydaları

  1. Ortalama süreleri değerlendirme:
    Belirli dönemlerde ortalama Lead ve Cycle Time süreleri takip edilerek, ortalamayı yükselten PBI’lar kolayca tespit edilebilir. Bu sayede iyileştirme yapılması gereken alanlar görünür olur.

  2. Aykırı değerlerin fark edilmesi:
    Scatter (saçılım) grafiği kullanıldığında, diğerlerinden belirgin şekilde uzun süren PBI’lar hemen ortaya çıkar. Bu aykırı değerler incelenerek darboğazların veya engellerin kök sebepleri araştırılabilir.

  3. İş tipine göre analiz:
    Backlog’da iş tipleri (örneğin: yeni özellik, bakım, problem çözme) etiketleniyorsa, ortalama Lead ve Cycle Time değerleri iş tipine göre ayrı ayrı değerlendirilebilir. Bu da hangi iş tipinin süreci yavaşlattığını görmeyi kolaylaştırır.


Sonuç

Scrum takımlarında Lead ve Cycle Time ölçümleri, yalnızca bir sayı üretmek için değil, sürekli iyileştirme kültürünü desteklemek için kullanılmalıdır. Takımlar bu metriklerden elde ettikleri verileri retrospektiflerde değerlendirerek darboğazlarını, gecikme sebeplerini ve süreç iyileştirme fırsatlarını ortaya çıkarabilir.

Böylece yalnızca daha hızlı değil, aynı zamanda daha verimli ve sürdürülebilir bir şekilde değer üretebilirler. 🚀

April 8, 2024 0 comments
0 FacebookTwitterPinterestEmail
Ölçümleme

Agile Takımlarda Ölçülebilecek Metrikler

by mlap April 4, 2024
written by mlap

Agile dönüşüm yolculuğunda takımların en büyük güçlerinden birisi ölçümlemedir. Ölçemediğimiz şeyi iyileştiremeyiz. Ancak Agile’da metrikler yalnızca raporlama için değil, takımın gelişimini desteklemek, engelleri fark etmek ve daha fazla değer üretmek için kullanılmalıdır.

Aşağıda Agile takımlarda kullanılabilecek temel metrikleri 5 ana başlık altında toparladım.


1. Teslimata Odaklı Metrikler

Takımın ne kadar hızlı ve sürdürülebilir şekilde değer üretebildiğini gösterir.

  • Velocity (Hız): Takımın bir sprintte tamamladığı story point miktarıdır. Zaman içinde takımın kapasitesini anlamak, daha gerçekçi planlama yapabilmek için kullanılır.

  • Throughput: Tamamlanan işlerin (PBI, story, task) sayısını gösterir. Story pointten bağımsız, tamamlanan iş adedine odaklanır.

  • Lead Time: Bir işin talep edilmesinden teslim edilmesine kadar geçen süredir. Müşteriye değer üretmenin hızını ölçmek için kullanılır.

  • Cycle Time: İşin “başlanmasından” tamamlanmasına kadar geçen süredir. Takımın akışındaki darboğazları ortaya çıkarmada etkilidir.

  • Release Frequency: Takımın pazara ne sıklıkla yeni ürün/özellik çıkardığını gösterir. Daha sık ve küçük release’ler, müşteri adaptasyonunu hızlandırır.


2. Kalite Metrikleri

Ürünün sürdürülebilirliğini ve müşteri memnuniyetini doğrudan etkileyen alanlardır.

  • Defect Density (Hata Yoğunluğu): Belirli bir iş büyüklüğü başına düşen hata sayısını ölçer. Kalitenin zaman içinde iyileşip iyileşmediğini gösterir.

  • Escaped Defects: Üretime çıktıktan sonra müşteri tarafından tespit edilen hatalardır. Bu metrik kalite güvence süreçlerinin ne kadar güçlü olduğunu gösterir.

  • Automated Test Coverage: Otomatik testlerin ürün kapsamındaki oranıdır. Test kapsamı ne kadar genişse, regresyon hatalarının riski o kadar azalır.

  • Technical Debt (Teknik Borç): Kısa vadeli çözümler yüzünden ertelenen bakım/geliştirme işlerini ifade eder. Ölçülmesi, gelecekte oluşabilecek riskleri öngörmek için kritiktir.


3. Takım Süreci Metrikleri

Takımın iş yapış biçimini ve akışını gözlemleyerek verimliliği artırmaya yardımcı olur.

  • Work In Progress (WIP): Aynı anda üzerinde çalışılan iş sayısını gösterir. Yüksek WIP değerleri odak kaybına ve teslimatların gecikmesine sebep olabilir.

  • Cumulative Flow Diagram (CFD): Akıştaki tüm işlerin durumunu görselleştirir. Darboğazların ve birikmelerin nerede olduğunu anlamayı sağlar.

  • Flow Efficiency: Çalışılan süre ile bekleme süresinin oranıdır. Düşükse takımın fazla beklediğini ve akışın iyileştirilmesi gerektiğini gösterir.

  • Blocking Issues: Takımın ilerlemesini engelleyen veya yavaşlatan işlerin takibidir. Engellerin görünür hale gelmesi çözüm için ön şarttır.


4. Müşteri Değerine Odaklı Metrikler

Agile’ın asıl amacı değer üretmek olduğundan, müşteri odaklı metrikler kritik önemdedir.

  • Business Value Delivered: Takımın tamamladığı PBI’ların iş değeri skoruna göre toplam değerini ölçer. Takımın gerçekten değer yaratan işlere odaklanıp odaklanmadığını gösterir.

  • Customer Satisfaction (NPS vb.): Ürün veya hizmetten memnuniyet seviyesini ölçer. Müşterinin gözüyle başarıyı görmek için en güçlü geri bildirimlerden biridir.

  • Innovation Rate: Backlog’daki yeni özelliklerin oranını ölçer. Yalnızca bakım ve destek değil, yenilik getiren işlerin oranı ürünün geleceğini belirler.

  • Usage Metrics: Çıkan bir özelliğin gerçekten kullanıcılar tarafından ne kadar kullanıldığını gösterir. Kullanılmayan özellikler aslında israfı işaret eder.


5. Takım Sağlığı ve Kültür Metrikleri

Takımın motivasyonu, sürdürülebilirliği ve işbirliği olmadan başarı uzun soluklu olamaz.

  • Team Happiness Index: Takımın kendini nasıl hissettiğini ölçen basit ama güçlü bir metriktir. Anketlerle düzenli olarak takip edilebilir.

  • Engagement Scores: Katılım ve işbirliği düzeylerini ölçer. Katılımcı bir takım, daha yenilikçi ve üretken olur.

  • Retrospective Action Completion: Retrospective’den çıkan aksiyonların uygulanma oranıdır. Gerçek iyileştirme kültürünün oturup oturmadığını gösterir.

  • Knowledge Sharing Frequency: Takım içindeki bilgi paylaşımı sıklığı. Bilgi paylaşımı arttıkça bağımlılıklar azalır, takım daha güçlü hale gelir.


Sonuç

Agile takımlarda metrikler yalnızca bir raporlama aracı değil, öğrenme ve gelişim mekanizmasıdır.
Dengeli bir yaklaşım için:

  • Teslimata bakarak hızımızı,

  • Kaliteye bakarak güvenilirliğimizi,

  • Süreç metriklerine bakarak akışımızı,

  • Müşteri değerine bakarak etkimizi,

  • Takım sağlığına bakarak sürdürülebilirliğimizi ölçmeliyiz.

Bu sayede takımlar hem çıktıyı hem de kültürü geliştirebilir, organizasyon da daha çevik bir yapıya kavuşabilir.

April 4, 2024 0 comments
0 FacebookTwitterPinterestEmail
Ölçümleme

Kanban Takımlarında Temel Metrikler

by mlap April 1, 2024
written by mlap

Agile dönüşüm yolculuğunda metrikler, takımların iyileştirme alanlarını fark etmesine ve eksik noktalarını görmesineyardımcı olur. Scrum takımlarında olduğu gibi Kanban takımları da PBI büyüklüklerini tahminlemek için Fibonacci, T-Shirt Size gibi teknikler kullanabilir. Hatta son zamanlarda tahminlemeyi tamamen kaldırmayı savunan #noestimatingyaklaşımı da yaygınlaşmaktadır.

Bu yazıda ise tahminleme yöntemlerinden değil, Kanban takımlarının temel ölçüm metriklerinden bahsedeceğim.

Kanban’da en sık kullanılan metrikler şunlardır:

  • Lead Time

  • Cycle Time

  • Work In Progress (WIP) Limitleri

  • Throughput

  • Aging Süresi


Lead Time

Tanım: Talep sahibinin ihtiyacı ilettiği andan, işin tamamlanmasına kadar geçen süredir.

  • Sayaç, talep iletildiği anda başlar ve iş tamamlandığında durur.

  • Takım işi hemen ele almasa bile süre işlemeye devam eder.

  • Amaç: Talep edilmesinden tamamlanmasına kadar geçen toplam süreyi ölçmek.

🔎 Faydası: Paydaşlar için en kritik metriktir. Bir talebin hayata geçmesinin müşteri gözünden ne kadar sürdüğünü gösterir.


Cycle Time

Tanım: Takımın talep üzerinde çalışmaya başladığı andan, işin tamamlandığı ana kadar geçen süredir.

  • Eğer iş bloke olduysa, tavsiyem sayaç yine işlemeye devam etsin.

  • Bu sayede darboğazlar daha net görünür.

Faydası: Takımın ne kadar hızlı iş bitirebildiğini gösterir.
İpucu: Lead Time ve Cycle Time mutlaka iş tiplerine göre (Bakım, Problem, Yeni Talep vb.) ayrı ayrı takip edilmelidir. Aksi takdirde ortalamalar yanlış yönlendirebilir.

Kullanılan Görseller:

  • Ortalama Lead/Cycle Time için: Çizgi veya bar grafikleri

  • Aykırı işlerin tespiti için: Scatter Plot (Saçılım grafiği)


Work In Progress (WIP) Limitleri

Tanım: Kanban pratiklerinden biri olan WIP, değer akışındaki istasyonlarda aynı anda çalışılan iş sayısına limit koymaktır.

  • Amaç: Takımın odaklı çalışmasını sağlamak.

  • Aynı anda çok fazla işe başlanması yerine limitlenmiş sayıda işte daha hızlı ilerleme yapılır.

  • Her istasyon için farklı limitler olabilir.

Faydası: İşlerin sürüncemede kalmasını engeller, darboğazları görünür hale getirir.
İpucu: Takımlar deneyimleyerek kendi süreçlerine uygun ideal WIP limitlerini bulmalıdır.


Throughput (Çıktı)

Tanım: Belli bir zaman diliminde tamamlanan PBI sayısıdır.

  • Türkçe karşılığı “çıktı”dır.

  • Mutlaka iş tipine göre takip edilmelidir (örneğin: bakım işleri, yeni talepler, problemler).

Faydası: Takımın üretkenliğini gösterir.

  • “Haftada ortalama kaç iş bitiriyoruz?” sorusunun cevabıdır.

  • Release veya roadmap planlamaları için oldukça faydalıdır.


Aging Süresi (Yaşlanma Süresi)

Tanım: Hâlen devam eden işlerin, değer akışında geçirdiği süredir.

  • Bir anlamda “devam eden cycle time” olarak düşünülebilir.

  • Özellikle daily toplantılarında gündeme alınabilir.

Faydası: Uzayan işlerin tespit edilmesini sağlar.

  • Takım geciken işlere hızlıca aksiyon alabilir.

  • “Neden bu iş hala devam ediyor?” sorusu farkındalık yaratır.


Sonuç

Kanban metrikleri, takımın sürecini görünür ve ölçülebilir hale getirir. Lead Time müşteri perspektifini, Cycle Time takımın hızını, WIP limitleri odaklanmayı, Throughput üretkenliği, Aging ise darboğazları ortaya çıkarır.

Bu metrikler sadece ölçüm için değil, sürekli iyileştirme (Kaizen) kültürünü beslemek için de güçlü bir araçtır.

April 1, 2024 0 comments
0 FacebookTwitterPinterestEmail
Ölçümleme

Scrum Takımlarında Burndown Chart’lar

by mlap March 26, 2024
written by mlap

Agile takımlarını başarıya götüren ve temelinde yer alan en önemli maddelerden birisi deneyimselliktir. Deneyimsel bir süreç oluşturabilmek için Plan – Do – Check – Act (PDCA) döngüsü uygulanır:

  • Plan: Planlama yapılır.

  • Do: Plan hayata geçirilir.

  • Check: Ölçümler ve metriklerle ilerleme değerlendirilir.

  • Act: Çıkan sonuçlara göre kararlar alınır ve döngü yeniden başlar.

Bu döngü, sürekli öğrenme ve iyileşmeyi sağlar. Burada veriler kritik bir rol oynar. Scrum takımlarının değerlendirme yaparken başvurduğu en önemli veri kaynaklarından biri ise metriklerdir.


Story Point

Scrum metriklerinin başında Story Point gelir. Story Point’in herhangi bir birimi yoktur, takımdan takıma farklılık gösterebilir. Bu sebeple bazı kurumlarda Velocity, Jelibon, Bonibon gibi farklı isimlerle de anılabilir.

Story Point tahminlemesinde genellikle Fibonacci serisi kullanılır. Her bir Product Backlog Item (PBI) için tahmin yapılır. Sprint sonunda:

  • Tamamlanan PBI → DONE

  • Tamamlanmayan PBI → NOT DONE olarak kabul edilir.

Story Point verisi, takımın gidişatı hakkında farkındalık oluşturmak için grafiklere dönüştürülür.


Burndown Chart Çeşitleri

1. Story Point Burndown Chart

  • Sprint bazlı olarak kalan işlerin Story Point cinsinden gösterildiği grafiktir.

  • Amaç, sprint boyunca işlerin ilerleyişini ve kalan yükü görünür kılmaktır.

  • Bu grafik sayesinde:

    • Takımın sprint içinde waterfall yaklaşımına kayıp kaymadığı,

    • Uzmanlık alanlarının paralel mi seri mi çalıştığı,

    • PBI’ların daha küçük parçalara bölünme ihtiyacı olup olmadığı değerlendirilebilir.


2. Efor Burndown Chart

  • PBI altındaki task’lar için saat cinsinden efor tahminleri üzerinden çizilir.

  • Sprint boyunca toplam kalan eforun takibini sağlar.

  • Yorumlamalar:

    • Baseline’ın üzerinde ilerliyorsa → Önceliği düşük PBI’lar NOT DONE olabilir, takım yüksek öncelikli işlere odaklanmalıdır.

    • Baseline’ın altında ilerliyorsa → Takım ek iş almayı değerlendirebilir.

Bu grafik, günlük planlamalarda önemli karar desteği sağlar.


3. Product Burndown Chart

  • Takımın ürünle ilgili tüm backlog işlerini ne zaman tamamlayacağına dair öngörü verir.

  • Dinamik yapısıyla değişimleri hızlıca gösterir.

  • Paydaşların stratejik kararlar almasına yardımcı olur.

  • “Ürün hedefi ne kadar uzakta? Takım bu hedefe hangi hızla yaklaşıyor?” sorularına cevap verir.


4. Release Burndown Chart

  • Product Burndown Chart’a benzer; tek farkı sadece belirli bir release kapsamındaki işleri kapsamasıdır.

  • Bir release’in ne zaman tamamlanacağına dair öngörü verir.

  • Ürün geliştirme yolculuğunda paydaşlar için somut ve güvenilir bir takip aracıdır.


Sonuç

Scrum metrikleri, takımın deneyimsel öğrenme döngüsünü (PDCA) sağlıklı işletmesini destekler. Burndown chart’lar ise takıma ve paydaşlara net görünürlük sunar. Böylece olası riskler erken fark edilir, öncelikler daha doğru belirlenir ve takımın sürdürülebilir değer üretimi güvence altına alınır.

March 26, 2024 0 comments
0 FacebookTwitterPinterestEmail
Newer Posts
Older Posts

Recent Posts

  • Cornell Not Tutma Tekniği ile Etkili Notlar
  • Growth Mindset ve Fixed Mindset: Hangi Düşünce Yapısına Sahipsiniz?
  • Agile Dönüşüm Yolculuğunda Başarıya Götüren Unsurlar
  • Agile Takımlarda Performans Yönetimi
  • Psikolojik Güvenlik: Takımların Başarıya Giden Yolu

Recent Comments

No comments to show.

© 2023 KaizenHub.net | by MLAP.TR

Kaizen Hub
  • Home