Home Agile & Lean
Category:

Agile & Lean

Agile & Lean

Grand Retrospective Nedir?

by Muhammed Lap
written by Muhammed Lap

Retrospective etkinlikleri, Agile takımların yaptığı işi, süreçleri, ilişkilerini ve iletişimlerini değerlendirerek daha iyiye gitmelerini sağlayan etkinliklerdir. Bu etkinlikler, organizasyonlarda sürekli iyileştirme (Kaizen) kültürününgelişmesini destekler.

Ancak sadece tek bir takımda değil, birden fazla takım veya grubun katılımıyla da gerçekleştirilebilir. İşte bu noktada Grand Retrospective devreye girer.

Grand Retrospective Tanımı

Grand Retrospective, birden fazla takımın veya grubun katılımıyla, daha uzun periyotlarla yapılan retrospective etkinlikleridir.

  • Akışı, klasik bir retrospective ile benzerlik gösterir.

  • Farkı, katılımcı sayısının fazla olması ve daha uzun bir zaman diliminin kapsanmasıdır.

  • Katılımcı kitlesine ve ele alınacak konuya özel bir akış tasarlandığında etkinliğin verimliliği çok daha artar.

Ne Zaman Grand Retrospective Yapılır?

  • Takımlar arası sıkıntılar: Takımların birbirleriyle yaşadıkları sorunların sebeplerini ortaya çıkarmak, ilişkileri iyileştirmek ve ortak aksiyonlar belirlemek için.

  • Uzun dönem değerlendirmeleri: 6 ay, 1 yıl gibi periyotlarda; bir ekip, birim veya kurumun genel süreçlerini, başarılarını ve eksiklerini değerlendirmek için.

  • İlerleyişi takip etmek için: Daha önce belirlenen iyileştirme aksiyonlarının uygulanma durumunu gözden geçirmek için.

  • Yakın çalışan takımlar: Birbiriyle yoğun etkileşimde bulunan takımların, işbirliklerini, süreçlerini ve ilişkilerini düzenli olarak geliştirmeleri için.

  • Farklı seviyelerde organizasyon: Sadece çalışanlar değil, yönetim ekipleri, üst yönetimler veya farklı kurumlar arasında bile yapılabilir.

Katma Değerleri

  • Farklı bakış açıları: Çok sayıda ekip ve bireyin katılımı, sorunlara ve çözümlere geniş bir perspektif kazandırır.

  • Kurumsal öğrenme: Takımlar sadece kendi deneyimlerinden değil, diğer ekiplerin yaşadıklarından da ders çıkarır.

  • İletişim ve işbirliği: Birimler arası etkileşimi güçlendirir, empatiyi artırır.

  • Stratejik farkındalık: Takımlar kendi seviyelerinden çıkıp organizasyonun büyük resmiyle hizalanma fırsatı bulur.

Sonuç

Grand Retrospective, klasik retrospective’lerin organizasyon çapında genişletilmiş bir versiyonu olarak düşünülebilir. Birden fazla çalışan, grup, takım ya da yönetim seviyesinin katıldığı her ortamda uygulanabilir. Düzenli gerçekleştirildiğinde, sadece takımların değil, tüm organizasyonun iyileşme yolculuğunu güçlendirir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

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

by Muhammed Lap
written by Muhammed Lap

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

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

“Bizim Agile Böyle” Söylemi: Yanlış Yorumlar, Doğru Yaklaşımlar

by Muhammed Lap
written by Muhammed Lap

Agile dönüşüm geçiren kurumlarda bir süre sonra sıkça duyulan bir cümle vardır:
👉 “Biz artık Agile uygulamıyoruz, biz Xce Agile uyguluyoruz.”
(X yerine genellikle kurumun adı gelir.)

Peki neden böyle denir?

En çok karşılaştığım gerekçelerden bazıları şunlar:

  • Agile’da deadline yoktur, bizde deadline baskısı var.

  • Agile’da yönetici rolü yoktur, bizde yönetici var.

  • Yönetici sprint ortasında takıma ek iş getiriyor.

  • Yönetici takımın işlerine müdahale ediyor.

  • Bizden sürekli deadline istiyorlar.

  • Yönetici refinement’a katılıyor.

  • Review toplantısında yönetici, zor soruları paydaşların önünde soruyor.

Liste uzatılabilir.

Agile Çerçeveler Neden Yetmez?

