OKR’NİN İLHAM KAYNAĞI; SCRUM VE ÇEVİKLİK (AGILITY) MANİFESTOSU

OKR’NİN İLHAM KAYNAĞI; SCRUM VE ÇEVİKLİK (AGILITY) MANİFESTOSU
NEDEN VE NASIL OKR? / YAZI-5
Önceki yazılarımızda OKR uygulamasının kökeninde günümüzün Kaotik İş Dünyası’nın ‘’YENİ NORMALİ’’ni ifade etmek için kullanılan VUCA ve onun panzehiri sayılan VUCA PRIME kavramlarının bulunduğunu ve VUCA dünyasıyla başa çıkmak için geliştirilen yeni uygulamaları ifade etmek ve “eski” – “yeni” farkını vurgulamak için literatürümüze giren en önemli kavramın ise “Agility (Çeviklik)” olduğunu belirtmiş ve şu sıralar sıkça duyduğumuz SCRUM ve OKR’nin ise VUCA dünyasının yeni normaline uyum için geliştirilen en popüler uygulamalar olduğunu söylemiştik.

Her ne kadar; bazı SCRUM kuramcıları ve uygulamacıları VUCA kavramına doğrudan vurgu yapmasa da ve bu uygulama salt yazılımcılar içinmiş gibi algılansa da tanımına “çevikliği” koymasıyla ve VUCA girdabına karşı VUCA PRIME’IN en temel kavramlarını esas almasıyla ve de artık tüm alanlarda  uygulanmasıyla bizce net bir şekilde kökenini VUCA’dan almakta ve OKR’ye ilham vermektedir.

Bu yazımızda SCRUM kavramına kısaca değineceğiz.
En genel anlamıyla Scrum;, “VUCA dünyasındaki karmaşık ürün geliştirme süreçlerini yönetmek için kullanılan Çevik (Agile) bir proje yönetimi çerçevesidir.”
Scrum, önce yazılım dünyasına 2000’li yıllarda bir “Çevik Yazılım Geliştirme” yaklaşımı olarak girmiş ve giderek tüm “Proje Yönetimi” metotlarına yayılmış bir yöntemdir. Günümüzde ise Scrum’ın kaynağı olan “agility (çeviklik)” ise artık iş dünyasının her alanına damgasını vurmuş ve vurmakta olan yeni paradigmanın adıdır.

Scrum, İngilizce’de kelime anlamı olarak “itişip kakışma” demektir. Bu ismin; bir projeyi hayata geçirme sürecinin, Amerikan futbolunda topun oyuna sokulması sırasındaki hücum ve defans oyuncuları arasındaki öngörülemeyen hengameyi andırması sebebiyle verildiği belirtiliyor.

2001 yılının şubat ayında yazılım dünyasının önde gelen 17 ismi Utah’da bir araya gelerek yazılım geliştirme üretkenliğini arttırmaya yönelik 2 günlük beyin fırtınası yapmışlar ve “Çevik Yazılım Geliştirme Manifestosu” ve “Çevik Yazılımın Prensipleri”ni yayınlamışlardır.

Daha sonra Ken Schwaber ve Jeff Sutherland tarafından 2010 yılında kaleme alınan “Scrum Guide (Scrum Kılavuzu)” adı verilen kitapçık ile Scrum uygulamalarının tüm adımları belirlenmiştir.

Bu yaklaşım, insanlara, değerlere ve taahhütlere dayanmaktadır. Agile Manifestosunda 4 değer ve 12 prensip bulunmaktadır.

Manifestodaki 4 değer şöyle ifade edilmiştir;

“Bizler;

1. Süreçler ve araçlardan ziyade bireyler ve etkileşimlere,

2. Kapsamlı dökümantasyondan ziyade beklentileri karşılayan yazılıma,

3. Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine,

4. Bir plana bağlı kalmaktan ziyade değişimlere ve yeniliklere açık olmaya,

odaklanmaya kanaat getirdik.

Sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız.”

Manifestoda yer alan 12 Prensip ise şöyledir;

1. En önemli önceliğimiz yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.

2. Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.

3. Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.

4. İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.

5. Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.

6. Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüz yüze iletişimdir.

7. Çalışan yazılım, ilerlemenin birincil ölçüsüdür.

8. Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.

9. Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.

10. Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca elimine edilmesi sanatı, olmazsa olmazlardandır.

11. En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.

12. Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Geleneksel Proje yönetim ile Çevik (Agile) Proje Yönetimi arasındaki uygulama farklarına bir göz atalım şimdi de. Çünkü bu farklar, OKR yaklaşımını anlamamıza da ışık tutacaktır.

Geleneksel yöntemde, istenen ürün/program ile ilgili veriler müşteriden alınır ve sürece başlanır.

