22 Ağustos 2016 Pazartesi

Çevik Yöntemlerde İdeal Takım: T-Biçimli Takım

Çevik yöntemlerde rollerin farklı olduğunu ve bu rollere uygun profillerin de farklı olduğunu daha önce belirtmiştik (İlgili Makaleler: Çevik Yöntemlerde RollerÇevik Yöntemlerdeki Rollere Uygun Profiller ). Geliştirme takımı üyesinin temel seviyede çevik yöntemleri bilmesi gerektiğini, uyumlu, kendi kendine organize olabilen, sorumluluk sahibi, takım oyuncusu, pro-aktif ve yeterli uzmanlığı taşıdığını belirtmiştik. Bu özelliklerde olan bir ekibin iyi bir takım olması için başka nelere dikkat etmek lazım? İdeal bir geliştirme takımı nasıl olmalı? İdeal takımı oluşturabilmek için mükemmel kişilere mi ihtiyaç var? En iyi teknik uzmanları bir araya getirirsek ideal bir takım kurmuş olur muyuz? Bu takım üretken olur mu? Bu yazıda bu soruların yanıtı arayacağız.

Şekil-1
Çevik dünyada herkesin sadece tek bir konuda uzman olması ve sadece kendi işini yapması beklenmiyor. Bilakis takım olarak ilerleme ve birlikte iş yapabilme ön planda. Bu da takım üyelerinin kendi uzmanlık alanları dışında diğer konularda da bilgi birikimlerini artırmaları ve katkı yapabilmeleri ihtiyacını doğuruyor. Böylece bu yazının da başlığında yer alan “T-biçimli” kavramı ortaya çıkıyor. Bu kavram son dönemde yurt dışında özellikle çevik yaklaşımları kullananlar arasında daha çok popüler olmakta. T-biçimli kişi kısaca bir konuda derinlemesine uzmanlığı varken başka konularda da bilgisi/yetkinliği olan kişi olarak karşımıza çıkıyor. Şekil-1’de en basit haliyle, yazılım geliştirme alanında derin bilgi birikimi olan bir kişinin analiz ve test süreçleri hakkında da temel seviyede bilgi sahibi olması gösteriliyor.
Şekil-2
Şekil-3

Herkesin her alanda uzmanlık seviyesi değişkenlik gösterebilir, örneğin yazılım geliştirmede uzman kişi test konusuna daha aşina olabilir, Şekil-2’de gösterildiği gibi. Şekil-3’de ise yazılım geliştirme alanında uzman bir kişinin yine kendi uzmanlık alanındaki alt alanlardaki durumunu gösteriliyor. Buna göre Java tecrübesi olan bir kişinin diğer konularda da belli bir bilgi seviyesinde olduğu anlaşılıyor. T-biçimi içinde iş alanı bilgisinin de eklenmiş olması çok önemli, bu boyuta ilişkin örnek Şekil-4’te yer alıyor. Teknik ve iş bilgisi boyutlarının birleşmesi geniş bir yetkinlik yelpazesi ortaya çıkarıyor. Buna ait örnek,  bir yazılım uzmanı özelinde Şekil-5’teki gibi gösterilebilir.

Şekil-4
Şekil-5
Kişilerin yetkinliklerini bir araya getirince, takımların uzmanlık alanları ortaya çıkar. Takımlar da tıpkı bireyler gibi belli konularda daha derinlemesine bilgi sahibi iken, bazı konularda daha yüzeysel bilgi sahibi olabilirler. Bu haliyle, takımın yetkinlikleri de T harfine benzediği için T-biçimli Takım (T-Takım) kavramı ortaya çıkıyor. T-Takım’da herkes aynı uzmanlık alanlarından olmaz, birbirini tamamlayan ve destekleyen alanlardan kişilerin bir araya gelmesi önemlidir. Örneğin sadece yazılım geliştirme uzmanlarından T-Takım kurulmaz. Muhasebe konusunda bir ürün üzerinde çalışacak ekibin yetkinlik gösterimi Şekil-6’da yer alıyor.  
Şekil-6: T-Takım
Peki T-Takımın faydaları nedir?
  • En başta kişi bağımlılığını azaltır. Takımda bir kişinin yokluğunda işler durmaz. Bir çok projede başarısızlık nedenlerinden birisi kişiye bağımlı olunmasıdır. Bu kişinin herhangi bir nedenle işini beklendiği gibi yapamaması projeyi de haliyle sekteye uğratır. T-Takımlarda bu gibi durumlar daha zor yaşanır.
  • Takım üyelerinin birbirlerini daha iyi anlamalarını ve daha etkin işbirliği yapmalarını sağlar. Eğer sadece kendi uzmanlık alanınızda bilginiz varsa ve diğer konularla ilgilenmiyorsanız, takım arkadaşlarınızın yaptığı işleri iyi anlamadığınız için hem onları küçümseyecek hem de yeterince işbirliği yapmayacaksınız. Eğer yüzeysel de olsa bilginiz varsa empati yapma ve anlama imkanınız olacak. Bu sayede daha etkili iş birliği fırsatınız olacaktır.
  • T-Takım müşteriden aldığı bir talebi uçtan uca geliştirip yine müşteriye sunulabilir. Hem müşteriyi anlar, hem de gelen talebi bunu gerekli yazılım geliştirme adımlarını tamamlayıp test edilmiş bir ürün olarak yine müşteriye sunar. Başka kişi ve takımlara bağımlılığı ya yoktur ya da çok azdır.
İdeal bir T-Takım kendi içindeki gelişime de önem verir. Takım üyelerinde bireysel olarak T-biçimli olmaları için diğer takım üyelerinin aktif desteği sağlanır. Takımın toplamdaki etkisini artırmak ve daha iyiye ulaşma çabasını hep barındırır. Yeni kurulan bir takımın bu noktaya ulaşması zaman alır. Bu nedenle T-Takımlar oluşturulduktan sonra, bunların gerçek performansları ortaya çıkana kadar desteklemek gerekir. T-Takım ortalama olarak 6 ay – 1 yıl arasında üretken hale gelir. Bu üretkenliği korumak için takımı da bozmamak ve değiştirmemek önemlidir. Uzun süreli örneğin 3-4 yıl birlikte çalışan T-Takımlar çok daha etkin hale gelmektedir.

T-Takım, çevik çalışan büyük ve kurumsal yerlerde (İlgili Makale: Büyük Ekipler Çevik Yöntemleri Uygulayabilir mi?) de kullanılabilir. Proje ne kadar büyük olursa olsun, çekirdeğini takımlar oluşturur. Bu takımların T-Takım olması, hem takımların birbirlerine bağımlılığını azaltır, hem de farklı lokasyonlarda çalışabilme imkanını verir.

Günümüzde başarının anlamı (İlgili Makale: Başarıya Farklı Bir Bakış) yeniden keşfediliyor. Bu çerçevede birlikte başarma ve takım olma konularının önemi giderek daha iyi anlaşılıyor. Takımlar kurulurken farklı kabiliyetleri olan ve birbirini tamamlayan yetkinliklere sahip kişileri bir araya getirme ve T-Takım oluşturmanın önümüzdeki günlerde daha çok konuşulacağını düşünüyorum.


3 Ağustos 2016 Çarşamba

Çevik Yöntemlerde Proje Yönetim Ofisi’ne (PYO-PMO) İhtiyaç Var mı?

Proje Yönetim Ofisi’nin (PYO, Project Management Office-PMO) projeler arası eş-güdüm sağlayan, projeleri izleyen ve raporlayan bir organizasyon parçası olduğunu daha önce aktarmıştık (İlgili Makale: Proje Yönetim Ofisi (PYO - PMO) Ne İşe Yarar? ). Öte yandan çevik yöntemler, hem kurumsal ölçekte hem de proje ölçeğinde çalışma şeklini temelinden değiştirmekte; gerek sunduğu roller, gerek değerleri, gerekse öncelikleriyle iş yapış tarzını tamamıyla farklı bir yöne doğru çevirmekte (İlgili Makaleler: Çevik Yöntemlere YolculukÇevik Yöntemlere Geçerken Direnç NoktalarıÇevik Yöntemlerde Sık Yapılan Hatalar). Çevik yöntemlere geçişle birlikte proje yöneticilerine ne olacağı, onlara ihtiyaç kalıp kalmadığı başlı başına bir tartışma konusu. Biz bu yazıda farklı bir noktaya odaklanacağız: Çevik Yöntemlerde PYO. Çevik yöntemlerin hemen hepsi kendini organize edebilen takımlardan ve bu takımların müşteriye doğrudan sunabildiği ürünlerden bahsediyor. Planlama bu takımlara bırakılıyor. Yine ilerlemenin izlenmesi de takımın kendi başına yapabildiği bir aktiviteye dönüşüyor. PYO’ya yapacak iş kalmıyor gibi görünüyor. Bu durumda çevik dönüşüm yapılan kurumlarda, bin bir zahmetle kurulmuş PYO’nun kapısına kilit mi vurmalı? 