En çok bilinen Agile yaklaşımı olan Scrum, sadece 12 sayfalık bir dokümandır. Çerçevenin sınırları bellidir ama hayatın içindeki tüm senaryoları kapsaması mümkün değildir.

Scrum’un kurucularından Jeff Sutherland bu durumu şöyle açıklıyor:
👉 “Scrum Guide’ı bilerek yarım bıraktık.”

Bu da demek oluyor ki:

  • Agile Manifesto prensipleri yol gösterici olmalı

  • Kurumun kültürüne ve takımın yapısına uygun pratikler ve teknikler geliştirilmelidir

Bu, Scrum’a ya da Agile’a aykırı değil, tam tersine çevikliğin sürdürülebilirliği için gereklidir.

Kurumların da Gelişim Eğrisi Var

Scrum Master, Product Owner veya Developer’ın bireysel gelişim eğrisi olduğu gibi, kurumların da Agile olgunluk eğrisi vardır.

Bir organizasyon Agile prensiplerini bir anda içselleştiremez.

  • Önce öğrenir,

  • Sonra hatalardan ders çıkarır,

  • Zamanla olgunlaşır.

Burada kritik nokta şudur:
👉 “Bizim Agile böyle” diyerek yanlış uygulamaları sahiplenmek yerine, kök sebepleri düzeltmeye odaklanmak gerekir.

Araçlar Amaç Haline Gelmemeli

Unutmamamız gereken en önemli nokta:

  • Scrum, Kanban veya diğer metotlar birer araçtır.

  • Amaç, organizasyonun gerçekten çevik değer üretmesidir.

Araçları amaç haline getirdiğimizde, Agile dönüşüm özünden uzaklaşır.

Yanlış Agile Yorumları vs. Doğru Agile Yaklaşımları

Yanlış Yorum Doğru Yaklaşım
“Agile’da deadline yok, bizde var o yüzden biz Agile değiliz.” Agile’da esnek planlama vardır. Değer üretmeye odaklanılır, teslimatlar öngörülen zaman kutuları (sprint) içinde yapılır.
“Yönetici yok, ama bizde var.” Agile’da yöneticiler farklı bir rol üstlenir: Engelleri kaldıran, vizyonu anlatan, takımı destekleyen liderlerdir.
“Yönetici sprint ortasında iş getiriyor.” Acil işler için buffer ayrılabilir, diğer işler backlog üzerinden planlanır.
“Review’de yönetici zor sorular soruyor.” Review, şeffaflık ve geribildirim ortamıdır. Sorular değerlidir; doğru şekilde fasilite edilmelidir.
“Bizim Agile farklı, biz böyle yapıyoruz.” Scrum/Agile çerçevesi temel prensipleriyle korunur, kurumun kültürüne uygun pratiklerle zenginleştirilir.
0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Takım yapısını geliştirme tekniği: Yetkinlik pazarı

by Muhammed Lap
written by Muhammed Lap

Agile takımların güçlü bir takım ruhu oluşturabilmeleri için üyelerin birbirlerini tanımaları büyük önem taşır. Farklı kişiliklere, ilgi alanlarına ve yetkinliklere sahip bireyler, paylaşımları arttıkça daha güvenli, güçlü ve verimli bir takım haline gelirler. Bu noktada, Lyssa Adkins’in Coaching Agile Teams kitabında detaylandırdığı Yetkinlik Pazarı (Market of Skills) etkinliği etkili bir tekniktir.

Amaç

Takım üyelerinin birbirlerinin yeteneklerini, ilgilerini ve hobilerini öğrenmesini, böylece hem profesyonel hem de kişisel düzeyde daha güçlü bağlar kurmasını sağlamak.

Süre ve Katılımcı

  • Katılımcı sayısı: 5–7 kişi

  • Süre: 30–60 dakika

Gerekli Araçlar

  • Fiziksel ortamda: Flipchart kağıdı + post-it + kalem

  • Uzaktan ortamda: Post-it destekli whiteboard uygulamaları (Miro, Mural vb.)

Katılımcılara Sorulacak 3 Soru

  1. Belirgin Yetkinlikler / Özellikler: Organizasyonda aktif olarak kullandıkları teknik veya teknik olmayan beceriler.

  2. Gizli Yetkinlikler / Özellikler: Organizasyonda kullanılmayan ama sahip olunan yetkinlikler, hobiler veya özel ilgi alanları.

  3. Öğrenmek İstedikleri: Takım arkadaşlarından öğrenmek istedikleri beceriler veya konular.

