Scrum çerçevesindeki 3 rolden birisi Product Owner, çoğu yerde kısaltma olarak kullanıldığı üzere PO. 

Bir Scrum takımnda doğru ürünü geliştirmek için uzmanlık ve yetkinlikleri yeterli bir Geliştirme takımının var olması elzem. Bir o kadar elzem olan da doğru kişinin Product Owner olması. Yeni bir takım kurulurken genellikle organizasyonla birlikte yaptığımız önemli çalışmalar arasında

• Üzerinde çalışılacak ürün/servise göre doğru kişiyi PO olarak seçmek konusunda destek olmak
• PO’ın Geliştirme takımını doğru yönlendirebilmesi , paydaş ve müşteri beklentilerini yönetebilmesi ve en karlı ve değerli işlerin yapılması için Product Backlogu güncel ve yaşar tutması için yeni yetkinlik ve teknikleri kazandırmak oluyor.

Bunun için PO’ın 3 anahtar özelliğe sahip olması gerekiyor; konu uzmanlığı, karar verebilme yetkisi ve çok önemli olan ve çoğu zaman organizasyon tarafından gözardı edilebilen zaman. Zaman önemli çünkü PO hem geliştirme takımıyla vakit geçirebilmeli(sadece Sprint planlama ve review’a katılmak yeterli değil) hem de Paydaş, sponsorlarla vakit geçirebilmeli. Karar verebilmesi önemli, takıma hız ve çeviklik kazandıran en önemli unsurlardan birisi takımı klasik organizasyondaki hiyerarşiyi, karar mekanizmalarını beklemeden PO’dan yanıtlarını alabilmesi ve geliştirmeye devam edebilmesi. Konu uzmanlığı da en değerli işleri ve neyin yapılabilip yapılamayacağı konusunda öngörüsünün olması ve böylece backlog yönetimini en iyi şekilde yapabilmesini sağlıyor.

Bana göre 3 önemli özelliğe ek bir konu daha var ;PO’luk rolü ve Scrum’daki diğer 2 rol yani ScrumMaster ve Geliştirme takımı eşlenik seviyelerde roller yani PO, Geliştirme takımının üstü değil, Scrum takımındaki aynı seviyedeki rollerden biri. Dolayısıyla PO olacak kişinin PUSH tarzında olmayan,takımın yöneticisi tarzında çalıştığını düşünen bir kişi de olmaması gerekiyor.

İşte bütün bu özellikleri taşıyabilen birisinin PO rolünü üstlenmesi iyi olacaktır.

Product Ownerlar Geliştirme takımı Sprinte başlamadan çok önce ürün/servis vizyonundan başlayarak Product Backloga doğru işleri almak, sıralamak için çalışmaya başlarlar. İster yeni ürün geliştirilsin, ister mevcut üründe geliştirme yapılsın ,pazar araştırması sonuçlarını incelemek, son kullanıcı deneyim beklentisini, sponsor beklentilerini anlamak ve Şirketin vizyonuyla uyumlu ve ekibe motive güzel bir ürün/servis vizyonu hazırlamak başlangıçta yaptıkları işler arasındadır. O yüzden sadece Sprint review ve planlama toplantılarına katılırım diye düşünülüyorsa PO’lar  görevlerini eksik yapmış olurlar.

Agile Product Ownerlık rolünü yakından tanımak için size tavsiye edebileceğim Henrik Kniberg’ten kısa bir  videoyu  izlemenizi tavsiye ederim.

Ben kendim PO’luk yaptığım zamanda ya da yeni PO olan kişilere önerdiğim ve etkin olduğunu düşündüğüm bir araç var ; Kendileri için özelleştirebilecekleri  ve kendilerin kontrol edebilecekleri bir check list. Bu yeni yetenek ve sorumluluklarımızı  otomatik olarak düşünmeden alışkanlık haline getirinceye değin ya da sonrasında da atlamamak için kullanabilecekleri, ihtiyaca ve deneyime göre güncelleyecekleri bir liste.

Unutmayalım check listleri kullanmaktaki amacımız raporlama yapmak değil, gelişigüzel , kullanmayacağımız, israf olacak döküman doldurmak değil, bunu kendimizi denetlemek ve gelişim aracı olarak kullanmamız.:)

PO’luk zor iş ve zamanla kendini geliştiren kişilerle çalışma fırsatım oldu. Dolayısıyla PO’lukla ilgili söylenebilecek çok fazla şey olmakla birlikte bu yazımda bu check listle ilgili bir kaç öneri ve kaynak paylaşacağım. İhtiyaca yönelik istediğinizi kullanmak , kendinize göre adapte etmek PO’larımızın elinizde.

Henrik Knibergle başlamışken onun diyagram şeklindeki check listi bu örneklerden birisi. Henrik Kniberg linkinden bu check liste ulaşabilirsiniz.

Product ownerla ilgili okuduğum ve tavsiye edeceğim kaynaklardan birisi de Roman Pichler.  Bu kitabı severek ve rahat okuduğum bir kitap olarak tavsiye edebilirim.

“

Yine Roman Pichler’den örnek olarak hazırlanmış bir check listede  Roman Pichler check list bu linki tıklayarak ulaşabilirsiniz.

Bir diğer tavsiye edebileceğim kaynak ise Robert Gallen’ın Scrum Product Ownership Kitabı. Sorularınız olduğunda konu başlıklarına dönüp bakabileceğiniz bir kitap.

Elbette User story konusunda Mike Kohn’un kitaplarınıda unutmamak lazım.