Çevik yöntemleri kullanırken de PYO’nun katkıları olabilir. Çevik projelerle çalışılan ortamlarda PYO’nun da çevik çalışmayı destekleyici bir yapıya bürünmesi, kurumsal çevikliği artırıcı alanlara odaklanması gerekir. Ancak bu şekilde çalıştığı zaman “Çevik PYO” demek doğru olur. Çevik PYO, temel olarak alttaki alanlarda katkı sağlayabilir:
  • Ürün Yönetimi: Çevik PYO, portföydeki tüm ürünlerin durumları ve ürünler arası bağımlılıkların koordinasyonu konusuna odaklanabilir. Bu sayede Ürün Sahipleri (Product Owner), Ürün Talep Listelerini (Product Backlog) düzenleme, maddelerin önceliklerini büyük resmi görerek daha iyi belirleme şansına sahip olacaklardır. Özellikle Ürün Yol Haritaları (Product Roadmap) arasındaki eş güdümde de önemli rol oynayacaktır.
  • Proje Başlatma: Proje taleplerine doğru Ürün Sahibi’nin belirlenmesi, projelerin çalışmaya değer olup olmadıklarının tespiti gibi konularda kurumsal ölçekte katkı sağlayacaktır.
  • İnsan Kaynakları: Çevik takımların kendini yönetebildiğini biliyoruz. Çevik PYO’nun takım içi işlere karışmasını beklemiyoruz. Ancak takımı kurarken doğru takım üyelerinin belirlenmesi ve bir araya getirilmesinde Çevik PYO’nun katkısı olacaktır.
  • Metrikler: Projeler içinde takımların kullandığı İlerleme Grafiği (Burndown Chart), Hız (Velocity) vb. metriklerin (İlgili Makale: Çevik Yöntemlerde Performans Ölçümü) konsolide edilmesi ve üst yönetim  için kurumsal ölçekteki durumun gösterilmesi de Çevik PYO’nun görev alanına girecektir. Burada önemli nokta Çevik PYO’nun yeni bir dolu metrik üretip takımların bu bilgileri sağlaması yönünde bir yaklaşımda bulunmamasıdır, çünkü takımlara ek iş yükü çıkarılmaması bekleniyor.
  • Uyum: Takımların takım dışı kurumsal ortamlarla uyumu, takımlar arası uyum, üst yönetim ve takımların iletişimi ve uyumu Çevik PYO’nun çalışma alanına girmektedir.
  • Eğitim ve Koçluk: İç ve dış eğitmenlerle iş birliği içinde takımların ihtiyaç duyduğu eğitimlerin planlanmasında Çevik PYO görev alacaktır. Ayrıca yeni başlayan çevik takımlara Çevik PYO içinden veya dışından bulacağı deneyimli kişilerle koçluk hizmeti de verebilmesi gerekir. İdealde çevik danışmanların ve koçların Çevik PYO çatısı altında toplanmasıdır. Kurumda yeterince bu tecrübede koç yoksa dışarıdan da alınabilir.
  • Çevik Metodoloji Seçimi: Çevik dünyada birçok farklı yaklaşım/yöntem/metodoloji bulunmaktadır. Kurumlar genelde dönüşüm yolculuklarında temel bir yöntemin örneğin Scrum veya Kanban’ın adaptasyonu ile sürece başlamaktadır. Tüm ürünler, projeler, müşteriler ve takımlar aynı olmadığı için bazen birden fazla yöntemin de kullanılması gerekebilir. Hem yöntem seçilmesinde hem de farklı ekiplerin farklı yöntemleri kullanmasında Çevik PYO’nun  desteği olacaktır. 
  • Sürekli Gelişim: Çevik yaklaşımın en temel özelliği olan sürekli gelişim ve daha iyiyi aramada, hem takımlar özelinde hem de kurumsal ölçekte Çevik PYO kılavuzluk yapabilir. Dünyadaki yeniliklerin takımlara akmasına yardımcı olabilir. Kurumsal ölçekteki gelişim aktivitelerini koordine edebilir.
Bütün bu faaliyetleri yaparken Çevik PYO’nun en belirgin özelliği diğer çevik rollerde olduğu gibi dinleyen, katkı sağlayan ve işleri kolaylaştıran tarafta olmasıdır (İlgili Makale: Çevik Yöntemlerdeki Rollere Uygun Profiller). Direktif veren, yöneten ve tepeden bakan bir yaklaşım çevik prensiplere uygun olmayacaktır. 

Her çevik kurum için Çevik PYO gerekli mi? Olmayabilir. En temel yalın öğreti “israfı önle” gözlüğünden baktığımızda kurumun büyük olmadığı durumlarda; takımların uzun yıllardır çevik yaklaşımla birlikte çalıştığı ortamlarda; sürekli gelişimi herkesin içine sindirip uygulayabildiği yerlerde; eğitim, koçluk ve uyum konularının işlediği yapılarda Çevik PYO gerekli olmayabilir. Çevik PYO’nun gerekliliğini artıları ve eksileri ile her kurum özelinde ayrı ayrı inceleyip karar vermek en doğrusu olacaktır. 

1 Temmuz 2016 Cuma

Çevik Yöntemlere Geçerken Direnç Noktaları