Uygulama Aşamaları

  1. Fasilitatör flipchart üzerine bir tezgah (market standı) çizer.

  2. Katılımcılara 10–15 dakika süre verilir; herkes 3 soruya ilişkin yanıtlarını post-it’lere yazar.

    • Belirgin özellikler → tezgahın üstüne

    • Gizli özellikler → tezgahın altına

    • Öğrenmek istedikleri → tezgahın çevresine

  3. Her katılımcı yazdıklarını sırayla ekibe anlatır, soruları yanıtlar.

  4. Benzer yetkinlikler gruplandırılır, ortak öğrenme alanları belirlenir.

Kazanımlar

  • Takım üyeleri birbirlerinin belirgin ve gizli yetkinliklerini öğrenir.

  • Destek olabilecekleri noktalar görünür hale gelir.

  • Takım içi öğrenme fırsatları belirlenir (ör. eğitim konuları).

  • Paylaşım arttıkça iş ile ilgili konularda da daha rahat konuşulur, fikir alışverişi ve geribildirim kültürü gelişir.

  • Takım daha hızlı uyum sağlar ve ortak gelişim süreci hızlanır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Agile Takımlarda Takdir Kültürü: Kudo Kartları

by Muhammed Lap
written by Muhammed Lap

Agile takımlar gelişimlerini sürdürürken yalnızca iyileştirme noktalarını belirlemekle kalmaz, aynı zamanda birbirlerini takdir ederek motivasyonlarını artırırlar. Çoğu retrospective pratiğinde iyi yapılanların dile getirildiği, teşekkürlerin paylaşıldığı bir alan bulunur. Bu noktada Kudo Kartları, basit ama etkili bir araç olarak öne çıkar.

Kudo Kartlarının Kökeni

Jurgen Appelo’nun Management 3.0 kitabında tanımladığı Kudo Kartları, bir teşekkür ve takdir notu olarak düşünülebilir. Kısacası, yüzdeki gülümsemenin yazıya dökülmüş halidir.

Kudo Kartları ile verilen teşekkürler anlık bir geri bildirimdir. Takdir yalnızca yöneticilerden çalışanlara doğru değil; iş arkadaşları arasında da olmalıdır. Hiyerarşik konumdan bağımsız herkes birbirine olumlu geri bildirim verebilir.

Kartların Başlıkları

Kudo Kartları farklı başlıklarda hazırlanabilir. Jurgen Appelo’nun önerdiği İngilizce başlıklardan bazıları:

  • Thank You

  • Congratulations

  • Many Thanks

  • Totally Awesome

  • Very Happy

  • Great Job

  • Well Done

Bu başlıklar kuruma, kültüre veya dile göre özelleştirilebilir.

Kudo Wall (Takdir Duvarı)

Kudo Kartlarının gücünü artırmak için kartların yer aldığı bir Kudo Wall oluşturulabilir. Bu duvar, teşekkürlerin ve takdirlerin herkes tarafından görülebileceği bir alana (örneğin ortak kullanım alanına) yerleştirilir. Uzaktan çalışan takımlar içinse dijital panolarda aynı görünürlük sağlanabilir.

Neden Önemli?

Samimi bir teşekkür, insanları mutlu eder, motivasyonu artırır ve yapılan işe değer kattığını hissettirir. Kudo Kartlarıyla kurulan takdir kültürü, yalnız bireysel motivasyonu değil, takımın bağlarını da güçlendirir.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Agile Dönüşümde Plus-Delta Chart ile Geribildirim

by Muhammed Lap
written by Muhammed Lap

Agile yaklaşımının temelinde sık geribildirim almak vardır. Dönüşüm yolculuğunun sağlıklı ilerlemesi için her aşamada geribildirimlerin toplanması kritik önem taşır. Gelen geribildirimler, dönüşümün sürekliliğini sağlamada en önemli araçlardan biridir.

Bu noktada en etkin yöntemlerden biri Plus-Delta Chart tekniğidir. Bu yöntem sayesinde herhangi bir konu, süreç ya da etkinlik hakkında hedef kitleden anonim şekilde geribildirim toplanabilir. Anonim olması, katılımcıların endişe duymadan ve filtresiz şekilde görüşlerini paylaşmalarını kolaylaştırır.

Plus-Delta Chart Nedir?

