Agile Proje Yönetimi
Scrum’ı kullanmak sadece projelerinizi daha etkin yönetmenize yardım etmekle kalmaz aynı zamanda projelere nasıl yaklaşacağınıza dair bakış açınızı da değiştirir.
Bu kısa makalede Scrum Çerçevesinin özellikle projelerinizi daha etkin yönetmenize nasıl yardımcı olacağına dair bazı ipuçları ve sırları sizlerle paylaşmaya çalışacağım.
Öncelikle, Scrum karmaşık problemleri yönetmeyi kolaylaştıran bir çerçevedir ve büyük ölçüde Product (Ürün) bağlamında kullanılır. Product Owner (Ürün Sahibi) olarak adlandırılan bir rol vardır ve ürünle ilgili yaptıklarınız Product Backlog ‘da (Ürün İş Listesi) olarak tutulur, vb. Peki, Scrum proje bağlamında kullanılabilir mi ve nasıl kullanılabilir ? Burada bir ürün yaklaşımı yerine bir proje yaklaşımı önermiyorum ya da ikisi arasındaki farkları tartışmayacağım. Bu makale, insanların kendilerini alışık oldukları dünyada Scrum kullanmaları yönünde kademeli adımlar atmasına yardım etmeyi amaçlamaktadır.
Belki doğru belki de yanlış bir yaklaşım ama bazı organizasyonların iş modellerini “proje” merkezlidir, yani bir değer üretmek için projeler yaparlar. Kararlaştırılan ön kapsamı müşteriye, tanımlamış bir bütçe ve/veya zaman dilimi dahilinde teslim ettiklerinde ödemelerini alırlar. Benzer şekilde, bir çok organizasyon tüm kurum içi inisiyatiflerini projeler olarak hayata geçirirler. Bu organizasyonlar projelerini çok çeşitli proje yönetim şekilleri kullanarak yönetirler.
Uzun bir süreden beri Agile Danışmanıyım ve ne zaman bir kuruluş için proje yaklaşımını ürün yaklaşımıyla değiştirmesi için bir fırsat görsem, her zaman bakış açımı kendileriyle paylaşırım ancak ürün zihniyetine geçmek her zaman kolay değildir ve diğer değişikliklerle beraber organizasyonel değişim de gerektirebilir (örneğin sözleşme yönetimi bu değişime iyi bir adaydır). Bugüne kadar danışmanlık yaptığım kuruluşlar Scrum’ın projelerini daha etkin yönetmelerine yardımcı olabilen bir çerçeve (ve aslında bir yöntem) olduğunu düşünmektedir. Kendilerine Scrum’ın bundan çok daha fazlası olduğunu açıklasam da, Scrum’ın proje bağlamında Çevikliğinizi arttırmaya yardımcı olacağı da elbette bir gerçektir. Peki, nasıl mı?
Ürün İş Listesi Yönetimi
Projeler sabit bir kapsama sahip olma eğilimindedir. Sabit kapsam sonradan değiştirilmesi zor ve belirsizlikleri reddeden bir yaklaşım demektir. Peki projenin kapsamını hiç konuşmadan mı başlayacağız ? Elbette hayır. Başlangıçta projenin ihtiyaçlarını daha genel ve üst seviyede konuşup bir takım hedefler belirlemek elbette mümkün. Hedef bazlı anlaşmada detayların daha sonra müzakere edilebilmesi anlamına gelir. Kısaca projede özellik/gereksinimlere odaklanmak yerine kullanıcı/paydaş ihtiyaçlarına odaklanmak ve hedef temelli bir yol haritası belirlemek kapsamı esnetmek için iyi bir başlangıç olabilir. Kapsamın projenin uygulanması sırasında müzakere edilebilmesine güzel bir örnek: bazı kuruluşlar, “yenisiyle değiştirilecek” özellikler üzerinde çalışılmasına henüz başlanmadığı sürece, gereksinimleri aynı boyutta gereksinimlerle değiştirmelerine olanak veren sözleşmeler düzenlerler.
Sorumluluklar
Scrum, 3 farklı sorumluluk tanımlamaktadır.
- Product Owner: Kısaca söylemek gerekirse, “Neden” ve “Neyi” yaptığımızdan sorumlu olan Ürün Sahibi (Product Owner – PO). Bunu, şeffaf canlı bir Ürün İş Listesi (Product Backlog – PBL) tutarak yapar. PBL, proje kapsamı belgesinin yerine geçer. Bu blog’da bir PBL’nin nasıl etkin bir şekilde tutulacağının/yönetileceğinin detayına inmeyeceğim). PO ayrıca, müşteri ihtiyaçlarını belirlemek ve doğrulamak için öncelikle paydaş yönetimine odaklanır. PO pazarı, rekabeti bilen ve takip eden, ürünün vizyon ve stratejisinden de sorumlu kişidir.
- Scrum Master: Scrum Takımının (bu durumda proje ekibinizin) etkinliğinden sorumlu olan Scrum Master. Peki, bunu nasıl yapar? Engelleri kaldırarak, kararları kolaylaştırarak/hızlandırarak, şeffaflık yaratarak, ekibin Agile ilkelerini, değerlerini benimsemesine yardım ederek, vb.
- Developers: Ürün üzerinde çalışan profesyoneller. Developers ‘Bitti Tanımı’ (Definition of Done) gibi, Scrum’da belirli standartlara uyarak ürün parçalarını kademeli (incremental) olarak tamamlarlar.
Bu sorumluklar proje organizasyonlarında benimsenebilir mi? Kısa cevap, evet. Bu üç sorumluluk başarılı bir proje için yeterli olacaktır. Projelerde başka rollere gerçekten ihtiyacınız var mı?
Scrum’da Geri Bildirim Döngüleri/Etkinlikler
Scrum’da, Sprint denilen maksimum 1 ay süreli bir zaman kısıtı içerisinde yer alan, tanımlı ve yapılması zorunlu geri bildirim döngüleri/etkinlikleri vardır. Bunlar: Sprint Planning, Daily Scrum, Sprint Review ve Sprint Retrospective’dir. Tüm Scrum etkinlikleri projelerde kolaylıkla kullanılabilir ve diğer proje toplantılarının hemen hemen tamamını elimine edebilir. Sprintler ilerlemenin/projenin durumuyla ilgili şeffaflığı arttıracak ve tüm yeni uyarlamaları mümkün kılacaktır. “Sprint Planning” (Sprint planlama), daha kısa dolayısıyla daha gerçekçi planlama döngülerine olanak sağlarken, “Sprint Review” (Sprint değerlendirme) paydaşlara şeffaflık sağlayacak ve paydaşların ilerlemeyle ilgili daha erken geri bildirim vermelerine olanak sağlayacaktır. “Daily Scrum” “Developers”ın günlük faaliyetlerini Sprint hedefine yönelik şekilde senkronize etmelerini ve planlamalarını sağlarken, “Sprint Retrospective”, tüm Scrum takımının daha düzenli, sıklıkta alınan dersleri gözden geçirmesini sağlarken, böylece ekibin gelecek projelerden ziyade devam eden proje için süreçlerini, araçlarını adapte edebilmelerine olanak sağlayacaktır.
Deneycilik
Scrum, düzenli sıklıkta denetim ve uyarlamayı temel alan deneysel süreç kontrol modeli üzerine kurulmuştur. Projelerde nelerin denetlenmesine ve uyarlanmasına gerek vardır? Merak ediyor olabileceğiniz birkaç soru:
- Planımız gerçekten yolunda ilerliyor mu (kapsam, zaman, bütçe). Bu şekilde ilerlemiyorsa, ne yapılabilir? Bunun yerine deneysel/uyarlanabilir (adaptive) bir planlama yapabilir miyiz? Müşterilerimiz bundan nasıl faydalanabilir? Ne kaybederiz?
- Müşterilerimiz/kullanıcılar hala bu özelliklere ihtiyaç duyuyor mu? Bunlara ihtiyaçları olup olmadığından nasıl emin olabilirim?
- Yeni müşterin ihtiyaçlarının ve taleplerinin karşılanmasını, değişim yönetimi üzerinde çok fazla zaman harcamadan bir kazan-kazan yaklaşımıyla nasıl mümkün kılabilirim?
- Üzerinde çok uğraşmadan etkin olmayan süreçleri hızla nasıl değiştirebilirim?
Deneycilik bir davranışsal değişim/düşünce yapısı değişikliği de gerektirir ve Scrum’da bu temelde Scrum Değerlerinin (açıklık, cesaret, saygı, bağlılık, odak) benimsenmesiyle desteklenir. Bu değerler, deneysel düşünce yapısı/deneysel yaklaşım için sahip olunması gereken temel bileşen olan güven duygusunu yaratır. Peki, bu, proje ekipleri tarafından benimsenebilir mi? Kesinlikle evet; gerçekleştirilmesi daha zor olabilir ama gösterilen çabaya değecektir.
Özet
Bu kısa makalede Scrum’ın projelerde nasıl kullanılabileceğini açıklamaya çalıştım. Scrum’ı kullanmak sadece projelerinizi daha etkin yönetmenize yardım etmekle kalmaz aynı zamanda projelere nasıl yaklaşacağınıza dair bakış açınızı da değiştirir. Scrum’ı etkin kullanarak, geleneksel proje yönetimi yöntemlerine kıyasla sarf ettiğiniz gereksiz enerjinin ve unsurların çoğunu ortadan kaldırmış olacaksınız.
Umarım bu yazı, projelerle ilgilenenlere ilham verir. Belki bu aynı zamanda, ana odak noktasının kapsam/zaman/bütçe yerine müşteri/kullanıcı olduğu bir ürün zihniyetine geçişe yönelik iyi bir adım da olabilir ?
Son olarak, Scrum’ı projelerde kullanmaya başlamak, onun uygulama kapsamını genişletmeden önce Scrum’ı tecrübe etmek isteyen kuruluşlar için iyi bir başlangıç olabilir.
Yorumlar