Kurumunuzda Çevik Yöntemlere geçişe karar verildi veya verilmek üzere, dönüşüm süreci (İlgili makaleler: Çevik Yöntemlere DönüşümÇevik Yöntemlere YolculukÇevik Yöntemlerde Performans Ölçümübaşlamak üzere ise bazı zorluklar sizi bekliyor demektir. Herkesin çevik yöntemlere geçiş için can attığını düşünüyorsanız, yanılıyorsunuz. Dönüşüm sürecinde insanların desteğini alabilmek için ikna etmeniz gerekiyor. Hatta ikna etmeniz gereken çok kişi olduğunu göreceksiniz. Bu ikna sürecinde farklı konumlarda çalışan farklı kişilerin birbirinden farklı direnç noktaları olacak.  Kaygı, korku, itiraz, ön yargı vb. hepsini direnç noktası olarak niteledim. Kimi zaman bu direnç noktaları açıkça size söylenecek, kimi zamansa içte tutulup gizlenecek. Bu direnç noktalarını önceden bilmek buna göre hazırlanmak direnç noktalarını aşmanızı sağlayabilir. Bu amaçla en sık olanları altta özetlemeye çalıştım.


Öncelikle takımdan başlayalım:
  • Çok fazla toplantı var! Özellikle ayaküstü (stand-up) toplantılarının her gün yapılacak olması, henüz bu toplantıları deneyimlememiş kişilerde çevik yöntemlerde çok toplantı yapıldığı düşüncesini çağrıştırabiliyor. Burada en iyi argüman, sürenin 15 dakika ile sınırlı olduğunu ve bu kısa toplantının, saatler süren eski usul başka toplantılardan kurtulmak için faydalarını anlatmak.
  • Eğer baştan tasarımı yapmazsak, mimarimiz başarısız olur! Çevik yöntemlerde ürünün baştan nasıl olacağının düşünülmediği, tasarımın yapılmadığı yönünde yanlış bir algı var. Bunun tam tersine Ürün Vizyonu (Product Vision) en baştan ortaya konuyor, bunu destekleyici nitelikte Ürün Yol Haritası (Product Raodmap) da hazırlanıyor. Vizyon ve Yol Haritasını ortaya koyabilmek için elbette genel hatlarıyla teknik tasarım da ortaya konuyor. Bunun anlamı tüm tasarımı en ince detayı ile baştan yapmak değil elbette. Tasarımın detayları Döngüler (Iteration, Sprint) içinde oluşturuluyor. Teknik mükemmeliyet ve güçlü tasarım bilakis çevik dünyada çok önemsenen prensipler (İlgili makale: Çevik Yöntemler ve Teknik Mükemmellik).
  • Aynı yerde çalışmıyoruz, dolayısıyla çevik olamayız! Aynı yerde çalışma (co-location) takım içi iletişimi kuvvetlendirmek için önerilen bir yaklaşım. Eğer coğrafi olarak farklı yerlerde çalışanlardan kurulu takımlar varsa,  çevik yöntemler yine uygulanabilir. Belli periyotlarla takımı bir araya getirecek yüz-yüze toplantılar kurgulanabilir. Özellikle Döngü Sonu Gözden Geçirme (Iteration Review, Sprint Review and Demo) toplantıları, Döngü Planlama Toplantıları ve Retrospektifler (İlgili makale: Çevik Yöntemlerde Retrospektif) bu amaca çok uygundur. Kalan zamanda teknolojinin nimetlerinden faydalanıp telekonferans, videokonferans, mesajlaşma (Google Talk, Skype, WhatsUp vb.) kullanılarak iletişim güçlendirilebilir.

Yönetime bakalım:
  • Çevik yaklaşımda uzun dönemli planlama yapılamıyor, bütçelerimizi böyle yönetemeyiz! Bu çok temel bir yanılgı, çevik yöntemlerde kapsam, bütçe ve zaman yönetimi çok daha güçlü. Bütçe ve zaman en baştan belirlendiği için yönetebilmek de kolay. Ayrıca her gelen yeni müşteri talebi ayrı ayrı maliyetlendirilip bütün planlar revize edilmediği için bütçenin sık sık değişmesi riski de söz konusu değil.
  • Mevcut modelimiz bugüne kadar çalıştı, değiştirmeye ve çevik olmaya ihtiyaç yok! Eğer gerçekten müşterilerin, çalışanların memnun olduğu ve şirketin istenen genel performansı gösterdiği bir ortam varsa belki de değişim gerekli olmayabilir. Ancak bu direnç noktasının arkasında genelde şu gerçek yatar: Direktif verici - kontrol edici yönetim tarzına (command and control) alışkın ve gücü elinde tutan yöneticiler, bu güce veda etmek istemezler (İlgili makale: Çevik Yöntemlerde Sık Yapılan Hatalar). Onlar için çevik yöntemlerde takımların kendi başlarına organize olabilmeleri bir tabudur. Bu direnci aşabilmek için çevik takımların sağlayacağı verimlilik ve etkinlik artışı ön plana çıkartılıp, yöneticinin üzerindeki yükün azalacağı, taktik seviyedeki sorunlarla ilgilenmesine gerek kalmayacağı ve kendisinin stratejik diğer konulara odaklanabileceği anlatılabilir.
  • Bizim durumumuz çevik için uygun değil, çünkü çok karmaşık! Bu bazen “çok farklı”, “çok özel” olarak da gelebilir. Bu direnç noktası için en iyi yaklaşım benzer firmalara ait vakaların anlatılması ve çevik dönüşüm sonrası yakalanan ivmenin vurgulanmasıdır. Özellikle rakiplerin yaptığı başarılı dönüşümler, yönetim kadrosunu etkileyecektir.

Peki Müşteriler:
  • Bütün kapsam yapılmazsa, ihtiyaçlarımız karşılanmamış olur! Çağlayan modeli ile kapsama sıkı sıkıya bağlı çalışan kurumlarda en ufak bir iş isterinin bile yapılmaması sanki tüm iş eksik kalmış algısı yaratacaktır. Bu da çevik yöntemlere geçişte bir direnç yaratabilir. Burada en iyi ikna, aynı müşterilerin daha önceki uygulamalarda sunulan tüm kabiliyetlerin ne kadarını kullandıklarının gösterilmesi ile olacaktır.  Tüm sektörde sunulan kabiliyetlerin yaklaşık %64’ünün çok az kullanıldığı veya hiç kullanılmadığını (Kaynak: Standish Group Chaos Report 2009) anlatmak da işe yarayabilir. Ayrıca değişiklik isteklerinin olumlu karşılandığı, Ürün İş Listesi (Product Backlog) içinde önceliklendirmelerin proje boyunca yapılabileceğini aktarmak da müşterileri rahatlatacaktır.
  • Takımla birlikte tüm döngülerde çalışacak kadar zamanımız yok! Özellikle Ürün Sahibi (Product Owner) olan müşteriler bu konuyu gündeme getirebilir. Burada takımla birlikte çalışmanın ve takıma hızlı bildirim vermenin sağlayacağı faydalar anlatılabilir. Eğer gerçekten de istenen katılım sağlanamıyorsa, en azından Döngü Gözden Geçirme toplantısına mutlaka katılımını sağlayacak bir model oluşturup, Ürün Sahibi rolünü müşteriyle en yakın çalışan takım üyesine vermek de bir alternatif olabilir.

Herkes için ortak olanlar da bulunuyor, bunların sadece başlıklarını belirtiyorum. Bunlara sunulacak argümanlar, sizin yaratıcılığınıza kalıyor. 
  •  Şu anda rahattım
  •  Değişimden korkuyorum
  • Daha çok çalışmam gerekecek
  • Başkalarıyla daha çok konuşmam gerekecek, konuşmayı sevmiyorum

Temel olarak değişim yönetimi başlıkları olan bu konuları iyi yönetebilmek, direnç noktalarını iyi belirleyip gerekli hazırlıkları yapmak, dönüşümün başarılı olması için çok önemli anahtarlardır.



6 Nisan 2016 Çarşamba

Başarıya Farklı Bir Bakış

Başarı günümüz modern dünyasında çok sık karşımıza çıkan bir kavram. Bu kavramı daha önce proje perspektifi ile ele almıştık (İlgili Makaleler:Projelerde Başarı EtkenleriBaşarılı Proje Ekibinin SorularıÖğrenilmiş Çaresizlik).
Bu yazıda genel olarak başarıdan bahsetmek istiyorum. Okulda başarı, sınavlarda başarı, spor müsabakalarında başarı ve iş hayatında başarı ise biraz daha öne çıkan kavramlar. Kimi için okuldan atılmamak başarı iken, kimi için okuldan dereceyle mezun olmak başarı. Kiminin sınavdan geçer not alması başarılı kabul edilirken, kiminin sınavdan tek bir yanlış cevabı başarısızlık olarak görülüyor. Kiminin olimpiyatlara katılabilmesi başarı iken, kiminin olimpiyatlarda gümüş madalya alması hayal kırıklığı olabiliyor. Kiminin iş bulabilmesi başarı olarak nitelenirken, kiminin genel müdür olamaması başarısızlık olarak algılanabiliyor. Peki çok farklı şekilde kullanılabilen başarı kavramı nedir? Türk Dil Kurumu’nun başarı tanımı bir işi istenen şekilde sonuçlandırmak. Burada başarıyı göreceli hale getiren “istenen şekilde” kısmı. İstenen ve elde edilen karşılaştırılınca başarı ve başarısızlık arasındaki çizgi belirleniyor. Örneğin olimpiyatlarda altın madalya istenirken gümüş madalya almak başarısızlık olabiliyor.
Başarılı olmayı veya istenen sonuca ulaşabilmeyi neler etkiliyor? Ben dört temel faktör olduğunu düşünüyorum:
  • Sahip Olunanlar: Genetik miras, maddi miras gibi doğuştan gelen ve etkileme imkanımız olmayan koşulları bu başlıkta düşünebiliriz. Bu koşulları değiştirme şansımız bulunmuyor. Bunları sabit kabul edebiliriz. Herkesin doğuştan gelen bir yeteneği, bir yatkınlığı, bir üstünlüğü bulunduğunu düşünüyorum. Eğer yeteneğimiz/yatkınlığımız/üstünlüğümüz olan bir alanda başarılı olmak istiyorsak avantajlıyız diyebilirim.
  • Çevresel Koşullar: İçinde bulunduğumuz çağ, ülke, kültür, toplum, kurumlar, ailemiz, arkadaşlarımız, yaşadığımız çevre, okuduklarımız, dinlediklerimiz, okullarımız, işyerlerimiz, yediklerimiz, içtiklerimiz vb. yani yaşamımızın bütün değişkenlerini bu başlıkta düşünebiliriz. Bunların bir kısmını değiştirme imkanımız varken bazılarını değiştirme imkanımız olmaz ve bunlarda oluşan değişim dalgaları bizi de etkiler ve başarılı olma veya olmama durumunu belirleyebilir.
  • Hedef: Başarı tanımımızda yer alan istenen sonuç yani hedef başarı durumumuzu belirler. Bu nedenle doğru hedef seçmek çok önemlidir. Ulaşılması imkansız hedefler belirlemek motivasyonu düşürdüğü gibi çok kolay ulaşılabilecek hedefler de gelişimi ve ilerlemeyi örseler.
  • Çaba: Tamamen bize bağlı olan, başarı ve başarısızlık arasında en çok fark yaratabileceğimiz faktörün bu olduğunu düşünüyorum.

Yukarıdaki faktörleri birleştirince herhangi bir alandaki başarıyı şu şekilde formülüze edebileceğimizi düşünüyorum:
  • Sonuç = Sahip Olunanlar + Çevresel Koşullar + Çaba
  •  Sonuç >= Hedef (Başarı)

Bu denklemde öncelikle bir Sonuç elde etmek için sonuca etki edecek tüm parametreler toplanıyor. Sonucun Hedef'ten büyük veya eşit olması durumunda başarı tanımındaki “istenen sonuç” ortaya çıkıyor ve başarılı kabul ediyoruz. Çaba ve Hedef bizim en çok belirleyici olduğumuz alanlar. Eğer Hedef yüksekse buna uygun Çaba harcamadan başarıya ulaşılamaz. Başarı faktörlerini grafikle de gösterebiliriz. Grafiklerde konunun daha net görülebilmesi için her bir faktöre rakam verdim. Bu faktörleri ve etkilerini rakamlara dökmek başlı başına bir bilimsel çalışma olabilir. İlk grafikte elde edilen Sonuç, Hedef'in altında kalıyor. Sonucun Hedef'i geçebilmesi için izlenecek ilk yol ikinci grafikteki gibi Hedef küçültmek olabilir. Bu sayede başarı yakalanabilir. Ancak bu daha fazla Çaba harcamamak için yapılan bir kandırmacadır. Üçüncü grafikteki yaklaşımda ise Çaba artırılmış ve istenen sonuca ulaşılmıştır.

Sahip Olunanlar ve Çevresel Koşullar’ın uygun olduğu bir alan seçilmesi durumunda yeterli Çaba da gösterilirse büyük ve etkileyici başarılara ulaşılabilir. Örneğin doğuştan müzik yeteneği olan bir çocuğun, uygun müzik eğitimlerini alması ve yeterli Çaba'yı göstermesi ile tanınan bir sanatçı haline gelmesi mümkündür. Eğer müzik yeteneğini yokken veya uygun eğitimleri almadan, sadece Çaba gösterilirse ilerleme kaydedilir ancak tanınan bir sanatçı olmaya yetecek başarıya ulaşılamaz.
Bir başka konu da her alanda Sahip Olunanlar ve Çevresel Koşullar'ın aynı oranda etki etmediği gerçeği. Bazı alanlarda Sahip Olunanlar'ın etkisinin yüksek olabildiği, bazı alanlarda Çevresel Koşullar'ın daha belirleyici olduğunu hepimiz biliyoruz. Her ne kadar bu iki faktörün etkisi yüksek de olsa Çaba ile en zor alanlarda bile değişim sağlanabiliyor. Örneğin insanın zeka tiplerinden en çok bilineni ve en çok ölçüleni IQ'nun genetik olduğunu düşünürüz ve Çaba ile değişmeyeceği kanaati hakimdir. Bunun tam tersini söyleyen araştırmalar bulunmakta yani Çaba ile IQ'nun artabildiği veya tembellik ile azalabildiği yönünde. Yani IQ'nuzu 5 puan artırmak gibi bir Hedef belirlerseniz, bunu yeterli Çaba ile başarmanız mümkün. 
Yukarıda anlattıklarımdan hareketle iki temel prensibin başarı için önemli olduğunu düşünüyorum:
  • Sahip Olunanlar ve Çevresel Koşullar’ın uygun olduğu bir alan ve gelişimi zorlayıcı akıllı bir Hedef seçilmesi
  • Yeterli Çaba’nın harcanması
Bu iki prensip bir araya geldiğinde etkileyici başarılardan söz etmek mümkün olabilir.

18 Şubat 2016 Perşembe

Çevik Yöntemlerde Performans Ölçümü

Çevik yöntemlerle ilgili çeşitli güncel başlıklara daha önce değinmiştik (İlgili Makaleler: Çevik Yöntemlerde Sık Yapılan HatalarÇevik Yöntemler ve Teknik MükemmellikÇevik Yöntemlerdeki Rollere Uygun Profiller). Çevik yöntemler ve ölçme yan yana düşünül(e)meyen kavramlar gibi görünüyor, bir araya gelebilirler mi? Bildiğimiz performans ölçümü yaklaşımları çevik projelerde işimize yarar mı? Bu yazıda bu sorulara yanıt arayacağız ve performans ölçümünün çevik dünyadaki yerini aktarmaya çalışacağız. 

Çevik yöntemlere dönüşümün başarılı olabilmesi için organizasyonel, süreçsel, yönetsel ve kültürel dönüşümün birlikte olması gerekliliği bilinen bir gerçek (İlgili Makale:Çevik Yöntemlere Dönüşüm). Bu parçalardan birinin dönüşmemesi, çevik dönüşümün tamamını zedeleyebiliyor. Hangi parçanın ne kadar dönüştüğü ve ne kadar geliştiği ise performans ölçümü ile ortaya çıkarılabiliyor. Dahası performans ölçümü ile elde edilen sonuçlar geri bildirim olarak kulllanılarak hangi alanda ne kadar yol katedildiği, hangi alanların gelişime açık olduğu belirlenebiliyor. Bu sayede çevik yöntemlerin daha etkin kullanılmasına da olanak sağlanıyor.  

Çevik projeleri klasik performans ölçüm yaklaşımı ile değerlendirmek yeterli olmuyor. Örneğin klasik yaklaşımda proje başarısı “başta belirlenen tüm kapsamın”, belirlenen bütçe ve zaman limitleri dahilinde gerçekleştirilmesidir. Çevik yaklaşımlarda “tüm kapsamın” tamamlanması bir amaç değildir. Kapsam, Ürün Talep Listesi’ne (Product Backlog) eklenen ve çıkarılan her bir madde ile sürekli değişebildiği için “başta belirlenen tüm kapsam” maddesinden çevik yaklaşımlar otomatik olarak sınıfta kalacaktır. Çevik dünyada kapsam yerine müşteriye sunulan "değer" ön plana çıkarılıyor. Değeri sağlamak için tüm kapsamı yapmak gerekmiyor, öncelikli ve çalışan parçaları mümkün olduğu kadar erken ve sık teslim etmek tercih ediliyor.

Klasik “başarı” ölçümü yaklaşımı bir hedef belirlemek ve sonucu bu hedefle kıyaslamaktan geçiyor. Bu her zaman “başarılı” ve “başarısız”ı doğru olarak ölçebilir mi? Bir örnek vermek gerekirse, bir sınava gireceğinizi ve hedefinizin 10 üzerinden 7 almak olduğunu düşünün, eğer 7 alırsanız, sonuç hedefinize uygun olduğu için performansınız “başarılı” olacaktır. Eğer aynı sınavdan 9 almayı hedeflediyseniz ve 8 aldıysanız klasik performans ölçümü yaklaşımı ile hedefe ulaşamadığınız için “başarısız” olarak niteleneceksiniz. Peki sınavdan 7 almak mı yoksa 8 almak mı daha büyük bir başarı? 

Çevik dünyada sürdürülebilir gelişim ve iyiye doğru devamlı ilerleme teşvik ediliyor. Örneğin 3 sınavdan sırasıyla 9,8,7 (ortalaması 8) almak mı yoksa 6,7,8 (ortalaması 7) almak mı daha iyi? Sınavın ortalama puanına göre ilk durum daha iyi gibi görünüyor. Ancak artan bir performans çevik dünyanın felsefesine daha uygun.

Yukarıdaki yaklaşımlardan yola çıkarak çevik yöntemlerde 2 boyutlu bir performans ölçümü öneriliyor. İlki ürünün müşteriye sağladığı katkı yani değer (business value). Bunu ölçmenin en temel yolu ürünün sağladığı ekonomik katkının, Yatırım Geri Dönüşü (ROI-Return on Investment, ilgili makale: Proje için Finans) gibi parametrelerle belirlenmesinden geçiyor.  İkinci boyut ise ürünün ortaya çıkarılmasındaki performansın ölçülmesi,  bunlardan başlıcaları:
  • Üretkenlik: Yapılan iş/fonksiyonalite miktarının (tamamlanan kullanıcı hikayesi, use case, özellik vb.) belirlenmesi. Bu ölçümün trend olarak izlenmesi, çevik takımın kendi gelişimini de görmesine yardımcı olacaktır. Gelişimin izlenmesi için Epic Burn-up Chart veya Product Burn-down Chart kullanılabilir.

  •  Verimlilik: Birim zamanda üretilen iş miktarının ölçülmesi ile çevik takımın verimliliğini izlemek mümkün olacaktır. Örneğin çevik takımın bir döngüde (iterasyon) üretebildiği iş miktarının belirlenmesi ile sonraki döngülerde taahhüt edeceği iş miktarını da buna uygun seçme imkanı olacaktır. 

  • Güvenilirlik: Sunulan ürünün sağlamlığı, güvenilir oluşu bu başlıkta izleniyor. Bu amaçla farklı metrikler tasarlanabilir. Örneğin yazılım projelerinde kod satır sayısı başına düşen hata oranı ile ürünün teknik kalitesi ve güvenilirliği ortaya konabilir. Ürünü teknik yönden kararlı olmasını sağlayan tüm metrikler de bu başlık altında düşünülüyor. 

Yukarıdaki başlıklar altında tasarlanacak performans metrikleri ile çevik takımın kendi içindeki gelişimini izlemesi, iyileşme potansiyelini fark edip artan bir performans grafiği yakalaması bekleniyor. Her çevik döngü sonunda yapılan retrospektiflerde (İlgili Makale:Çevik Yöntemlerde Retrospektif) bu amaca hizmet edilerek bir sonraki döngü için bir gelişim teması belirleniyor. 

Çevik yöntemlere dönüşümü hedefleyen kurumlarda daha en başından itibaren mevcut durumun belirlenmesi, gelişimin ölçülmesi ve trendinin izlenmesi, çevik yaklaşımların kattığı değerin net olarak görülebilmesi için çok büyük önem taşıyor. Burada da üç boyutlu :bir yaklaşım öneriliyor:
  • İlki dönüşüme konu ekiplerin kendi içindeki gelişimin trend analizi.
  • İkincisi dönüşüme konu olan ve olmayan ürünlerin kıyaslamasının trend analizi. Bunu dikkatli yönetmek gerekiyor. Takım bazında değil, ürün bazında yapmak lazım. Takımlar kıyaslanmamalı.
  • Üçüncüsü şirketin toplamında yaratılan değişimin trend analizi.

İster çevik yöntemlere dönüşüm yolunda olsun, ister çevik metodolojileri daha iyi kullanabilme yolunda olsun, gelişimi izleyebilmek ve iyileşme fırsatlarını görebilmek için ölçmek gerekiyor. Son söz olarak ölçmeden yönetemeyeceğimizi unutmamak gerekiyor.

6 Ocak 2016 Çarşamba

Çevik Yöntemlerde Sık Yapılan Hatalar

Ülkemizde giderek daha fazla ilgi çeken çevik yöntemlerle ilgili çeşitli yazıları (İlgili Makaleler: Çevik Yöntemlere Yolculuk, Çevik Yöntemler ve Teknik Mükemmellik, Büyük Ekipler Çevik Yöntemleri Uygulayabilir mi? ) daha önce kaleme almıştık. Bu yöntemleri uygulamaya çalışan bazı kurumlar istenen sonucu alamıyor ve bir süre sonra pes ederek eski alışkanlıklarına dönüyor. Bu başarısız dönüşüm çabalarından sonra çevik yaklaşımın kendi kurumlarına göre olmadığını belirtenlerin sayısı da azımsanmayacak kadar yüksek. Aslında çevik yöntemlerdeki uygulama hataları da bu başarısız dönüşüm çabalarında önemli yer tutuyor. Bu yazıda sık yapılan uygulama hatalarını ele alacağız:
  • Yanlış Çevik Metodoloji Seçimi: Yapılan çalışmaya, ekibe ve projeye uygun olmayan bir yaklaşımla çalışılması doğal olarak başarı getirmeyecektir. Örneğin Kanban kullanmanın uygun olabileceği yerlerde herkes Scrum kullanıyor diye bu yaklaşımın kullanılması, ekibin motivasyonunu da verimliliğini de olumsuz etkileyecektir. Doğru çevik yaklaşımın belirlenmesinin proje, ürün ve ekip özelindeki dinamiklerin incelenmesi ile mümkün olacağını unutmamak gerekiyor.
  • Yetkin Olmayan Ekipler: Tüm çevik yaklaşımlarda ortak olan konulardan bir tanesi çevik takımın kendini organize edebilmesi, işi küçük parçalara ayırabilmesi ve bunları kendini içinde planlayarak yapabilmesidir. Bu kabiliyetleri olmayan, dahası yönlendirmeye gereksinim duyan, direktifsiz çalışamayan ekiplerle çevik takım kurmak ve bu takımlardan üretim beklemek haksızlık olacaktır. Hem organizasyonel becerileri, hem iletişim becerileri hem de teknik yetkinlikleri yüksek olan takımların çevik yöntemleri hakkıyla uygulayabileceğini unutmamak gerekiyor.
  • Dokümantasyon Yapılmaması: Çevik çalışmayı hiçbir dokümantasyon yapmadan çalışma olarak algılayan ekipler de var. Bu yaklaşım doğru değil, çevik metodolojilerle çalışırken gerekli olan dokümantasyonun mutlaka yapılması gerekiyor. Ürün kalitesine, sürdürülebilirliğe katkı yapacağı için bunu atlamamak gerekiyor. Burada en önemli prensip asgari yeter (barely sufficient) prensibine uygun olarak gerekli dokümantasyonu asgari yeter seviyede yapmak, ötesine geçmemek gerekiyor. Eğer süreçler gereği kullanılmayan dokümanlar üretiliyorsa, bunu kendiliğinden yapmamak yerine süreçlerden kaldıracak girişimlerde bulunmak da doğru bir yaklaşım olacaktır.
  • Kısmı Uygulama: Çevik manifestonun ve arkasındaki prensiplerinin işine gelen kısmını uygulamak işine gelmeyenlerini göz ardı etmek, seçilen metodolojinin bazı kısımlarını yok saymak gibi yanlışlar ne yazık ki yapılıyor. Bu da istenen sonuçların alınmasını engelliyor.
  • Sadece Mühendislik Ekipleri ile Sınırlama: Genellikle çevik yaklaşımların sadece mühendislik ekiplerinin çalışmalarını düzenlediğini düşünen ve kendini bu çemberin dışında gören ekipler ve paydaşlar da oluyor. Örneğin müşterinin, üst yönetimin, kalite ekiplerinin de çevik yaklaşımlara uygun olarak kendi çalışma yaklaşımlarını değiştirmeleri ve uygulanan çevik metodolojiye uygun hale getirmeleri gerekiyor.
  • Şampiyon (CEO vb.) Olmaması: Çevik çalışmaların arkasında duracak, bu dönüşümün
    sponsoru olacak, eskiye dönüş konusunda gelecek baskıları durdurabilecek güçte bir kişinin 
    yani şampiyonun desteği mutlaka gerekiyor. Özellikle CEO’ların bu şampiyon olması tercih
    edilen bir durum.
  • Hatalı Yönetim Tarzı: Direktif verici ve kontrol edici yönetim tarzının (command and control) çevik dünyaya uygun olmadığı bir gerçek. Çevik takımların kendi işlerini organize edebilen, bu işleri kimsenin talimatına ihtiyaç duymadan yapabilen takımlar olduğu gerçeğinden yola çıkınca direktif veren bir yöneticinin böyle bir takımın harmonisini nasıl bozacağını tahmin etmek zor olmayacaktır. Çevik dünyada istenen yönetim tarzı ise hizmet eden liderlik (İlgili Makaleler: Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerdeki Rollere Uygun Profiller) anlayışını barındırmalıdır.
  • Ekibin Başına Buyruk Davranması: Çevik takımların kendini organize edebilme yeteneğini kötüye kullanarak, müşteriyi, ürün sahibini ve diğer paydaşları dikkate almadan çalışması da çevik yöntemlerden istenen sonuçların alınmasını engelleyen bir durum olarak karşımıza çıkıyor. Özellikle gelişmeleri görmek isteyen müşterinin reddedilmesi, geri bildiriminin yeterince alınmaması “çalışan ama işe yaramayan” ürünlerin ortaya çıkmasına sebep olmaktadır.
  • Liderlerin İlgisiz Davranışları: Çevik takımlardaki ürün sahibi veya yönetici rolündeki (scrum master vb.) kişilerin geliştirme takımlarının yaşadıkları sorun ve karşılaştıkları engellere duyarsız kalmaları ve “siz kendiniz çözün” gibi yanıtlar vererek takımın önünü açmamaları da çevik yöntemlerde yaşanabilen bir hatadır.  Bu tür durumlarda çevik takımlar, ilerlemek için harcayacakları enerjiyi sorunların takibi ve çözümü gibi konulara kaydırmak durumunda kalıyor.
  • İş Biriminin/Müşterinin Yetersiz Katılımı: Müşterinin veya iş birimlerinin projeye tam olarak dahil olmaması, gerekli yönlendirmeleri yapmaması, zamanda karar alamaması ile çevik takımların önü tıkanıyor. Bu da sık yaşanabilen ve çevik yöntemleri kullanan takımların istenen üretkenliğe ulaşmasını engelleyen bir durumdur.
  • Kovboy Kodlaması: Çevik yazılım yapmayı kuralsız çalışmak olarak algılayan kişiler ne yazık ki bulunuyor. Bu da çevik yaklaşımların ortak prensiplerinden olan sürdürebilirlik ve teknik mükemmeliyet başlıkları ile çelişiyor.

Yukarıdaki tespitlere başka maddeler de eklemek mümkün. Çevik yöntemlerin başarılı olabilmesi için bu sık yapılan hataları tekrarlamamakta fayda var. Ayrıca çevik yöntemlerden istenen sonuç alınamıyorsa, bunun faturasını çevik yönteme kesmek yerine uygulama biçimini gözden geçirmek, doğru uygulamanın yollarını bulmak ve en iyi örnekleri incelemekte de yarar görüyorum. 

3 Kasım 2015 Salı

Büyük Ekipler Çevik Yöntemleri Uygulayabilir mi?

Daha önce çevik yöntemlere dönüşümle ilgili yazılar kaleme almıştık (İlgili Makaleler: Çevik Yöntemlere YolculukÇevik Yöntemlere Dönüşüm). Çevik yöntemlere dönüşümde hemen herkesin aklına küçük ekiplerin bir arada çalıştığı üretken ortamlar geliyor. Dahası çevik yöntemlerin küçük firmalar ve aynı yerde çalışan ekipler için uygun olduğu düşünülüyor. Peki, büyük ekipler, farklı yerlerde çalışan takımlar ve kurumsal şirketler çevik yöntemlere geçebilir mi? Örneğin 500 çalışanı olan bir ar-ge bölümü, çevik yöntemlerle çalışabilir mi? Ya da dünya çapında 5 farklı ülkede ofisi olan bir firmada çevik yaklaşımlar uygulanabilir mi?

Ekipteki kişi sayısı arttıkça, takımlar farklı yerlerde (farklı ülke, şehir veya ofis) çalıştıkça, kurumsallık yükseldikçe çevik yöntemleri oldukları gibi uygulamak giderek zorlaşıyor. Ya kurumdaki rolleri ve süreçleri eğip bükerek çevikleştirme yoluna gidiliyor, ya da çevik yöntemleri eğip bükerek kurumlara özgü “çevik ama ...” yöntemler türetiliyor. Hangisi yapılırsa yapılsın, bir şeyler yerli yerine oturmuyor ve bir süre sonra eski alışkanlıklara dönüş eğilimi başlıyor. Bütün bunları aşarak gerçekten uygulamayı başarabilen kurumlarda ise arka planda çevik şövalyeleri diyebileceğimiz insanların olağanüstü gayretleri oluyor. Bu insanların motivasyonlarını yitirmeleri veya kurumdan ayrılmaları durumunda geçmişe dönüş hemen başlıyor.

Büyük ekiplerin çevik yöntemlerle çalışmasındaki zorluklar dünyada epeyce kafa yorulan bir alan. Buna yanıtlardan birisi son birkaç yıldır duyulan LeSS (Large Scale Scrum). Craig  Larman ve Bas Vodde’nin öncülüğü yaptığı bu yöntem Scrum’ın temel felsefesine bağlı kalarak, büyük ve çok büyük ekipler için iki farklı çatı öneriyor.  İlk çatıda 10’a kadar Scrum takımının aynı ürün üzerinde çalışabileceği bir sistematik öneriliyor. İkinci çatıda daha kalabalık ekiplerin örneğin birkaç bin kişinin çalışabileceği bir yapı sunuluyor. Her iki çatıda da tek bir Ürün Sahibi (Product Owner), tek Ürün İş Listesi (Product Backlog) ve sabit süreli Sprintler yer alıyor. Scrum’in temel prensipleri korunmak kaydıyla birinci çatının bildiğimiz Scrum’dan farklı olduğu noktalar:
  •  Sprint planlamanın iki aşamalı olması: İlkine her takımdan ikişer kişinin katılıyor ve ürün sahibi ile birlikte hangi takımın hangi işi seçeceği konuşuluyor. Burada kritik nokta takımların farklı yazılım katmanlarında uzmanlaşmış olmak yerine uçtan uca geliştirme yapabilecek şekilde oluşturulmuş olması bekleniyor. Bu sayede bütün takımlar gözle görülür çıktılar üreterek demo yapabiliyorlar. İkincisini ise takımlar kendi içlerinde yapıyorlar, farklı takımlardan kişiler diğer takımlardaki planlamayı izlemek isterlerse kapılar sonuna kadar açılıyor.
  •  Günlük Toplantılar, Scrum’la aynı olmakla birlikte takımlar birbirlerinin toplantılarını izleyebiliyorlar.
  • Takımlar-arası Koordinasyon Toplantıları: haftada en az bir kez, SoS (Scrum of Scrums) ya da benzeri bir toplantı ile takımların birbirlerindeki gelişmelerden haberdar olması sağlanıyor.
  • İş Listesi Sadeleştirme (Product Backlog Refinement) toplantıları da iki aşamalı yani takımlararası ve takım içi olarak yapılıyor.
  • Sprint Gözden Geçirme (Sprint Review) ise tüm takımların katıldığı ve daha çok bir teknoloji fuarı havasında geçen, tüm takımların kendi demolarını yapabileceği bir ortamda gerçekleştiriliyor.
  • Retrospektifler (İlgili Makale: Çevik Yöntemlerde Retrospektif) de yine iki aşamalı olarak yapılıyor.

İkinci çatıda ise bir ürün sahibinin tüm takımlara yetişemeyeceği ve ofislerin farklı yerlerde olabileceği varsayımıyla Yerel Ürün Sahipleri (Local Product Owner) görev yapıyor. Ürün İş Listesi tek olduğu için takımların çalışmaları tek yerden takip edilebiliyor. Toplantı ve iş akışları ise yukarıdaki yaklaşıma uygun gerçekleşiyor.

Büyük ölçekli ekiplerin uyumlu çalışmasındaki temel konu koordinasyonun sağlıklı yapılabilmesi. Bu amaçla LeSS içinde alttaki yaklaşımlar öneriliyor:
  • Devamlı ve kesintisiz entegrasyon
  • Takımların tamamına açık kodlar ve standart kodlama yaklaşımı
  • Uçtan uca geliştirme yapabilen dikey takımların kurulması
  • Pratik Toplulukları (Communities of Practice) ile takımlar arası mimari, standartlar, kullanıcı deneyimi gibi konuların yönetimi
  • Takımların yönettiği yazılım derleme sistemi
  • Ve tabi ki daha fazla iletişim ve konuşma :)