Plus-Delta Chart iki basit başlık üzerinden ilerler:

  • Plus (+): İyi yapılan, güçlü yönler, devam edilmesi gereken noktalar.

  • Delta (Δ): Geliştirilmesi, değiştirilmesi veya iyileştirilmesi gereken noktalar.

Bu yöntem, hem başarılı uygulamaları görünür kılar hem de iyileştirme fırsatlarını netleştirir.

Kullanım Alanları

  • Organizasyonel Dönüşüm:
    Örneğin bir kurum Agile dönüşüm sürecindeyse, tüm çalışanlardan dönüşümle ilgili anonim geribildirimler toplanabilir. Çalışanlar güçlü buldukları uygulamaları (Plus) ve geliştirilmesi gereken yönleri (Delta) rahatlıkla paylaşabilir.

  • Etkinlik veya Eğitim Sonrası:
    Bir workshop, sprint review ya da eğitim sonunda hızlıca geribildirim almak için kullanılabilir.

  • Takım İyileştirmeleri:
    Takım içinde süreçlerin, ritüellerin veya iş yapış biçimlerinin değerlendirilmesi için düzenli kullanılabilir.

Uygulama Yöntemleri

  • Fiziksel Ortamda:
    Beyaz tahta veya flipchart üzerine iki kolon açılır. Katılımcılar post-it’lere görüşlerini yazar ve ilgili başlığa yapıştırır.

  • Uzaktan Çalışmada:
    Miro, Mural, EasyRetro gibi dijital board uygulamaları kullanılarak aynı etki yaratılabilir. Bu sayede dağıtık çalışan takımlar da kolayca katkı sağlayabilir.

📌 Sonuç:

Plus-Delta Chart, yalın ama etkili yapısıyla Agile kültüründe sürekli iyileştirmeyi destekleyen pratik bir araçtır. Düzenli kullanıldığında hem takım hem de organizasyon seviyesinde değerli içgörüler ortaya çıkarır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Agile Dönüşümde Takım Kurulumu Öncesi Hazırlıklar

by Muhammed Lap
written by Muhammed Lap

Agile dönüşüm yolculuğu, ilk adım olan takım kurulumu ile başlar. Ancak takım kurulmadan önce yapılacak bazı hazırlıklar, ileride yaşanabilecek problemlerin önüne geçmek için kritik öneme sahiptir. Sağlıklı bir dönüşüm başlatmak ve sürdürülebilir kılmak için aşağıdaki adımlara dikkat edilmelidir.

1. İlgili ekiplerle ön görüşmeler yapılması

Dönüşüm başlamadan önce ilgili ekiplerle bir araya gelinmeli, dönüşüm ihtiyacı ve amaçları konuşulmalıdır.

  • Takımın mevcut iş yapış şekilleri,

  • Agile prensiplerinin nasıl uygulanabileceği,

  • Dönüşümden beklentiler ele alınmalıdır.

Bu görüşmelerde Agile koç veya danışman, doğru soruları sorarak ihtiyacı en iyi karşılayacak çerçeveye/metoda karar verilmesini kolaylaştırır.

2. Uygulanacak metod/çerçevenin seçilmesi

Scrum, Kanban veya farklı Agile yaklaşımları arasında seçim yapılmalıdır. Bu karar, takımın iş yapış şekline ve sorumluluk alanına en uygun yöntemi belirlemek açısından önemlidir.

3. Yönetim ile düzenli iletişim kurulması

Agile dönüşüm sadece takımları değil, yöneticilerin rollerini de etkiler. Bu nedenle:

  • Yönetimle düzenli (tercihen haftalık) toplantılar yapılmalı,

  • Soru-cevap seansları düzenlenmeli,

  • Yeni sorumluluk ve roller hakkında bilgilendirme sağlanmalıdır.

Böylece yöneticiler dönüşüm sürecine daha hazırlıklı girer.

4. Eğitimlerin verilmesi

Takımın seçeceği çerçeve/metod (örneğin Scrum veya Kanban) ile ilgili kapsamlı bir eğitim verilmelidir. Eğitimde sadece teorik bilgi değil, uygulamaya yönelik örnekler de olmalıdır. Böylece takım, dönüşüme başlamadan önce soru işaretlerinden arınmış olur.

5. Product Owner’ın belirlenmesi

Product Owner seçimi kurumdan kuruma değişebilir. Deneyimlerime göre bu rol çoğunlukla yönetim tarafından atanıyor. Beklentilerin yüksek olduğu bu rol için doğru ismin yönetim tarafından seçilmesi genellikle daha sağlıklı bir yöntemdir.

