Bir yazılım ekibinin takvimine bakarak ne kadar verimli çalıştığını anlamaya çalışsaydınız, muhtemelen dolu takvimleri “yoğun çalışan ekipler” olarak değerlendirirdiniz. Günün büyük bölümü refinement, planning, daily stand-up, backlog grooming, sprint review, teknik değerlendirme ve çeşitli senkronizasyon toplantılarıyla geçiyorsa, dışarıdan bakıldığında ekip sürekli iletişim halinde gibi görünür.

Ancak gerçek çoğu zaman bunun tam tersidir.

Yıllar içinde farklı büyüklüklerde ekiplerle çalışırken ilginç bir örüntü fark ettim. En başarılı ekipler, en fazla toplantı yapan ekipler değildi. Hatta çoğu zaman tam tersiydi. Teslimat kalitesi yüksek, değişikliklere hızlı adapte olabilen ve teknik borcunu kontrol altında tutabilen ekiplerin ortak özelliklerinden biri, toplantıları minimum seviyede tutmalarıydı.

Bu noktada yanlış anlaşılmaması gereken önemli bir konu var. Buradaki amaç toplantıları tamamen ortadan kaldırmak değildir. Sorun toplantının kendisi değil, toplantının organizasyondaki eksikleri kapatmak için kullanılan varsayılan çözüm haline gelmesidir.

Peki yüksek performanslı ekipler neden daha az toplantı yapıyor?

Toplantılar Genellikle Problemin Kendisi Değil, Belirtisidir

Bir ekip sürekli toplantı yapma ihtiyacı hissediyorsa, bunun arkasında genellikle daha temel bir organizasyon problemi vardır.

Belki ürün gereksinimleri yeterince net değildir. Belki teknik kararlar hiçbir zaman yazılı hale getirilmiyordur. Belki ekipte kimin hangi konuda karar vereceği belli değildir. Bazen de bilgi yalnızca birkaç kişinin zihninde bulunduğu için herkesin aynı odada bulunması zorunlu hale gelir.

Bu durumda her yeni özellik, her bug ve her değişiklik yeni bir toplantıyı beraberinde getirir.

“Bir konuşalım.”
“Bir alignment meeting yapalım.”
“Bunu bir de ekipçe değerlendirelim.”

Başlangıçta masum görünen bu yaklaşım zamanla organizasyon kültürüne dönüşür. Artık herhangi bir konuda karar almanın varsayılan yolu düşünmek veya yazmak değil, toplantı planlamaktır.

Oysa toplantılar problemi çözmez. Çoğu zaman yalnızca süreçlerdeki eksikliklerin etkisini geçici olarak azaltır.

Toplantının Görünmeyen Maliyeti

Otuz dakikalık altı kişilik bir toplantının maliyetini hesaplamak kolaydır.

Altı kişi, otuz dakika.
Toplam üç adam/saat.
Fakat gerçek maliyet bundan çok daha yüksektir.

Yazılım geliştirme, derin odaklanma gerektiren bir iştir. Bir geliştirici karmaşık bir problemi çözmeye çalışırken yalnızca kod yazmaz; aynı zamanda onlarca sınıfı, veri akışını, business rule’ları ve olası edge case’leri zihninde taşır. Bu bağlamı oluşturmak zaman alır.

Araştırmalar, kesintiye uğrayan bir geliştiricinin aynı odak seviyesine geri dönmesinin 20-30 dakikayı bulabildiğini gösteriyor. Dolayısıyla 15 dakikalık bir toplantı çoğu zaman yalnızca 15 dakika kaybettirmez. Toplantıya hazırlanma süresi, toplantının kendisi ve sonrasında yeniden bağlama dönme süreci düşünüldüğünde gerçek maliyet bir saati rahatlıkla aşabilir.

Bu nedenle başarılı ekipler toplantı planlarken yalnızca takvimde boşluk olup olmadığına bakmaz. Aynı zamanda bu toplantının ekipte yaratacağı odak kaybını da hesaba katar.

High Performing Teams Yazılı İletişimi Tercih Eder

Düşük performanslı ekiplerde bilgi çoğunlukla konuşularak aktarılır.
Yüksek performanslı ekiplerde ise bilgi yazılır.
Bu iki yaklaşım arasındaki fark ilk bakışta küçük görünse de uzun vadede organizasyonun çalışma biçimini tamamen değiştirir.
Yeni bir özellik geliştirileceğini düşünelim.