Biz birinci çatıyı 4 takımla İzmir ve Ankara'da kullanıyoruz. Tek Ürün İş Listesi ve tek Ürün Sahibi'nin bu 4 takımı beslediği bir yapı kurduk. Haftalık SoS de yaparak iletişimi artırmaya gayret ediyoruz. Sprint sonu gözden geçirmelerini her takımın sunum ve demo yaptığı çalıştaylar olarak bir araya gelerek yapıyoruz. Kodlama standartları ve uçtan uca geliştirme yapabilen dikey takımların oldukça yararlı olduğunu gözlüyoruz. 10 ayımızı tamamladık. Özellikle büyük ekipler ve farklı şehirlerde yer alan takımlar için yararlı olabileceğini düşünüyoruz.

Kaynakça:
  1. less.works
  2. Larman C., Vodde B., 2013 Scaling Agile Development, CrossTalk.
  3. Larman C., Vodde B., 2010 Practices for Scaling Lean & Agile Development, Addison-Wesley.


4 Eylül 2015 Cuma

Çevik Yöntemler ve Teknik Mükemmellik

Önceki yazılarımızda çevik yöntemlerde roller (İlgili Makaleler: RollerRollere Uygun ProfillerLiderlik), çevik yöntemlere geçiş (İlgili Makaleler: DönüşümUygulayabilmek) ve diğer önemli başlıklara (İlgili Makaleler: Başarının AnahtarlarıToplantılar, GüvenAnalizTest Yönetimi) temas etmiştik. Çevik yöntemlere geçen birçok ekip öncelikle rollere, proje yönetim prensiplerine, toplantılara, dokümanlara ve iş listelerine odaklanıyor. Roller benimsenip, proje yapıları ve toplantı rutinleri oturunca, dokümanlar sadeleştirilip iş listeleri de işler hale geldiğinde çevik dönüşümün tamamlandığı gibi bir yanılsama ortaya çıkıyor. Eğer bir de bu adımlar üretim hızını artırırsa çevik dönüşümle istenen sonucun alındığı düşünülüyor. Üretim hızı kadar yapılan işin teknik yönden sağlam ve aynı zamanda esnek olması gereklliliği genelde göz ardı ediliyor. Sağlamlığı ve esnekliği de bünyesinde barındıran “Teknik Mükemmellik” kavramı hak ettiği yeri alamıyor. Bu yazımızda Çevik Manifesto’nun ardındanki 12 prensipten biri olan Teknik Mükemmellik başlığını ele alacağız.