6. Product Owner’a aktarım yapılması

Agile koç, Product Owner’a rol ve sorumluluklarını net bir şekilde aktarmalıdır. Özellikle:

  • Product Backlog yönetimi,

  • Backlog’un nasıl hazırlanacağı,

  • İlk backlog (initial backlog) oluşturma ipuçları paylaşılmalıdır.

7. Initial Product Backlog’un hazırlanması

Takım kurma etkinliklerinden önce Product Owner’ın initial backlog’u hazırlaması gerekir. Bu sayede takım, ilk planlama etkinliklerine daha hazır girer ve dönüşüm süreci daha güçlü başlar.

✅ Sık Yapılan Hatalar

Agile dönüşümün ilk adımı olan takım kurulumu sırasında sıkça yapılan bazı hatalar şunlardır:

  • Eğitimlerin yüzeysel verilmesi: Sadece teori aktarımıyla yetinilen eğitimler, uygulama aşamasında takımın çok zorlanmasına sebep olur.

  • Product Owner’ın hazırlıksız atanması: Rolün beklentileri yüksek olmasına rağmen PO’nun rolüne dair aktarım yapılmadan sahaya sürülmesi başarısızlığa davetiye çıkarır.

  • Initial backlog’un eksik hazırlanması: İlk backlog’un boş, olgunlaşmamış veya önceliklendirilmemiş olması planlama toplantılarının verimsiz geçmesine neden olur.

  • Yönetim ile iletişimin ihmal edilmesi: Yöneticiler dönüşümün dışında bırakıldığında hem destek eksikliği olur hem de ilerleyen süreçte direnç artar.

  • Çerçeve seçiminin yanlış yapılması: Sadece popüler olduğu için Scrum veya Kanban seçmek yerine takımın iş yapışına uygun olan yöntem tercih edilmelidir.

📌 Sonuç:

Agile dönüşümün başarısı, doğru kurulan takımlarla başlar. Takım kurulmadan önce yapılan bu hazırlıklar ve hatalardan kaçınılması, hem dönüşümün sağlıklı başlamasını hem de sürdürülebilir olmasını sağlar.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Agile Takımlarda Motivasyonu Sürdürülebilir Kılmak

by Muhammed Lap
written by Muhammed Lap

Geleneksel yazılım geliştirme yöntemlerinde özellikle büyük projelerden sonra genellikle bir “light dönem” yaşanırdı. Bu dönemde ekipler, önceki projenin yorgunluğunu atar, araştırmalar yapar, kendini geliştirir, biraz da “kafasını toplardı”. Hatta iş başvurularında sıkça duyduğumuz self motivation kavramı için güzel bir örnektir.

Motivasyonun zaman zaman maaş artışı veya ek imkanlarla artırılabildiği bilinse de, bunun kalıcı olmadığı araştırmalarla ortaya konmuştur. Liderlerin etkileyici konuşmaları da motivasyonu yükseltebilir; fakat onların etkisi de bir süre sonra azalır. Örneğin, Süreyya Ciliv’in konuşmalarının çalışanlarda uzun süreli bir coşku uyandırdığı bilinir, ancak bir noktadan sonra yine “normal”e dönülür.

Ardından, organizasyon Agile dönüşüm yolculuğuna başlar. Artık işler küçük parçalara bölünür; sprintler veya iterasyonlarla sürekli değer üretmeye odaklanılır. Fakat burada bir fark vardır: Bir sprint biter bitmez, hemen bir sonraki sprint başlar. Geleneksel yöntemlerdeki “light dönem” artık yoktur. Bu da zamanla, çıktıların kalitesinde, takım içi iletişimde ve motivasyonda düşüşlere yol açabilir.

Peki, Agile takımlarda motivasyonu nasıl sağlarız?
Burada hem takımlara, hem liderlere, hem de Agile dönüşümünü yöneten rollere önemli sorumluluklar düşmektedir.

