Bir SAFe kurulumu çalıştırmak ve kendi kararlarını alabilen ve yalnızca Özellik Komisyoncuları ve İş Listesi Yöneticileri olarak hareket etmeyen Ürün Sahiplerini güçlendirmek gerçekten mümkün mü? Evet, SAFe'yi statik bir hedef olarak görmememize ve ürün odaklılığa yatırım yapmamıza izin verirsek.
Yetkili Ürün Sahipleri, Scrum takımlarının tam potansiyelini ortaya çıkarmanın anahtarıdır. Hepimiz bunu biliyoruz. Ancak bir SAFe kurulumunda, PO'ların Takım İş Listesi Yöneticilerine (veya " Hikaye Sahiplerine”). Bunun nedeni, bir yandan Ürün Yönetiminin, Program İş Listesindeki özelliklerin keşfini, iyileştirilmesini ve önceliklendirmesini yönlendirirken (daha kolaylaştırıcı ve uyumlu bir duruş sergilemek yerine), diğer yandan geliştiricilerin kırılmaya ana katkıda bulunmasıdır. hikayelere ayrılmıştır ve genellikle hikayeleri PI ve sprintler için belirli bir sıraya göre sıralamak için çok iyi teknik nedenlere sahiptir. PO'lar, geliştiricilere, hikayelerin de alan bilgileriyle değer katması ve katkıda bulunması gerektiğini hatırlatabilir, ancak ekibin asıl odaklandığı şey, Program İş Listesinden özellikler sunmak ve PI Hedeflerini karşılamaktır, bu da PO'ları üzerinde çok az söz bırakabilir. ürünlerin gerçek yönü. Öyleyse, SAFe PO'sunu nasıl güçlendiririz ve katma değerini nasıl artırırız?
Cevap, Ürün Sahibi rolünün asıl amacına geri dönmekte yatıyor. Bunu nasıl yapacağınız aşağıda açıklanmıştır:
İlk adım, ürünlerini yaşayan ve soluyan Scrum takımları ve ürünlerinin başarısından (daha fazla) sorumlu olan PO'larla Scrum köklerine geri dönmektir. Bunu söylemek, büyük kuruluşlarda yapmaktan daha kolaydır, ancak ilk adım, yetkilendirilmiş, hesap verebilir PO'ların daha iyi ürünlere yol açacağına güvenmek ve inanmaktır.
A) Yönetim düzeyinde, PO'ları güçlendirmenin 'neden' ve 'nasıl' olduğu konusunda anlaşın ve bunu genişletilmiş Ürün Yönetimi ekibiyle (PM ve PO'lar) uyumlu hale getirin.
B) Genişletilmiş Koruyucu Bakım ekibinde, ART içindeki ürünleri tanımlayın ve net ürün tanımları oluşturun (örneğin, ekip ve paydaşlarla bir Ürün Vizyon Kurulu çalıştırarak ).
C) Ürün tanımlarına bağlı olarak, Sistem Mimarı ve ihtiyaç duyulan geliştiricilerin ürünleri tasarlamasını sağlayın, böylece net kesimler ve arayüzler elde etsinler ve gelecekteki PI için gerekli işi planlayın. ART dışındaki ekiplere bağımlılıklar varsa, bu harici ekipleri ART'nize dahil edip etmeyeceğinizi tartışın. İçine bak kireç çözme uygulamaları .
D) PO'lar ürünleri kendi aralarında dağıtır (ekip üyesi temsilcileri dahil olmalıdır). PO sayısı ile ürün arasında bir yanlış eşleşme varsa, bunu pragmatik olarak çözün (örneğin, iki takım bir ürünü paylaşır veya bir takım iki ürüne sahiptir).
E) Her bir PO, yöneticileriyle üründen sorumlu hale getirildikten sonra büyümeleri gereken yetkinlik alanlarını belirler (örneğin, ticari becerilerini geliştirmek).
ART'deki her bir PO, hangi ürün (ler) için sorumlu olduklarını bildiğine göre, ekibin geri kalanının sahiplenmesini sağlamanın zamanı geldi. Ekibin buraya gelmesi gerektiğinin farkına varılması, Geliştirme Değer Akışı boyunca uzanan bir Özellik Ekibi olmaktan ziyade, tek bir ürüne odaklanmış bir Ürün Ekibi olacağıdır.
A) Her ekip, gelecekteki değişiklikler, Ürün Ekibi olarak yeni odak noktaları, Ürün Vizyon Kurulu, fırsatlar, zorluklar, beklentiler vb. Konusunda dahili olarak uyum sağlar.
B) Ekibin ürüne özgü öğrenimini hızlandırmak için ekibin ürünüyle ilgili ekip dışı uzmanları iyileştirme oturumlarına (ve potansiyel olarak geliştirme sırasında) davet edin.
C) İleriye dönük olarak, PO'lar ürünle ilgili tüm keşifleri, stratejileri, yol haritalarını, pazara uyumu vb. Yönlendirir.
D) Ekibin ürününün fayda gerçekleştirmesini ölçmesini ve bunu genişletilmiş Ürün Yönetimi ekibi aracılığıyla tüm ART'ınkine sunmasını sağlar.
Net ürün tanımlarına sahip Ürün Ekipleri içeren bir ART'de, artık iki yeni kuralı tanıtabileceğimiz için program düzeyinde toplu birikime çok az ihtiyaç vardır:
1. Bir özellik, ürüne özgüdür.
2. Özellikler, Takım Bekleme Listelerine yerleştirilir.
Bu yeni kuralları dikkate alarak, farklı senaryoların nasıl ele alınacağı aşağıda açıklanmıştır:
Öyleyse, PO'lara ürünlerinin tam mülkiyetini alma yetkisi verildiğine göre, Başbakan şimdi ne yapmalıdır? Kısacası, ART'nin ürün portföyünün kolektif katma değerini, işletmenin stratejik yönü ve Değer Akışının odağı ile uyumlu hale getirmelidirler.
A) Proje Yöneticisinin yönlendirdiği ART vizyonu, stratejisi ve üst düzey yol haritasının PO'lar için ürün keşfine rehberlik etmesini sağlayın.
B) Her bir PI Planlamasından sonra, Proje Yöneticisi, ürüne özgü ekip PI Hedeflerinin Program PI Hedeflerinde toplanmasını sağlar.
C) Proje Yöneticisini, işletme düzeyindeki kararlarla uyum sağlama konusunda PO'ların kavga ettiği stratejik ortak yapın.
PI Planlama, SAFe'deki gerçekten harika şeylerden biridir - eğer bağımlılıkları ve teslimatları ekipler arasında uyumlu hale getirme ihtiyacı varsa , yani. Artık ürün odaklı olduğumuza ve PO'ları güçlendirdiğimize göre, PI Planlamanın odak noktası artık ürünler arasındaki kalan bağımlılıkları ortadan kaldırmak olabilir .
A) Bağımlı ekipler, bağımlılıkları ortadan kaldırmak için gereken işi belirlemek ve planlamak için işbirliği yapar. Bu çalışma, belirli PI Hedeflerine adanmıştır.
B) Bağımlı olmayan ekipler, PI için çalışmalarını tahmin etmek için PI Planning'i kullanır ve ürüne özgü PI Hedefleri oluşturur; bu da Proje Yöneticisi, daha sonra Program PI Hedeflerini çıkarır.
C) Her bir PI Planlamasından sonra, ART, PI Planlarına sahip olup olmayacağını veya ekiplerin artık takıma özel planlama ve uzun vadeli tahminlerin yeterli olacağı kadar ayrılıp ayrılmadığını değerlendirir.
Bu neredeyse söylemeye gerek yok, ancak özellikle başlangıçta, bağımlılıklar tamamen kaldırılana kadar PO'ların ekipler arasında sık sık hizalanması önemlidir. PO Eşitleme veya PI Planlama için beklemeye gerek yoktur; PI Planning'de meydana gelen etkileşimlerin PI aracılığıyla geçici olarak gerçekleşmesini istiyoruz.
Belki hayır, ama asıl soru şu: olmak zorunda mı? SAFe'nin organizasyonel bağlamınıza uyarlanması gerektiğini unutmayın, bu nedenle ART ve ürünlerinizin kolektif katma değerini artırmak için gerekli olanı yapın. Belki de SAFe PO'larını olduğu gibi tutmak sizin için en iyi seçimdir, belki yukarıdaki noktaları takip etmek, hatta belki de tümüyle kireç çözme yapmaktır. Hangi yolu seçerseniz seçin, yaklaşımınızı incelemeye ve uyarlamaya devam etmeyi ve bunu yaptığınız gibi yapmanın nedenlerini sürekli olarak düşünmeyi unutmayın. Şelale, SAFe, Scrum veya Kanban olsun.
Ciddi Scrum için yazmak mı yoksa Scrum'ı ciddi şekilde tartışmak mı istiyorsunuz?
Hız ve Kapasite planlaması arasındaki farkları önceki bir makalede anlatmıştım, ancak bu makalede, ekiplerim için iyi çalıştığı kanıtlanmış sprint planlama yaklaşımını paylaşıyorum. Bu yaklaşımı paylaşarak, bunun mutlak gerçek olduğunu kastetmiyorum.
Kullanıcılara değer sunmak zor Değer nerede? Ürünler üretirken değer sunmak her zaman 1 numaralı odak noktamızdır. Bir uygulama değer getirmiyorsa ve bir kullanıcının karşılaştığı bir sorunu çözmesine yardımcı olmuyorsa hiçbir ilgisi yoktur.
Bugün farklı bir yolculuğa çıkıyoruz. Çoğunlukla resimler.
26 Temmuz'da Kilise, Meryem Ana'nın ebeveynleri olan Aziz Joachim ve Anne'yi inançları ve azimleri için anıyor. İşte ailemin hikayesi - hayatlarını sadelik içinde yaşayan ve bize yedi çocuğuna yaşam boyu eğitim veren basit bir çift.
Bu ay tüm yeni abonelerimize ve yazarlarımıza sıcak bir karşılama; sürülerinizde ortaya çıkıyorsunuz ve bunun için size teşekkür ediyoruz. Burada harika bir topluluk oluşturuyoruz ve yorumlarınızı ve makalelerinizi okumak harika.
Amerikalı koşucu Athing Mu, profesyonel kariyerinde ilk kez 800 metrelik bir yarışı kaybedebilirmiş gibi görünüyordu. Mu, tipik olarak, az kol hareketi ve görünüşte az enerji içeren benzersiz ve zahmetsiz bir adımla yarışlarına hükmeder.