Bu prensip çevik manifestoda tam olarak şu şekilde ifade ediliyor: “Continuous attention to technical excellence and good design enhances agility”, türkçesi “Teknik mükemmellik ve iyi tasarım konusundaki sürekli özen/dikkat çevikliği artırır.” Bu prensibi sondan başa doğru ele almakta yarar görüyorum. Öncelikle sürekli özene değinmek istiyorum. Hepimizin bildiği üzere çevik dünyada hep bir adım ileri gitme ve gelişimi sürekli kılma ön planda yer alıyor. Hatta bu gelişimi takımın kendi dinamikleri içinde başarabilmesi bekleniyor. Retrospektiflerin (İlgili Makale: Retrospektif) amacı tam da  bu gelişimi devamlı kılmak, hep bir adım ileriye gidebilmek. Tüm başlıklarda olduğu gibi tasarım ve teknik çerçevedeki ilerleme konusundaki sürekli özen de teşvik ediliyor. Hep daha iyisinin olabileceği düşünülüyor, hep bir adım ötesi hedefleniyor.

Teknik Mükemmellik kavramı ile genelde iyi tasarım birbiriyle özdeşleştiriliyor. İyi tasarım bu prensipteki hedeflerden bir tanesi. Bununla birlikte prensipte Teknik Mükemmellik özellikle ve ilk başta ifade ediliyor. İyi tasarım, Teknik Mükemmellik için gerekli ama tek başına yeterli değil. Çok iyi bir tasarım yaptıktan sonra bunu nasıl gerçekleştirdiğiniz ve nasıl test ettiğiniz de bir o kadar önemli. Tasarımı hayata geçirirken hangi alt parçalara ayırdığınız, bu parçaları hangi sıra ile ele aldığınız, aralarındaki bağımlılıkları nasıl yönettiğiniz,  her birini nasıl gerçekleştirdiğiniz, birim testini nasıl yaptığınız, nasıl entegre ettiğiniz, oluşan son ürünü nasıl kontrol ettiğiniz; bütün bunlar üretilen son çıktının kalitesine etki edecektir ve dolayısıyla Teknik Mükemmellik konusudur. Son ürünün kalitesini artıracak, sağlamlık ve esneklik getirecek tüm aksiyonlar Teknik Mükemmellik içinde değerlendirilebilir.