Bir ekipte süreç şu şekilde ilerleyebilir:
Önce bir refinement toplantısı yapılır. Ardından teknik tasarım toplantısı planlanır. Birkaç gün sonra Product Manager yeni bir değişiklik ister ve herkes tekrar bir araya gelir. Sonuçta herkes toplantılara katılmıştır ama yine de gereksinimler konusunda farklı yorumlara sahiptir.

Diğer ekipte ise Product Manager önce kısa bir doküman hazırlar. Problem tanımı, hedef kullanıcı, acceptance criteria ve kapsam net şekilde yazılır. Teknik ekip gerekiyorsa bunun üzerine birkaç sayfalık teknik tasarım dokümanı ekler. Herkes toplantıdan önce bu dokümanları okur.

Toplantı başladığında artık ilk otuz dakika bilgi aktarmak yerine doğrudan karar vermeye ayrılır.

İşte yüksek performanslı ekiplerin en önemli alışkanlıklarından biri budur.
Toplantılar bilgi paylaşmak için değil, karar almak için yapılır.

Asenkron Çalışma Kültürü Verimliliği Artırır

Her sorunun cevabı senkron iletişim değildir.
Bugün kullandığımız araçlar aslında birçok toplantıyı gereksiz hale getirecek kadar gelişmiş durumda.
Bir teknik karar Architecture Decision Record (ADR) olarak yazılabilir.
Bir gereksinim değişikliği Jira üzerinden detaylandırılabilir.
Kodla ilgili tartışmalar Pull Request üzerinde yürütülebilir.
Tasarım önerileri Confluence veya Notion üzerinde yorumlanabilir.
Bütün bunlar insanların aynı anda aynı yerde bulunmasını gerektirmez.

Asenkron iletişimin en büyük avantajı, herkesin kendi çalışma ritmini koruyabilmesidir. Sabah erken saatlerde çalışan bir geliştirici ile öğleden sonra daha verimli çalışan başka bir geliştirici, aynı toplantıya katılmak zorunda kalmadan aynı probleme katkı sağlayabilir.

Bu yalnızca esneklik sağlamaz, aynı zamanda daha kaliteli düşünmeyi de teşvik eder. Çünkü insanlar anlık cevap vermek yerine düşünerek yorum yapabilir.

Güven Seviyesi Arttıkça Toplantılar Azalır

Organizasyonlarda toplantı sayısını belirleyen en önemli faktörlerden biri güven seviyesidir.

Eğer ekip üyelerine güvenilmiyorsa, herkes her karardan haberdar olmak ister.
Manager her teknik kararı görmek ister.
Tech Lead her Pull Request’e dahil olmak ister.
Product Manager her implementasyon detayını takip etmek ister.
Sonuç olarak insanlar iş üretmek yerine birbirlerini beklemeye başlar.
Oysa yüksek performanslı ekiplerde sorumluluk alanları nettir.
Backend ekibi API tasarımını yönetir.
Frontend ekibi kullanıcı deneyimiyle ilgili kararları alır.
Platform ekibi altyapı standartlarını belirler.
Elbette gerektiğinde fikir alışverişi yapılır. Ancak her kararın herkes tarafından verilmesi beklenmez.
Yetkinin net olduğu yerde toplantıya duyulan ihtiyaç doğal olarak azalır.

Belirsizlik Ne Kadar Fazlaysa Toplantı Sayısı da O Kadar Artar

Birçok ekipte toplantılar aslında karar almak için değil, belirsizliği yönetmek için yapılır.

Örneğin bir geliştirme başladıktan sonra Product tarafı sürekli yeni gereksinimler ekliyorsa ekip tekrar tekrar bir araya gelmek zorunda kalır.

Benzer şekilde teknik mimari konusunda ortak standartlar oluşturulmamışsa her yeni servis için yeniden tartışma yapılır.

REST mi kullanalım?
GraphQL mi?
Event Driven mı ilerleyelim?
Caching ekleyelim mi?
Bu tartışmaların kendisi problem değildir.
Problem, aynı tartışmanın her projede yeniden yapılıyor olmasıdır.

Başarılı ekipler tekrar eden kararları standartlaştırır. Böylece ekip enerjisini daha değerli problemlere ayırabilir.

Context Switching Verimliliğin Sessiz Düşmanıdır

Yazılım geliştirmede en değerli kaynak zaman değildir, odaklanmadır.