Takımın Yapabilecekleri

  • Sürdürülebilir hız:
    Yoğun dönemler doğal olarak yaşanır. Ancak sürekli fazla mesai yapmak, bir süre sonra bıkkınlık yaratır ve teknik borçları artırır. Yoğun bir sprintten sonra kısa süreliğine “vitesi düşürmek”, uzun vadede daha verimli çalışmayı sağlar.

  • Product Owner ile doğru denge:
    Product Owner’ın her talebe “Evet” demesi, takımı tükenmişliğe sürükleyebilir. Aynı şekilde takım üyelerinin de “HAYIR” diyebilmesi kritik bir yetkinliktir. Doğru önceliklendirme yapılmadığında motivasyon hızla kaybolur.

  • Kişisel gelişime zaman ayırmak:
    Sprint backlog’una kişisel gelişim için küçük işler eklemek, hem bireysel motivasyonu hem de takımın uzun vadeli verimliliğini artırır.

  • İş dışı iletişim:
    Takım içindeki küçük sohbetler, kahve molaları veya online oyunlar bile iletişimi ve aidiyeti güçlendirir.

Liderlerin Yapabilecekleri

  • Doğru eşleşme ve rotasyon:
    Takım üyelerinin güçlü olduğu işlerde yer almaları motivasyonu artırır. Zaman zaman yapılan rotasyonlar da farklı deneyimlerle iş tatminini yükseltir.

  • Sorun çözme desteği:
    Takım içinde çözülemeyen kişisel veya iş kaynaklı sorunlara liderlerin koçluk etmesi ve gerekirse reorganizasyonla çözüm sağlaması önemlidir.

  • Şeffaf iletişim:
    Liderlerin tüm takımı ilgilendiren konuları şeffaf bir şekilde paylaşması, güven ortamı yaratır.

  • Sosyal aktiviteler:
    İş dışında düzenlenen etkinlikler, takımın deşarj olmasını sağlar. Bu aktiviteler, uzun vadede motivasyonu yüksek tutan önemli araçlardır.

Agile Dönüşümünü Yöneten Rollerin Yapabilecekleri

  • Oyunsallaştırma (Gamification):
    Takımların ortak hedefler doğrultusunda motive olması için oyunlaştırma yöntemleri kullanılabilir. Hem eğlenceli hem de öğretici bir deneyim yaratır.

  • Pratik çeşitliliği:
    Her takım aynı değildir. Takımların dinamiklerine göre farklı pratikler, teknikler geliştirmek tekdüzeliği ortadan kaldırır.

  • Kültürü güçlendirmek:
    Agile prensipler sadece takım seviyesinde değil, organizasyon genelinde kültür haline gelmelidir. Eğer Agile sadece “takım bazlı” kalırsa, zamanla eski geleneksel yöntemler geri döner.

Sonuç

Agile dönüşüm yolculuğunda motivasyonun sürekliliği, yalnızca takımlardan değil, liderlerden ve dönüşümü yönetenlerden de sorumluluk almayı gerektirir. Sürdürülebilir motivasyon, sürdürülebilir değer üretiminin en büyük anahtarıdır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Product Owner Bir Sprinti Nasıl Geçirir?

by Muhammed Lap
written by Muhammed Lap

Scrum’da bulunan üç rolden biri olan Product Owner, takım tarafından gerçekleştirilecek işlerin listesi olan Product Backlog’un yönetiminden sorumludur. En değerli işlerin öncelikli olarak ele alınmasını sağlamak onun temel sorumluluğudur.

Sprint Başlangıcı: Planlama

Sprint, Sprint Planlama etkinliği ile başlar. Product Owner bu etkinliğin ana aktörüdür.

  • Planlama öncesinde, öncelikli işlere göre sıralanmış ve refine edilmiş bir backlog hazırlar.

  • Planlama sırasında takıma, ele alınacak işlerin NE yapılacağı ve NEDEN değerli olduğu hakkında net bilgi verir.

  • Takımın sorularına cevap verir, gerekli yönlendirmeleri yapar.

Göründüğü kadar kolay değildir; planlama öncesi hazırlık, araştırma ve paydaşlarla iletişim bu sürecin önemli bir parçasıdır.

Sprint Süresince: Takıma Destek ve Backlog Yönetimi

  • Sorulara Hazır Olmak: Takım geliştirme sırasında birçok noktada bilgiye veya karara ihtiyaç duyacaktır. Product Owner, bu ihtiyaçları hızlıca karşılamalıdır.

  • Backlog’u Refine Etmek: Bir sonraki sprint için backlog’u hazırlamak Product Owner’ın sürekli sorumluluğudur. Bu iş zaman alıcıdır ve çoğu zaman developer’ların desteğini de gerektirir.

  • Takımla Yakın Çalışmak: Aynı lokasyonda olamasa bile özellikle uzaktan çalışmada daily’lere katılım, iletişimin güçlü kalmasını sağlar. Bu katılım, hem takımdan gelen sorulara cevap vermek hem de sürece yakın olmak açısından faydalıdır.