Teknik Mükemmellik için önemli bir adımı da ölçme ve değerlendirme oluşturuyor. Çevik dünyaya yolculuğa çıkarken teknik olarak kurumun bulunduğu durumun fotoğrafını çekmek, hangi noktalarda zayıflıklar olduğunu tespit etmek ve öncelikle bunlara odaklanmak önem taşıyor. Ayrıca çevik yöntemlerle ilerlerken teknik yönden gelişimin izlenmesi ve hedeften ne kadar uzakta olunduğunun tespit edilmesi de gerekiyor. Teknik seviyenin belirlenmesini metrik ölçümlere dayandırmak ve subjektif değerlendirmelere engel olmak da gelişimin daha şeffaf izlenebilmesini sağlıyor. Bu sayede doğru değerlendirmeler yapmak ve isabetli adımlar atarak Teknik Mükemmelik yolunda gelişimi sürdürmek mümkün olabiliyor.

Çevik dünyada teknik pratikler ve iyi uygulamalar söz konusu olduğunda eXtreme Programming (İlgili Makale: XP) ve Test Güdümlü Geliştirme  (İlgili Makale: TDD) gibi teknik yaklaşımlar ön plana çıkıyor. Bunların Teknik Mükemmeliyete önemli katkıları olduğu şüphe götürmez. Bunların dışında kurumunuza özgü ihtiyaçlar için farklı yaklaşımların da benimsenmesi mümkün. Hangi yaklaşım benimsenirse benimsensin önemli olan onu takımların özümsemesini sağlamak ve kalıcı hale getirebilmek. Dahası sürekli özenle Teknik Mükemmelliği ön planda tutabilmek. Unutmamak gerekiyor ki, çevik yöntemler bürokrasiyi azaltıp, işleri daha kolay yapabilmek için zemin hazırlarken, takımlardan daha kararlı ve daha kaliteli ürünler bekliyor.




1 Eylül 2015 Salı

Çevik Yöntemlere Yolculuk


Proje Yönetim Dünyası Dergisi'nin Ağustos sayısında yayınlanan yazımı altta sizlerle paylaşıyorum. 