Bir geliştirici karmaşık bir algoritma üzerinde çalışırken gelen tek bir toplantı daveti bile bütün düşünce zincirini koparabilir. Toplantı sona erdiğinde IDE hâlâ açıktır ancak zihinsel bağlam kaybolmuştur.

Bu nedenle birçok teknoloji şirketi artık geliştiricilerin takvimlerinde “meeting free blocks” oluşturmaya başladı.
Örneğin sabah 09.00 ile 12.00 arasında hiçbir toplantı planlanmıyor.
Bunun nedeni geliştiricilerin daha az çalışması değil, tam tersine en verimli oldukları zaman dilimini koruyabilmeleridir.

Derin odaklanma gerektiren işler parçalanmaya başladığında üretkenlik doğrusal değil, katlanarak düşer.

Az Toplantı Daha Az İletişim Anlamına Gelmez

Bu konu en sık yapılan yanlış yorumlardan biridir.
Toplantı sayısının azalması iletişimin azalması anlamına gelmez.
Tam tersine iletişimin kalitesinin arttığı anlamına gelir.
Kararlar yazılı hale getirilir.
Dokümantasyon güncel tutulur.
Release notları hazırlanır.
Mimari değişiklikler kayıt altına alınır.
Yeni gelen ekip üyeleri geçmiş toplantıları dinlemek yerine yazılı bilgiye ulaşabilir.

Bilginin kurumsallaşması, yüksek performanslı ekiplerin en önemli özelliklerinden biridir.

Hangi Toplantılar Gerçekten Değerlidir?

Buraya kadar toplantıların zararlarından bahsettik. Ancak bu, bütün toplantıların gereksiz olduğu anlamına gelmiyor.

Bazı toplantılar ekip için oldukça yüksek değer üretir.
Sprint Planning, ekibin ortak hedefini belirlediği için önemlidir.
Retrospective, yalnızca ürünün değil sürecin de sürekli iyileştirilmesini sağlar.
Incident Review toplantıları aynı hataların tekrar yaşanmaması için kritik bilgiler üretir.
One-on-One görüşmeleri ise teknik konuların ötesinde çalışan gelişimi, motivasyonu ve kariyer planlaması açısından vazgeçilmezdir.
Bu toplantıların ortak özelliği, yapılmadığında organizasyonun gerçekten bir şey kaybetmesidir.

Diğer tarafta yalnızca bilgi paylaşımı amacıyla düzenlenen ve sonunda hiçbir karar alınmayan toplantılar ise çoğu zaman yeniden değerlendirilmelidir.

Yeni Bir Toplantı Planlamadan Önce Sorulabilecek Beş Soru

Takvime yeni bir toplantı eklemeden önce ekip olarak şu soruları sormayı alışkanlık haline getirebilirsiniz.

Bu konu yazılı olarak çözülebilir mi?
Toplantının sonunda alınacak net bir karar var mı?
Karar verecek kişiler gerçekten toplantıda olacak mı?
Toplantı yapılmazsa ortaya çıkacak risk nedir?
Katılımcı sayısını azaltabilir miyiz?

Bu sorular basit görünse de birçok gereksiz toplantının daha başlamadan iptal edilmesini sağlayabilir.

Sonuç

Yüksek performanslı ekipler daha az toplantı yapar çünkü daha az iletişim kurdukları için değil, iletişimi daha sistematik yönettikleri için.

Yazılı dokümantasyon güçlüdür. Karar mekanizmaları nettir. İnsanlar birbirlerinin uzmanlığına güvenir. Gereksiz senkronizasyon yerine asenkron çalışma kültürü benimsenmiştir. Toplantılar bilgi aktarmanın değil, karar vermenin aracıdır.

Takvimi tamamen boş bir ekip elbette başarılı olacak diye bir kural yoktur. Aynı şekilde günün tamamını toplantılarla geçiren bir ekip de mutlaka başarısız değildir. Ancak sürekli toplantıya ihtiyaç duyan organizasyonlar çoğu zaman daha derindeki süreç problemlerini toplantılarla telafi etmeye çalışırlar.

Belki de ekiplerin kendilerine sorması gereken en önemli soru şudur:

“Bu toplantıyı gerçekten yapmak zorunda mıyız, yoksa süreçlerimizdeki bir eksikliği toplantıyla kapatmaya mı çalışıyoruz?”

Çünkü yüksek performansın sırrı daha fazla konuşmakta değil, doğru bilgiyi doğru kişiye, doğru zamanda ve mümkün olduğunca kalıcı bir şekilde ulaştırabilmektedir.