Süreç bitene kadar hazırlanan ürün/program müşteri ile genelde paylaşılmaz ve bu süreçte tamamen en iyisi yapılmaya odaklanır. Fakat biz bununla uğraşıp zaman kaybederken piyasanın ihtiyaçları değişmiş ve müşterinin ihtiyacına uygun ürünler çoktan piyasaya çıkmaya başlamıştır bile. En iyisini yapsak dahi bu durum bizi piyasanın gerisinde bırakabilir. Fakat bunun yerine projeyi müşterinin ihtiyacını kısmen de olsa karşılayabilecek daha küçük parçalara bölsek, her bir kısmı bitirdiğimizde müşteriye test edebileceği kısımlar vererek onun ihtiyacını karşılamaya odaklansak, müşteriyi en baştan kazanarak onun da istekleri doğrultusunda ilerlemek çok daha kolay olur.

Geleneksel proje yönetimiyle yapılan bir projede, proje bittikten sonra bazı değişimler istendiğinde oluşturduğumuz nihai ürün üzerinde bu değişimler yapılamayabilir. Fakat Çevik (Agile) yaklaşımında amaç, olabilecek tüm değişimlere açık olmaktır ve ürünü müşterinin istekleri doğrultusunda  
güncelleyebilmektir.

Scrum, temelde ürünü ufak parçalara bölerek, düzenli aralıklarla çalışan bir çözüm çıkartmayı ve bunu müşteriyle test etmeyi önerir. Bunu da düzenli aralıklarla bir araya gelerek yapar. Müşteri beklentisi, ürünün boyutu vs. gibi durumlar değerlendirilerek, 1–4 hafta arasında bir sprint süresi belirlenebilir.

Sprint süresinin ardından ise, Backlog adı verilen bir ürün iş listesi oluşturulur. Ürünle ilgili işlere yönelik tüm kullanıcı hikayeleri/user story’ler çıkartılır ve backlog’a eklenir. Kullanıcı hikayeleri/user story’ler ile yenilenmiş backloglara uygun yeni sprintler başlar.

Ekipte sadece aşağıdaki roller yer alır ve aralarında herhangi bir resmi hiyerarşi bulunmaz. Proje Yöneticisi diye bir rol yoktur. Ekipler oluşturulurken, 3 temel motivasyon kaynağına sahip olunmasına dikkat edilmelidir.

. Amaç; Amaç etrafında herkes net ve kenetlenmiş olmalıdır.

. Özerklik; Ekip dışında herhangi bir kişiden emir, komuta alınmaz.

. Uzmanlık; Ekip tamamen işi bilen, yapan kişilerden oluşmalıdır. (tek tip yerine farklı alanlarda uzmanlıklar olabilir)

“Agile; komuta mekanizmasına karşıdır. Cross-functionality’i (çapraz fonkisyonaliteyi) destekler.” Bir Scrum takımındaki roller şöyledir;

> Scrum Master / Scrum Koçu

> Product Owner / Ürün Sahibi

> Development Team / Proje Ekibi, Geliştirme Ekibi

Sprint toplantıları sırasıyla aşağıdaki amaçlarla yapılır;

> Sprint Planlama; Scrum Master Product Owner’ın beklentilerini karşılayacak şekilde backlog’da maddeleri listeler ve geliştirme ekibi de yapabileceklerini seçer. Ardından story’ler, task’a dönüştürülür. Bu listeye Sprint İş Listesi denir.

> Günlük Scrum; Scrum ekibinin günlük olarak ayakta yaptığı toplantılardır. 3 soruya cevap aranır; “Dün; ekibe hedeflerine ulaşması için nasıl yardımcı oldum?”, “Bugün nasıl yardımcı olacağım?”, “Hedeflere ulaşmada herhangi bir engel görüyor muyum?”

> Sprint Gözden Geçirme; Sprint sonunda tüm Scrum takımının bir araya gelerek, ürün teslimini yaptığı toplantıdır.

> Retrospektif; Sprintlerin ardından yapılan, geri bildirim ve iyileştirme planı oluşturma seansıdır. Ekip, sprint sürecinde yaşadıklarıyla ilgili birbirine geri bildirimler verir. “Neleri iyi yaptık?”, “Neleri daha iyi yapabiliriz?”, “İş yapış tarzını iyileştirmek için neler yapabiliriz?” soruları üzerinde konuşulur.

Scrum metodolojisi, OKR yöntemiyle pek çok yönden benzerlik göstermekte ve bize göre ona ilham vermektedir. Çünkü her ikisi de VUCA dünyası üzerinde “Agility (Çeviklik)” özellikleri bağlamında gelişmiştir. Köken aynıdır. VUCA PRIME.