Merhaba sevgili arkadaşlar,
Bugün ekiplerin bir araya gelerek birlikte hızlı ve çevik şekilde çalışmalarını sağlayan Scrum modelinden bahsetmek istiyorum. Bu modeli Jeff Suttlerland tarafından kaleme alınan "İki katı işi yarı zamanda yapma sanatı: Scrum" adlı kitabını özetleyerek yapacağım.
Öncelikle Scrum kelimesinin nereden geldiğine bakmalıyız. Scrum Rugby sporunda bir takımın topu sahanın diğer ucuna götürmek için birlikte çalışma yöntemine denmektedir. Scrumda ekiplerin doğru bir dizilişte bir araya gelmesi ve doğru zamanda doğru hareketleri yapabilmesi çok önemlidir. Scrumda önemli olan büyük işler başarabilmek için ekiplerin bir araya getirilmesidir. Ekipler sadece en sondaki hedefe odaklanmazlar. Belirledikleri kısa vadeli hedefleri başara başara çalışmalarına devam ederler.
Scrumda planlama önemlidir ama çok detaylı bir planlama için efor harcanması doğru bulunmaz. Çünkü planlama ne kadar güzel yapılırsa yapılsın, mutlaka planlarda bir sapma olur ve bunun sonucunda bir düzensizlik meydana gelir. Eğer daha üst düzeyde bir planlama yapılır ve kısa vadelerde daha detay planlamalar gerçekleştirilirse bu durumda planlardan sapmalar azalır.
Yapılan işler kısa dönemli döngüler halinde denetlenmelidir. Hatta bunun en güzeli mümkün olan en kısa zamanda müşteriye bir ürün önerisinde bulunup müşterinin gerçek aksiyonlarını anlamaktır. Böylece eğer başarısız bir proje yapılıyorsa bunun başarısız olduğu erkenden anlaşılır ve gereksiz yatırım yapılmaz. Bu erken aşamada müşteriye gösterilen ürüne MVP (minimum viable product denir). Aşağıda bunun hangi aşamada olması gerektiğini ifade eden bir grafik vardır.
 |