Sprint Sonu: Review ve Retrospective

  • Sprint Review: Product Owner, bu etkinliğin başrol oyuncusudur.

    • Ürünün geldiği noktayı paydaşlara sunar.

    • Sunumun sadece kendi tarafından değil, konu bazlı olarak takım üyeleriyle birlikte yapılmasına özen gösterir.

    • Paydaşlardan gelen geribildirimleri toplar ve uygun olanları backlog’a ekler.

  • Sprint Retrospective: Product Owner bu etkinliğe katılımcı olarak dahil olur.

    • Diğer takım üyeleri gibi fikirlerini paylaşır.

    • Sürecin iyileşmesine katkı sağlar.

✅ Özetle: Product Owner’ın sprint boyunca rolü; doğru işleri seçmek, takıma netlik sağlamak, backlog’u sürekli olgunlaştırmak, paydaşlarla köprü olmak ve ürünün değerini artırmak için sürekli çalışmaktır.

0 comments
0 FacebookTwitterPinterestEmail
Agile & Lean

Scrum Master Bir Sprinti Nasıl Geçirir?

by Muhammed Lap
written by Muhammed Lap

Scrum’da üç temel rolden biri olan Scrum Master, takımın Scrum’ı doğru anlamasını, uygulamasını ve önündeki engellerin kaldırılmasını sağlamakla sorumludur. Peki bir Scrum Master sprint boyunca neler yapar?

Sprint Başlangıcı: Planlama

Her sprint Sprint Planlama ile başlar. Scrum Master’ın buradaki görevi, etkinliğin verimli ve kurallarına uygun şekilde gerçekleşmesini sağlamaktır.

  • Takımın, Product Backlog’dan seçilen PBI’ların NEDEN değerli olduğunu anladığından emin olur.

  • Developer’ların NE yapılacağını netleştirmelerini ve NASIL yapılacağına dair task’ları oluşturmasını destekler.

  • Taskboard’un sprint başında hazır ve güncel olmasını sağlar.

Sprint Süresince: Takip ve Destek

Sprint boyunca Scrum Master’ın sorumlulukları devam eder.

  • Daily Scrum’lar:

    • Daily’nin her gün aynı saatte başlamasını ve 15 dakika içinde bitmesini sağlar.

    • Uzayabilecek konuları o anda park ettirip daily sonrası detaylı konuşulmasını teşvik eder.

    • Takımın engelleri dile getirmesi için cesaretlendirir.

  • Metrikler ve Görselleştirme:

    • Daily sonrası sprint bazlı metrikleri (ör. burndown chart) takip ederek takımı aksiyon almaya yönlendirir.

    • Haftada 1–2 kez board’un genel üzerinden geçerek atlanan konuların fark edilmesini sağlar.

  • Engellerin Yönetimi:

    • Takımın impediment backlog’unu gözden geçirir, çözülmesi için gerekli adımları atar.

  • Takımın Gelişimi:

    • Takımı self-organize olmaya teşvik eder, belirlenen kurallar çerçevesinde otonom hareket etmelerini destekler.

    • Liderler ile takım arasında ortak anlayışın gelişmesi için inisiyatif alır.

Sprint Sonu: Review ve Retrospective

Sprintin son gününde Scrum Master’ın rolü kritik hale gelir:

  • Sprint Review:

    • Takımın etkinliğe hazırlanmasını, ürünün en iyi şekilde sunulmasını teşvik eder.

    • Review sırasında gözlem yaparak iyileştirme fırsatlarını belirler ve bunları Retrospective gündemine taşır.

  • Sprint Retrospective:

    • Etkinliğin etkin bir şekilde fasilite edilmesini sağlar.

    • Önceki retrospective aksiyonlarının takibini yapar.

    • Takımla birlikte yeni aksiyonların belirlenmesine destek olur ve sürekli iyileşme kültürünü yaşatır.

✅ Özetle; Scrum Master’ın rolü sprint boyunca planlamanın kalitesini sağlamak, sürecin akışını kolaylaştırmak, engelleri kaldırmak ve takımı sürekli gelişime yönlendirmektir.

0 comments
0 FacebookTwitterPinterestEmail
Newer Posts
Older Posts