Son olarak paylaşabileceğim  Lare Ekman tarafından tarafından oluşturulmuş ve aşağıda görebileceğiniz üzere Türkçeye çevrilmiş olan bir check list. Burada herbir madde için kendinize puan verebilir ve sonuçta sorumluluklar listesinde kaç üstünden kaçı tamamlayabildiğinizi, kendinizi geliştirmek için odaklanacağınız alanları seçebilirsiniz.

Lare Ekman Check list

Ürün Vizyonu

• Müşteri, son kullanıcılarla beraber oluşturulmuş bir ürün vizyonuna sahibim.
• Ürün vizyonu hakkında soruların soruları net, özlü ve motive edici biçimde yanıtlayabiliyorum.
• Ürün vizyonunun basit, doğru şekilde anlaşılmasına yarayan ve releaselerimin değerini vurgulayan ilgi çekici bir anahtar iletişim söylemim var. Örneğin ‘’cebinizde 1000 şarkı’’(ıpod 2011)

Paydaşlar

• Müşteri, son kullanıcı ve paydaşlarımın ihtiyaçlarını anlıyorum.
• Paydaşların ihtiyaçlarını anlamak ve taleplerini yönetmek için onlarla düzenli iletişim halindeyim.
• Paydaşlar tarafından yetkilendirildiğime ve bana güvenin tam olduğuna eminim ve Ürün sahibi olarak çalışmaktan dolayı motiveyim.
• Takımımın hızı ve çıktı performansı doğrultusunda paydaşlarıma taahhütte bulunurum.

Ürün Kapsamı

• Paydaşlar ve tüm takımın rahat bir şekilde ulaşabildiği, net ve açık ifadelerle düzenlenmiş bir ürün kapsamım var.
• Ürün kapsamı hakkında karar verme yetkisi bana ait.
• Ürün kapsamını en azından her Sprint planlama toplantısı öncesinde düzenli olarak güncelliyorum.
• Ürün kapsamındaki maddeleri değer, bağımlılık, riski gözeterek doğru şekilde sıralıyor ve önceliklendiriyorum.
• Ürün kapsamındaki maddeler net bir şekilde açıklanmış ve yakın sprintlerde alınacak işler takım tarafından rahatlıkla anlaşılacak detayda düzenliyorum
• Takımla birlikte düzenli şekilde ürün kapsamı yenileme seansı yapıyoruz.

Değer

• Takımla beraber yarattığımız değeri ölçümlemek için doğru şekilde set edilmiş KPI larımız var.( sadece hız değil, kalite, technical debt gibi birçok boyutu ele alan)
• İşlerin fayda anlamında getirisini en yüksek seviyeye çekmek, hızlı ve erken teslimatı sağlarken kaliteli işler çıkması sağlamak için takımla beraber tanımlamdığımız BİTTİ tanımı ve ürün kapsamındaki her iş tanımı için Sprint kapsamı öncesinde çalıştığımız kabul kriteri var.
• BİTTİ kriteri daha kaliteli sonuç üretmek ve yetkinliğimiz geliştirmek için zaman içinde gelişme gösterir.
• Çevik ürün/ servis geliştirme sürecini sürekli iyileştirerek değeri optimize etmek için uygula-ölç-öğren döngüsünde çalışıyorum.

Takım

• Takımın bana rahatlıkla ve her an ulaşabilir.
• Ürün kapsamında nihai söz yetkisi bana ait ve takımıma ürün kapsamı dışında farklı yerlerden iş talebi ulaşmamakta, tüm paydaşlar taleplerini bana ileterek ürün kapsamı tarafından yönetilmektedir.
• Takımımım geliştirme yetkinliğine güveniyorum.
• Ürün kapsamının erken, kaliteli ve hızlı teslimatı için takımda yeterli yetkinlik olmaması halinde eğitim, doğru takımla çalışma gibi gereken aksiyonları alırım.
• Ürün kapsamındaki işlerle ilgili tahminlemeyi takım yapar.
• Önceliklendirilmiş ürün kapsamından Sprint kapsamına alınacak işleri takımım seçer, onlara iş atamam.

Scrum Master

• Takımın ve benim güvendiğimiz ve inandığımız bir Scrum Masterımız var.
• Scrum Masterla uyumlu bir işbirliğimiz var.

Scrum Aktiviteleri

• Sprint planlama toplantılarına katılırım,   takım tarafından ürün kapsamının net anlaşılması için gerekli açıklamaları veririm.
• Sadece Sprint değerlendirme toplantısında değil Sprint boyunca takımla beraber çalışarak gelişime yönelik geribildirim veririm.
• Sprint değerlendirme toplantısında paydaşlarımıza takımla beraber çıkarttığımız ürün parçasının üstünde gözlem yapıp geribildirim alırız, Sprint değerlendirme toplantılarına paydaşların katılımını sağlarım.
• Sprint kapsamındaki işlerin BİTTİ ve kabul kriterlerine uygun olacak şekilde ürün parçasına dönüşmesini teyit ederim.
• Süreç gözden geçirme toplantılarına katılarak takımımdan geribildirim alır, ürün sahibi olarak işimi gözlemleyip geliştirmek üzere aksiyon alırım.
• Scrum’ın değerlerini biliyor ve bunları uyguladığıma taahhüt ediyorum.( Taahhüt, odak, açıklık, cesaret, saygı)

Toplam skor :31                 Gerçekleşen:(kişisel skorum)

Deneyimlerime göre PO Scrum çerçevesinde yer alan bir rol olarak bilinmekle birlikte doğru ürün/hizmet geliştirmek için yöntem ve çerçeveden bağımsız başarıyı destekleyen en kritik rollerden biri. Bu yazıda bir nebze olsun bunu hissettirmek istedim, sonraki yazılarda diğer roller ve ipuçları devam edecek.

Görüşmek üzere,