| MVP nin Piyasaya Çıkması |
Müşterinin geri bildirimi ile ürün veya hizmet geliştirmede farklı bir yöne doğru ilerlemek gerektiği ortaya çıkabilir. Bu şekilde scrumı en iyi şekilde uygulayan şirketlerde %800'e yakın bir üretkenlik artışı görülürken, ortalama ekiplerde ise bu üretkenlik artışı %300'ün altında olmamaktadır. Hatta işin kalitesi de 2 kattan fazla artmaktadır.
Scrumda ekipler bir araya getirilirken yönetim modelinini de mutlaka bu ekibe uygun hale evrilmesi gerekmektedir. Yöneticiler bu modelde ürün geliştirmeyi ekiplerine nasıl yapacaklarını söyleyen değil, onların önündeki engelleri ortadan kaldırmaya yönelik çalışan liderler olarak görev yapmalıdır. Elbette ekiplerin de bazı özellikleri barındırmaları gerekmektedir. Bunlara kısaca bakarsak;
- Üstünlük: Bu ekiplerin sıradanlığın ötesinde bir amaç duyguları vardır.
- Otonomi: Ekipler kendi kendilerini organize ederler. İşlerinin nasıl yapılacağı noktasında kendi kararlarını alma noktasında yetkindirler. Stratejik hedef koymak yönetimin sorumluluğundadır fakat o göreve nasıl ulaşılacağı ise ekibin sorumluluğundadır.
- Çapraz Fonksiyonluluk: Ekipler projeyi tamamlamak için tüm yeteneklere sahip olmalıdır. Bu anlamda, planlama, tasarım, üretim, satış ve dağıtım aynı ekipte ele alınmalıdır.
Ekiplerin boyutu da oldukça önemlidir. Ekip dinamiği küçük ekiplerde işler. Klasik bir scrum ekibinde 7 kişi vardır ama bu artı eksi 2 kişi olarak değişebilir. Brooks yasasına göre gecikmiş bir yazılım projesine insan gücü ilave etmek onu daha da geciktirir. 1990 larda yapılan bir araştırmaya göre ekip üye sayısı 8'in üzerine çıktığında işlerin tamamlanması kayda değer şekilde uzun sürmektedir. 3 ile 7 kişi arasındaki ekipler aynı işi tamamlamak için 9 ile 20 üyesi olan ekiplere göre 4 kat hızlı olabilmektedir.
Ekiplerin bir diğer önemli özelliği ise bir sorunla karşılaştıklarında birbirlerini değil sistemi sorgulamalarıdır. Eğer bir engel çıkmışsa ve bir sorun ile karşılaşmışlarsa neden olarak birbirlerini göstermezler.
Ekiplerin içerisinde bir ürün yöneticisi ve bir scrum danışmanı (scrum master) mutlaka olmalıdır. Ekibin ilerlemesinde ne yapılmalı sorusunun cevabını ürün yöneticisi, nasıl yapılması gerekir sorusunun cevabını da scrum master vermelidir. Ürün yöneticisi pazar ihtiyacını anlamalı, bunun müşteride oluşturacağı değeri öngörebilmelidir. Scrum master ise scrum işleyişindeki sorunları tespit edip çözülmesinde yardımcı olmalıdır.
Ekipler bir proje ile ilgili bir araya geldikten sonra haftalık (başka zaman periyotlarında da olabilir) sprint adı verilen döngülerde kendilerine görev olarak aldıkları işleri tamamlamaya çalışırlar. Bu döngülerin de sorunsuz şekilde ilerleyebilmesi için ekipler her gün 15 dakikadan fazla sürmeyen toplantılar yaparlar. Bu toplantılar ayakta yapılır ve kesinlikle belirtilen süreyi geçmez. Üç tane soru sorulur:
- Ekibin sprinti tamamlamasına yardım etmek için dün ne yaptın?
- Ekibin sprinti tamamlamasına yardım etmek için bugün ne yapacaksın?
- Ekibin önünde hangi engeller var?
Bu toplantının temel amacı ekip üyelerinin ekibin neresinde durduğunu ve her bir bireyin sprint içerisinde bireysel olarak ne katkı sağladığını göstermektir. Toplantı her gün aynı saatte tüm ekibin katılımı ile gerçekleşmelidir. Toplantı bittiğinde o gün herkesin ne yapacağını bilmesi gerekmektedir. Ekibin içerisinde akıllı aptal diye adlandırılan insanlar olmalıdır. Bunlar zaman zaman rahatsız edici sorular sorabilen, ekibin konforunu bozabilen, mantıklı ve herkesin gördüğü ama dile getirmeye korktuğu alanlara vurgu yapabilen insanlardır. Kısacası kral çıplak diyen bu insanlara ihtiyaç vardır.
Ekibin başladığı bir işi bitirmek yerine araya başka işler alması israflara neden olmaktadır. Aşağıdaki tabloya göre eğer birden fazla projeniz varsa ve bu projeler arasında eğer gidip geliyorsanız eforunuzun önemli bir kısmı heba oluyor demektir.
İnsan doğası gereki bizler birden fazla işi aynı anda yapamıyoruz. Yaptığımızı zannediyoruz ama yapamıyoruz. Daha önce bunu İkigai adlı kitap özetimde anlatmıştım (İkigai için tıklayın). Bu nedenle bir işe başlıyorsak onu bitirmeden başka bir işe geçmek doğru olmayacaktır. Ayrıca eğer bir sorun yaşanmışsa bu sorunu hemen çözmek gerekmektedir. Üzerinden zaman geçerse bu sorunu tekrar keşfedip çözmek çok zor olmaktadır. Kitapta yer alan bir örnekte bir bug doğduğu anda ilgilenilirse 1 saatte çözülürken 3 hafta sonra aynı bug 24 saatte çözülmektedir. Bu sebeple ilk seferde doğru yapmak önemlidir.
Ayrıca ekiplerin doğal çalışma koşullarında faaliyetlerine devam etmesi gerektiği vurgulanıyor. Buna göre çalışma saatleri arttıkça insanların verimi düşünüyor ve hatalar yapmaya başlıyorlar.
Ekip bir araya geldiğinde bir sprintte ne kadar iş bitirebileceğini görmek için bir planlama yapar ve sprint sonunda bunun altında mı üstünde mi kaldıklarını kontrol ederek diğer sprintte gerekli ayarlamaları gerçekleştirirler. Her bir sprintte hangi işleri yapacaklarsa onların birbirlerinden anlamlı şekilde ayrılmasını (iş yükü anlamında) sağlayabilmek için her bir göreve Fibonacci sayıları ile ağırlık verirler. Fibonacci; 0,1,1,2,3,5,8,13... diye devam eden ve her bir sayının kendinden önceki iki sayının toplamından oluştuğu bir dizidir. Buradaki amaç bir görev üzerinde tartışma yapılırken, bir ekip üyesi sekiz verirken bir başkası bir veriyorsa bu anlamlı farkın ortadan kalkmasıdır. Herkesin ağırlık konusunda mutabık olmasıdır.
Fibonacci sayıları ile görevlere ağırlık verildikten sonra 1 sprintte tamamlanacak görevlerin toplam ağırlığı ortaya çıkar. Yukarıda da belirtildiği gibi sprint sonunda bunların ne ölçüde tamamlandığı gözlemlenerek sonraki sprintler için yeni fakat daha doğru planlamalar yapılabilir.
Ekipleri oluşturduk, sprintler planladık, görevlerimizin üzerinden geçtik ve bunlara ağırlıklar verdik. Peki nasıl önceliklendirme yapacağız? Genel olarak şunu bilmemiz lazım ki, ürünün değerinin %80'i ürün özelliklerinin %20'sinde yer alır. Hatta bir mobil şube yapıyorsanız belki 100 işleminiz vardır ama bunlardan sadece 20 tanesi mobil şubedeki işlemlerin %95'ini oluşturuyordur. O nedenle her iş öncelikli, her işi hemen olsun yanılgısına düşmeden gerçekten önemli işleri öne almalı ve ona göre sprintleri planlamalısınız.
Kitapta hoşuma giden bir anektod vardı. Bildiğiniz gibi bizler her zaman tamamladığımız işlere göre ödüllendiriliriz. Belki de işin doğası gereği bu böyle olmalıdır. Oysa hedefe ulaşma anı kısa bir an ama hedefe koşma süreci uzun bir süreçtir. Örneğin şirket kar etmişse bu, sene sonunda kısa bir an için kutlanabilir ama bütün sene o kar rakamına ulaşmak için büyük bir gayret sarf edilir. Bu sebeple süreç içerisinde de insanları ödüllendirmeyi, onları motive etmeyi ve mutlu bireyler haline getirmeyi başarmalıyız. Aslında değerli olan sürecin kendisidir. Sonuç ise sadece bir çıktıdır. Eğer ekip üyelerini süreç içerisinde motive ve mutlu bireyler haline getirmeyi başarabilirsek daha iyi çıktılar üretmelerini sağlayabiliriz. Çünkü 2005 yılında yapılan bir araştırmaya göre bireyler mutlu oldukları için daha iyi sonuçlar üretiyorlar, daha iyi sonuçlar ürettikleri için mutlu olmuyorlar. Bu belki bazılarına süpriz gelebilir ama mutluluk başarının öncesinde yer almalı, mutluluk bir x değişkeni ise başarı bir y değişkenidir.
Peki mutlu olmak için ne yapmak lazım denildiğinde ise karşımıza şu üç terim çıkmaktadır:
- Otonomi: Ekiplerin sprintlerde kendi kararlarını verebilmesi ve yetkilendirilmiş olmaları
- Amaç: Kendileri için önemli ve özel gördükleri bir amaçları olması
- Ustalık: Yaptıkları işte uzmanlaşmaları ve böylece bir akışa girip sanki bir hobi yapıyormuş gibi işlerinde tatmin yaşamaları. (Akış konusunu da İkigai adlı kitapta görmüştük.)
Bu kavramlara çok az değindim çünkü bunları bir başka kitapta (Drive; Daniel Pink) sizler için daha önce özetlemiştim. Lütfen detay için tıklayın.
Mutluluk çok önemlidir ama bazı riskler de barındırır. Örneğin bir işi çok iyi yaptığınıza inandığınızda belki kendi öz tatmininizi yaşayabilirsiniz ama öbür taraftan kendinizi geliştirmeye olan isteğiniz azalabilir. Bu nedenle sürekli gelişimi unutmamalı ve hiçbir zaman tam anlamıyla yetkinliklerinizde en üst noktaya eriştiğinizi düşünmemelisiniz.
Evet sevgili arkadaşlar, kitap oldukça kapsamlı şekilde scrum ın nasıl uygulanması gerektiğini anlatıyor. Ben de sizinle paylaşmak istedim. Scrum sadece iş yaşamında değil, belki bir düğün planlarken veya tatil planı yaparken de kullanılabilir. O sebeple büyük veya küçük projelere uydurulabilir. Umarım sizler için keyifli olmuştur. Bir başka kitapta görüşmek üzere.