Son yıllarda çokça duyulan ve popüler olan yaklaşımlardan biri de çevik yöntemler (agile methodologies). Çevik yöntemler aslında ihtiyaçtan ortaya çıkıyor. Büyük harcamalara rağmen istenen sonucun alınamadığı; bürokrasinin ve hiyerarişinin işleri yavaşlattığı; müşterinin yeterince önemsenmediği; ciltlerle dokümantasyona rağmen son ürünün çalışmadığı projeler bu ihtiyacı doğuruyor. Kökleri 1950'lere dayanan bu yaklaşım 1960'larda 1-2 haftalık iterasyonlar ve kısmi çözümlerle hızlı sonuçlar alınması şeklinde uygulanmaya başlıyor. 1980'lerde Hirotaka Takeuchi ve Ikujiro Nonaka isimli iki Japon bilim insanı yayınladıkları makale ile Scrum yönteminin temelini atıyorlar. Burada rugby oyunundaki toplu hücum toplu savunma anlayışından esinlenilerek takım olarak tüm işin sahiplenilmesi ve yapılması temel felsefeyi oluşturuyor. 1990'larda XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), Scrum, FDD (Feature Driven Development), Crystal, LSD (Lean Software Development), Kanban ve benzeri yöntemler ortaya çıkarak çeşitli projelerde kullanılmaya başlıyorlar. Her ne kadar isimleri ve detayları farklı olsa da temel prensipleri aynı olan bu yöntemlerin temsilcisi 17 kişi, 2001 yılında bir araya gelerek ünlü Çevik Manifesto ile ortak paydalarını ilan ediyorlar. Çevik Manifesto özetle:
  • süreçler ve araçlardan ziyade bireyler ve etkileşimlere 
  • kapsamlı dökümantasyondan ziyade çalışan yazılıma 
  • sözleşme ve pazarlıklarından ziyade müşteri ile işbirliğine 
  • bir plana bağlı kalmaktan ziyade değişime karşılık vermeye 
değer verilmesini salık veriyor. 

Çevik yöntemler yazılım ve bilişim projelerinde özellikle 2000’li yıllarla birlikte dünya genelinde oldukça yaygınlaşıyor. Ülkemizde de yaygınlaşma ivmesi 2010’dan sonra gözle görünür biçimde artıyor. Birçok büyük kurum ve kuruluş çevik yöntemlere geçişi başlattı veya planlıyor. Her ne kadar yazılım projelerinde yaygın olsa da çevik yaklaşımlar ve sağladığı yararlar aslında tüm ürünlere ve projelere uyarlanabilir. Bu sebeple çevik yöntemlere yolculuğu da geniş perspektiften ele alıyoruz.

Çevik yöntemlere yolculuk esas itibariyle işe, ekibe ve müşteriye bakış açısını değiştirmeyi gerektiriyor. İşi, ürün perspektifinden ve bütünsel ele almayı, kısa aralıklarla yeni kabiliyetler eklemeyi ve çalışan ürünü temel başarı göstergesi olarak görmeyi gerektiriyor. Ekibi takıma dönüştürmeyi, takıma güvenmeyi, takımın kendini organize edebilmesini, hiyerarşinin ortadan kalkmasını, kollektif sahiplenmeyi ve sorumluluğu gerektiyor. Müşterinin masanın karşısından kalkıp proje takımının yanına oturmasını, proje çalışmalarına dahil olmasını, geri bildirimlerini hemen verebilmesini, değişiklik taleplerini proje boyunca iletebilmesini mümkün kılıyor. Bu paradigma değişikliklerini üst yönetime, müşteriye ve tüm proje paydaşlarına benimsetmek çevik yöntemlerle sağlanacak başarının anahtarı oluyor. 

Çevik yöntemlerle birlikte projeye bakış açısının da değişmesi gerekiyor. Birçoğumuzun bildiği proje başarı üçgeninde köşelerde takvim, maliyet ve kapsamın olduğu; ortada kalitenin yer aldığı varsayılıyor. Takvim, maliyet ve kapsamın plana uygun gerçekleşmesinin projenin temel başarı kriterleri olduğu belirtiliyor. Gerçek hayatta ise genellikle hedeflenen kapsama erişebilmek için takvimin ve maliyetin aşıldığı, kaliteden de çoğu zaman tavizler verildiği bulgulanıyor. Bu gerçeklik karşısında çevik yöntemler, kapsamın serbest bırakılmasını, takvim ve maliyetin sabit olmasını, kaliteden ise taviz verilmemesini tercih ediyor. Elbette kapsamın serbest bırakılması kontrolsüz gerçekleşmiyor. Bilakis kapsam yönetimi Ürün İş Listesi (Product Backlog) ile yakından takip ediliyor, projedeki tüm gereksinimler bu listeye ekleniyor. Listedeki öncelikli gereksinimleri yapmak ve proje tamamlandığı noktada geriye önceliği düşük işlerin kalması temel yaklaşımı oluşturuyor. Müşterinin, Ürün İş Listesi’ne proje boyunca yeni gereksinimlerini eklemesine izin veriliyor. Bu sayede kapsam değişikliklerine fırsat tanınıyor. Gereksinimlerin önceliğini de müşteri belirliyor ve istediği noktada değiştirebiliyor. Bunun tek istisnası proje takımının üzerinde çalıştığı iş paketleri, bunlara dokunamıyor. Proje bittiği noktada, Ürün İş Listesi içinde kalan gereksinimler müşteri tarafından önceliği diğerlerine düşük olarak belirlendiği için, müşteri nezdinde de soruna yol açmıyor.

Çevik yöntemlere geçişle birlikte takımların çalışma prensipleri de değişiyor. Öncelikle takımın projeye dedike olması, başka iş ve projelerde görevlendirilmemesi gerekiyor. Burada temel gerekçe insanın bir tek konuya odaklandığında daha kaliteli ve hızlı üretebilmesi. Bunun arkasındaki sebep de insanoğlunun çoklu düşünme kabiliyetine sahip olmaması, aynı anda çok şeyi düşündüğümüzü sandığımız anlarda bile beynimizin düşünceleri teker teker ancak aralarında çok kısa aralıklar bırakarak işleme aldığı, bunun bize aynı anda çok şeyi düşünüyormuş yanılgısı yarattığı gerçeği.

Takımla ilgili ikinci önemli konu, aynı yerde birlikte çalışma, yüzyüze iletişim kurma şeklinde karşımıza çıkıyor. Mümkünse proje için ayrılmış bir odada, Takım Odası’nda tüm takımın birlikte çalışması, ekibin takıma dönüşebilmesi için büyük önem taşıyor. Takım Odası’nda projeye, ürüne ve gereksinimlere ait durumların rahat izlenebilmesi için duvarlara birşeyler asılması da ürüne odaklanmaya önemli katkı sağlıyor. Takım Odası’nda müşteri tarafından karar verebilecek bir kişinin de takımla çalışması ayrıca katkı sağlıyor. Bunun yapılamadığı durumlarda en azından müşteri ile sık aralıklarla bir araya gelmek ve yapılan çalışmaların gösterilmesini sağlamak yarar sağlıyor.

Takımla ilgili üçüncü konu işlerin planlanmasındaki ve paylaşılmasındaki değişiklik olarak kendini gösteriyor. Çalışmaları artırımlı iterasyonlar olarak planlamak, iterasyonlar sonunda müşteriye değerli ve çalışan bir teslimat sunmak hedefleniyor. İterasyonlarda kabaca nelerin yapılacağı, başta planlansa da tam olarak Ürün İş Listesi’nden hangi gereksinimlerin yapılacağına iterasyon başında takım olarak karar veriliyor. Seçilen gereksinimlerin müşteri tarafından en öncelikli olarak belirlenenlerden oluşması gerekiyor. Bu sayede müşteri için en değerli olan çalışmalara öncelik verilmiş oluyor. Takım üyeleri gereksinimler veya onlarla ilgili alt aktiviteleri kendi üzerlerine alarak paylaşıyorlar. Kimse iş ataması yapmıyor. Bu sayede bireysel sorumluluk ve takım içi güven teşvik ediliyor.

Takımla ilgili dördüncü konu rollerdeki farklılıklar olarak karşımıza çıkıyor. Üç temel rol, Ürün Sahibi (Product Owner), Çevik Proje Yöneticisi (Agile PM), Geliştirme Takımı (Develoment Team) olarak uygulanıyor. Bu rollerin farklı çevik yaklaşımlarda farklı isimleri de olabiliyor. Takım içinde farklı yetkinliklerde insanlar olması teşvik ediliyor. Bununla birlikte takım içinde yönetici veya hiyerarşi taşıyan rollere sıcak bakılmıyor. Bunun takım ruhunu örseleyeceği düşünülüyor.

Yukarıda temel bazı noktalarına değindiğimiz çevik yöntemlere yolculukta, aslında en önemli konu bakış açısını değiştirmek, farklı düşünebilmek. Buna paralel olarak Kuantum Kuramı’nı geliştiren ünlü bilim adamı Max Planck, “bakış açımızı değiştirdiğimiz zaman gördüğümüz şeylerin de değişeceğini” söylüyor. Bakış açısını değiştirmenin ilk ve en temel adımı çevik yöntemlere geçiş için gereken paradigma değişikliğine istekli olunması. Dahası bu yolculuğu sürdürebilmek için azim ve kararlılık gerektiğinin de altını çizmemiz gerekiyor.

Kaynakça:
Adkins L. (2010) Coaching Agile Teams, Addison-Wesley.
Shore J. ve Warden S. (2008) The Art of Agile Development, O’Reilly Press.
Sliger M. ve Broderick S. (2008) The Software Project Manager’s Bridge to Agility, Addison-Wesley.

12 Haziran 2015 Cuma

Çevik Yöntemlere Dönüşüm

