Hayatımızın bir çok alanında şeffaf olmanın avantajlarını görebiliyoruz. Hem özel hayatımızda, hem iş hayatımızda çoğu zaman da bizden beklenen zaten şeffaf olmamız. Son zamanlarda özellikle Agile ile birlikte en çok konuşulan konu oldu “Şeffaflık”. Fakat bunu hakkıyla yapabilmek veya dozunu ayarlayabilmek konusunda zorlanabiliyoruz.
Peki nedir bu şeffaflık? Agile’daki şeffaflıktan kastedilen ne? Hatta bu yazının esas sorusu: Ne kadar şeffaf olmalıyız?
Şeffaflık Nedir?
Şeffaflık, işi yapma nedenlerimizi, işi yapma şeklimizi, işin kalitesini ve işin işlevselliğini açıklığa kavuşturmakla ilgilidir.
İş hayatımızdan örneklerle gidelim. Bir yönetici için şeffaflık, işin durumunu bilmek olabilir. Bir ekip üyesine göre ise devam eden işleri takip edebilmek için herkesin ulaşabileceği bir board kullanmak, şeffaflık anlamına gelebilir. Hatta tüm organizasyonu ilgilendiren kararların üst yönetim tarafından çalışanlara açık bir şekilde anlatılması da bir başka şeffaf olmanın göstergesi kabul edilebilir.
Agile’da Şeffaflık
Agile değerlere baktığımızda (Agile Manifesto) şeffaflık üzerine kurulu olduğunu görebiliriz. Bireyler ve etkileşimlerin daha değerli olduğunu, müşteri iş birliklerinin önem kazandığını söyleyebiliriz.
Agile şemsiyesi altındaki en popüler çerçeve olan Scrum da şeffaflık ilkesine oldukça değer verir. Hatta deneysellik için gerekli olan 3 sac ayaklarından biri olarak görür (Diğerleri adaptasyon ve gözlem). Ayrıca Scrum etkinlikleri de ekiplerin şeffaflık yaratmasına yardımcı olan en iyi pratiklerdendir.
Başka bir popüler çerçeve olan Extreme Programming (XP), iletişim ve geri bildirime önem verir. Bilgilendirici bir çalışma alanı yaratma yoluyla şeffaflık oluşturur.
Takımların Şeffaflığı
Takımlar yaptıkları çalışmaları görünür kılmak için şeffaflık için gereken iyi pratikleri uygularlar. En çok karşımıza çıkan pratik ise metrik tutmaktır. Takımlar düzenli olarak metriklerini güncel tutar. Böylece mevcut durumlarını herkes için görünür kılarlar. Ayrıca metriklerin bir diğer güçlü yönü ise takıma hızlıca karar aldırmayı sağlamasıdır. Çevik takımlar için birkaç metrik sıralayacak olursak;
- Velocity
- Lead Time
- Çalışma günleri – Kapasite
- Burn-down & Burn-up Charts
- CFD – Cumulative Flow Diagram
Ancak şeffaflık metrik tutmanın biraz daha ötesindedir. Yani sadece metrikler çevik takımlarda şeffaflık için yeterli değildir. Şeffaflık ayrıca, ekip üyelerinin yaptığı konuşmaları, aldıkları kararları da içermelidir.
Soyut & Somut Veriler: Metrikler takımlar için sayısal değerler içeren şeffaflık sağlayıcılardır. Takım üyelerinin birbirleri ile konuşmalarını veya retro kararlarını içeren şeffaflık ise sayısal değerler içermez. Dolayısı ile şeffaflık verilerini soyut ve somut diye 2 başlık altında düşünebiliriz.
Takım İçi & Takım Dışı Paylaşım: Neyin şeffaf hale getirildiğine ek olarak, ekibin işleri ve verileri kime görünür kılacağını düşünmek de bu işin bir parçasıdır.
Peki Ne Kadar Şeffaflık?
Takımların şeffaflığını anlatırken soyut & somut veriler ve takım içi & takım dışı şeffaflık diye kategorize ettim. Bu kategorizasyon bize ne kadar şeffaf olmamız gerektiğine karar vermemizde yardımcı olacak.
Öncelikle somut (nicel) verilerle başlayalım:
Takım metriklerinin sayısal değerler olduğunu ve somut veriler kategorisinde değerlendirildiğini söylemiştim. Takımlar öncelikle kendileri için metrik tutmalıdır. Takım kendisini iyileştirmek için bu verileri kullanır. Bu yüzden tüm somut veriler takım içindeki herkesle paylaşılmalı ve ulaşılabilir olmalıdır.
Somut verileri takım dışına açma konusunu düşünelim şimdi de. Normal şartlarda takımlardan somut verileri takım dışına da paylaşması beklenir. Ama bazı istisna durumları da vardır. Takım kendi içinde paylaştığı tüm somut verileri dışarı çıkarmak istemeyebilir. Bu çok normal ve haklı bir durumdur. Eğer ki takım bazı verilerin yanlış yorumlanacağından endişeleniyorsa, kötüye kullanım riski varsa, verinin takım dışına paylaşımını kapatabilir. Takım dışına karşı gizlenmek istenen verilerden biri de ekip üyelerinin bireysel metrikleri olabilir. Bir kişi üzerindeki hata / madde sayısı, çalışma saatleri vb olabilir.
Bireysel metrik tutmaya çok sıcak bakmıyorum açıkçası. Takım olma dinamiklerini riske atabileceğini düşünüyorum. Ama olgunluğu yüksek takımlarda çok da risk olur mu? Olmayabilir. Çünkü bireysel metrik tutan ve bunlardan yarar sağlayan takımları da gördüm.
Yine de ben oyumu takım üyeleri üzerinde kişi bazlı metrik tutmamaya kullanıyorum.
Scrum koşan takımlar review etkinliklerini takım dışına açar ve ürettikleri Increment’i paydaşlarıyla değerlendirirler. Takım, neleri bitirdiklerini gösterir, neleri bitiremediklerini de cesaretle açıklar. Review etkinlikleri takım ve paydaşlar arasında mükemmel bir şeffaflık sağlar.
Takımların dışarıya karşı uyguladıkları şeffaflık pratiklerinden biri de bülten yayınlamalarıdır. Burada geçirdikleri dönemde neler yaptıklarını görselleştirir, metriklerle somut verilerini paylaşırlar.
Gelelim soyut (nitel) verilere:
Takım içi paylaşılan soyut veriler için akla ilk gelenler takımın retrospective etkinliklerindeki konuşmaları, burada aldıkları kararlardır. Bu tarz konuşmalar ve kararlar takımca yapılır ve hep takım kararıdır. Bu yüzden de takımın tüm bireyleri için paylaşılır ve ulaşılabilir olmalıdır. Fakat bazı durumlarda dikkatli olmak gerekir. Mesela ekip üyelerinden iki kişi arasında özel bir konuşma olabilir. Bu konuşmanın içeriğini diğer ekip üyelerinin bilmesini istemeyebilirler. Ekip üyeleri de onları söylemeleri için zorlamamalıdır.
İki ekip üyesinin özel görüşmesini yaptıkları iş veya başka bir ekip üyesi hakkındaki bir konuşması olarak düşünebiliriz. Fakat bunu yine takım olgusunu riske atabilecek bir davranış olarak görüyorum.
İki kişi, diğer ekip üyelerinin performansı hakkında tabii ki konuşabilir. Eğer performansından memnun olmadıkları bir durum varsa bunu takım içi dayanışma ile çözebilmeliler bence. Yani burada da bir takım içi şeffaflık ve kişileri kazanma bakış açısı beklerim.
İş ile alakalı görüşmeler de yine aynı şekilde sadece senior kişilerce değil tüm ekip halinde konuşulması gereken konular olarak düşünüyorum.
Yine de açık kapım var. Tüm takımca paylaşılması gerekmeyen, iki kişi arasında olan durumlar olabilir tabii ki.
Takım dışına soyut verilerin paylaşımı konusu ise dikkat edilmesi gereken bir durumdur. Nitel verilerin takım içinde bile yüzde yüz şeffaflığı söz konusu değilken, takım dışında düşünmeden hareket etmek doğru olmaz. Özellikle takımların retro etkinliklerinin dışarı açılması doğru karşılanmaz. Retrospective etkinlikleri takımın özelidir ve sonrasında da öyle kalmalıdır.
Retrospective etkinliklerine takım dışından birilerinin gelmesi, etkinliğin sağlıklı geçmesine engel olacaktır. Özellikle bazı yöneticilerin katılma talepleri olabiliyor. Takımların “Hayır” diyemediği durumlarda retro etkinlikleri yöneticiye rapor verme toplantısına dönüşebiliyor. Tek risk bu da değil, takımın birbirine karşı açık iletişimine de engel bir durum. Takım, yöneticisinden veya retroya katılan takım dışı bireyden çekindiği için olumsuz konuları konuşmayacaktır. Böylece şeffaflık da bozulacaktır.
Şeffaflık vs Açıklık
Birbirine yakın iki kelime olsalar da anlatmak istedikleri biraz farklı. Ama birbirlerini destekledikleri kesin. Peki fark ne?
Şeffaflık bireylerin veya takımların yaptıkları iş, süreç ve durumların herkesçe görünür olmasıdır. Açıklık ise bireylerin birbirlerine karşı söylem ve davranışları ile alakalıdır.
Şeffaflık Scrum’ın deneysellik için gereken 3 temel bacağından (Scrum Pillars) biri olarak kabul edilir. Açıklık ise takım üyelerinin Scrum Değerleri içinde bahsedilmiştir.
İlkim Dilara KADAKALOĞLU
d.
İlk Yorumu Siz Yapın