Çevik yöntemleri son dönemde sıkça duyuyorsunuz, hatta etrafınızdaki şirketlerden dönüşüm yapanları veya deneyenleri görüyorsunuz. Çevik yöntemlerin kendi kurumunuza da faydalı olacağını düşünüyorsunuz, ancak endişeleriniz var. Aklınızda sorular uçuşuyor:
  •  “Dönüşüme nereden başlamalıyım?”
  • “Neleri değiştirmeliyim?”
  • “Kimleri dahil etmeliyim?”
  • “Nasıl yaygınlaştırmalıyım?”
  • “Eski alışkanlıklara dönüşü nasıl engellemeliyim? Dönüşümü nasıl kalıcı hale getirebilirim?”
  • “Nerede durmalıyım?”
  • “Sözde çevik noktasında kalır mıyım?”“Özde çevik olabilecek miyim?”
  • “Dönüşümün faydasını ne zaman görürüm?”


Çevik yöntemlere dönüşüm genellikle “hızlı kod yazmaya” başlamak olarak algılanıyor ve IT ekipleri ile sınırlı kalıyor. Özellikle üst yönetim, müşteri ve diğer paydaşlara yeterince anlatılmadığı için yeterince anlaşılamıyor.Dolayısıyla destek alamadığı ve istenen sonuçların ortaya çıkmadığı durumlara çok sık rastlanıyor. Halbuki dönüşüm için müşteri ve üst yönetimin tam desteği olmazsa olmaz. Onlara nelerin nasıl değişeceğini ve sonuçlarının nasıl olacağını anlatmak ve de tam desteklerini almak dönüşümün ilk adımlarından birisi olmalı.

Dönüşümler genellikle kurum çapında geniş katılımlı eğitimlerle başlıyor, eğitimlerde ideal yapılar anlatılıyor. Eğitimden sonra insanlar çevik yaklaşımları beğeniyorlar ancak kendi çalışmalarına nasıl uygulayabileceklerini göremiyorlar. Aradan zaman geçince ve uygulama fırsatı bulamayınca eğitimdeki bilgileri de unutuyorlar.Her ekibin farklı dönüşüm deneyimi oluyor. Kimi tam dönüşemeden iki arada bir derede kalıyor. Yöntemlerini anlatırken de şöyle cümleler kullanıyorlar “çevik ama...”. 


Okuduklarımdan, gözlemlediklerimden ve deneyimlerimden derlediğim birkaç dönüşüm tavsiyesine bu yazıda yer vermek isterim:
  • Çevik yöntemlere dönüşümün de bir proje olması ve hatta çevik bir proje olması. Dönüşüm için bir takım kurulması ve yaşayan bir iş listesi (product backlog) oluşturulması.
  • Uygulamanın pilot ekiplerle başlatılması ve kademeli olarak yaygınlaştırılması.
  • Çevik yöntemlerdeki rollerin iyi anlatılması ve doğru role doğru kişinin getirilmesi (İlgili Makale:Çevik Yöntemlerdeki Rollere Uygun Profiller).
  • Planlanan eğitimlerin iki aşamalı olması. İlk aşamada genel çevik yöntemleri içeren bir program, ikinci aşamada ise kurumdaki çevik uygulamanın nasıl olacağının anlatıldığı bir program. Pilot seçilen ekiplerin iki eğitimi de alması ve ardından ekibe dahil edilecek koç ile uygulamanın başlatılması.
  •  Farklı takımların deneyimlerini birbiri ile paylaşabilmesi için ortamlar yaratılması.
  •  Retrospektiflerin mutlaka etkin yapılması, ekiplerin de gelişim fırsatlarını görmelerinin sağlanması (İlgili Makale:Çevik Yöntemlerde Retrospektif).
  •  Tüm ekiplerin çevik yöntemlere geçişinin zorlanmaması. İsteyen, gönüllü olan, müşterileri ve işleri uygun olan takımlardan başlanması süreci kolaylaştırabilir.
  • Sabırlı olunması, dönüşümün en az 2 yıla yayılması. Özellikle verimliliğin artması, üretim hızının yükselmesi için acele edilmemesi gerekiyor.
  •  Dönüştükten sonra durulmaması, çevik yöntemleri daha etkin kullanabilmenin yollarının araştırılması. Bu noktada Kai-zen felsefesi ve bu felsefede olan “mükemmel yoktur, daha iyisi vardır” yaklaşımı benimsenebilir.


Bunlardan başka  önemli noktalar da muhakkak var. Bence en önemli olan zorlukları görünce pes etmemek, dönüşüme azimle devam etmek ve de gerçekten uygulayabilmek (İlgili Makale:Çevik Yöntemleri Uygulayabilmek).

8 Nisan 2015 Çarşamba

Savuşturmacı Kültür

Alttaki türden yanıtları sıkça duyuyor musunuz?
  • “Bakarız”
  • “Sonra yapalım”
  •  “Daha zaman var”
  • “Daha acil işler var”
  •  “Yönetime sormak lazım”
  •  “Bu konudan ben sorumlu değilim”
  • "Buna ne gerek var”
Bu liste uzayıp gidebilir. Bu yanıtları alınca içinizden ne geçiyor, ne düşünüyosunuz? Karşımızdakinin bir şeyi yapabilecekken yapmadığını, işten kaçındığını veya ötelediğini, değil mi? Hatta bazen karşımızdakinin zamanının olduğunu, yetkisinin uygun olduğunu ve dahası kendi işi olduğunu bilsek bile bu yanıtı alıp şaşırdığımız oluyor. O kadar yaygın ki aile içi ilişkilerde, arkadaşlar arasında bile bu durumlara çok sık rastlanıyor. Esas itibariyle hem iş hayatında hem de günlük hayatımızda çokça karşılaştığımız durumlar bunlar. Literatürde tarayabildiğim kadarıyla bir sınıflamasını bulamadım ve Savuşturmacı Kültür adınının uygun olabileceğini düşündüm. Eğer bir yerde geçiyorsa ve atlamışsam kusura bakmayın ve lütfen beni de bilgilendirin.

Savuşturmacı Kültür’ün iki stratejisinin olduğunu düşünüyorum, ilki yukarıda örneklerini vermeye çalıştığım, “işi yapmama veya öteleme”, ikincisi ise “yapılmış gibi, olmuş gibi, doğruymuş gibi gösterme”. İkinci stratejide işle veya durumla ilgili sorulara gerçek dışı yanıtlar verme, olduğundan farklı ve iyi gösterecek bilgilendirmeler yapma esastır. Bir çalışanınıza işin durumunu sorduğunuzda aldığınız şu tür yanıtlar bu duruma örnek gösterilebilir:
  •  “Bitmek üzere”
  •  “Sorun yok”
  •  “Risk yok
  •  “Hallediyoruz”
  •  “Yetişir”
Bu güzel bilgilendirmeler sonunda yönetici konumundaysanız içinize su serpilir, rahatlarsınız. Ama işin aslı öyle değildir ve nitekim işin sonunda beklenen sonuç ortaya çıkmaz, sorun olduğu da ancak duvara çarptıktan sonra ortaya çıkar.
 
İşin bitmemesi, gecikmesi veya hatalı olması durumunda da iyi bir bahane bulunması veya günah keçisi tespit edilip tüm sorumluluğun ona yüklenmesi  Savuşturmacı Kültür’ün tamamlayıcı savunma stratejisidir. Hatta çalışma boyunca “işi nasıl iyi ve zamanında yaparım?” sorusu değil “nasıl ikna edici bir bahane bulurum?”, “başarısızlığın sorumluluğunu neye bağlayabilirim?”,“kimi günah keçisi yapabilirim?” türünde sorular da zihinleri meşgul eder. İşin sonunda sorunun kaynağını sorduğunuzda hep başka birisi hatalıdır veya başka bir kurum işini iyi yapmamıştır.

Bir kurumda Savuşturmacı Kültür ne kadar hakimse verimlilik ve etkinlik o kadar düşüktür. Kuruma sonradan katılanlar da ister istemez bu kültürün etki alanına girerler. Kimsenin iş yapmak istemediği, bunu da farklı bahanelerin arkasına saklanarak dolaylı dile getirdiği bir ortam oluşur. Yürüyen işler gereği gibi şeffaf raporlanmaz, tüm işlerin sorunsuz ilerlediği yanılgısı oluşturulur. Bu sorunsuz(!) işlerin sonuçlarındaki başarısızlıklar da hep başka bir etkene bağlanır veya yanlış kişilere fatura kesilir. Başarısızlığın sebeplerinin yanlış teşhis edilmesi sonucu ortaya çıkar ve yanlış tedaviler uygulanır. Bu tedavilerde istenen sonuçlar alınamaz ancak Savuşturmacı Kültür bu noktada da devreye girerek kök sebebe inilmesine izin vermez.

Bir çok kurumda Savuşturmacı Kültür’ün hakimiyeti bulunuyor ve maalesef farkına varılamıyor. Savuşturmacı Kültür’ün panzehirinin alttaki adımlardan geçtiğini düşünüyorum:
  • Bahane üretme yerine Sorumluluk Alma: İşin yapılmaması için bahane üreten kişilerin teşvik edilmediği; sorumluluk alarak işleri yapma motivasyonu taşıyan kişilerin ödüllendirildiği bir çalışma ortamının oluşturulması.
  • Yanlış raporlamalar ve manipülasyon yerine Şeffaflık: Yanlış, eksik veya yanlı raporlamaların, bilgilendirmelerin kabul edilmediği; sorunların/risklerin tespit edildiği anda şeffaf olarak aktarıldığı durumların kabul gördüğü iletişim ortamının sağlanması.
  • Başkasını suçlama yerine Özeleştiri Yapabilme: Hatayı hep dışarıda aramanın, başkalarını suçlamanın uygun bulunmadığı; iğneyi kendine de batırmanın öneminin vurgulandığı özeleştiri alışkanlığının kazandırılması.