Ölçeklenemeyecek Kadar Büyük – Optimal Scrum Takım Boyutu Kılavuzu

Bu makalenin sesli sürümünü dinleyin

İster küçük bir startupta, ister büyük bir şirkette yeni bir ürün üzerinde çalışıyor olun, bir ekipte çok fazla insanın olduğu bir noktaya gelmeniz muhtemeldir. İşaretleri erken tespit etmek sizi ekibin en verimsiz aşamasına gelmekten kurtaracaktır.

Her ürün farklıdır ve üzerinde çalışan ekipler de öyle. Bu nedenle, bir ekibi bölmek, koşullarınızı yansıtan bazı kararlar vermenizi de gerektirecektir. Dikkate alınması gereken bazı şeyler şunlardır:

• Takım arkadaşları artık birlikte çalışmadığında teknik bilgi bütünlüğü nasıl korunur
• İşlevler arasında mı bölünmelisiniz (örneğin, ön uç ve arka uç ekipleri)?
• Yeni ekiplerin ayrı birikimleri olmalı mı?
• Ürün yönetimi ekibi buna göre büyümeli mi?

İkinci Takım Oluşturmaya Ne Zaman Başlamalısınız?

Bir takım bölünmesi veya yeni bir takım ekleme hakkında düşünmeye başlamanın en bariz göstergesi, bütçenizin arttığı zamandır. Bu, bir girişimde yeni bir yatırım turunda veya bir kuruluştaki ürününüz için yeni hedeflerde ortaya çıkabilir. Bütçe artışı, ekibinizin 3 kat veya daha fazla büyümesini sağlayacak kadar önemliyse, bilgi birikimini dağıtmak için mevcut ekibinizi bölmek zorunda kalmanız hiç de kolay değil. Ancak, bütçe artışı artımlı olduğunda ve kadroya birkaç yeni kişi eklediğinizde kararlar o kadar net olmaz. Diyelim ki, ekibinizi 7 kişiden 11 kişiye çıkarma planlarınız varsa, bunun için bir bölünme gerekiyor mu? Çevik, küçük ekipleri teşvik eder, ancak aynı zamanda süreçler ve araçlar üzerinde bireyleri ve etkileşimleri teşvik eder. İki veya daha fazla takıma sahip olmak, kaçınılmaz olarak senkronize çalışabilmek için daha fazla süreç yaratır.

Uzmanlar ne diyor?

Amazon'un kurucusu Jeff Bezos, hem toplantılar hem de ekipler için iki pizza kuralını kullanıyor. Bu, her birinin öğle yemeğinde iki pizzanın besleyebileceği kadar kişiye sahip olması gerektiği anlamına gelir.

Scrum Kılavuzu, sprint biriktirme listesini fiilen yürüten üç ila dokuz takım üyesinin olmasını önerir. Bu, her ikisi de sprint biriktirme listesi öğelerini uygulamadıkça, ürün sahibini veya scrum master'ı toplama dahil etmeyeceğiniz anlamına gelir.

Bu sayılar sezgisel bir anlam ifade ediyor gibi görünüyor, ancak bunun arkasında bir miktar matematik de var. Bir takım hakkında düşünürseniz, her insan bir düğüm gibidir ve diğer düğümlere bağlanır. Bunlar takım arkadaşları arasındaki kişilerarası ilişkilerdir. Arkadaş canlısı, rekabetçi, kinci veya sevecen olabilirler. İki insan arasındaki ilişki ne olursa olsun, yine de her kişiden bir miktar zihinsel kapasite gerektiren bir bağlantıdır. Bir ekip büyüdükçe, bu bağlantıların bu sayıları doğrusal olarak büyümez. Düğümler arasındaki bağlantılar için formül \(n(n-1)/2\) şeklindedir. İşte bağlantı büyüme tablosu:

Grafik, ekiplerin neden çok büyük olmadıklarında en verimli şekilde çalıştıklarını matematiksel açıdan açıkça göstermektedir. Scrum Kılavuzu tarafından önerilen 3 ila 9 takım üyesini alırsak, 3 ila 36 bağlantı ile sonuçlanırız. 15 kişiye büyüseydik, 100'den fazla bağlantımız olurdu. Böyle bir ekip, ancak görevleri çok iyi tanımlanmışsa ve nadiren çakışıyorsa veya bazı resmi olmayan alt gruplar varsa verimli çalışabilir. Çevik ilkelere dayalı olarak çalışırken durum böyle değildir veya arzu edilmez.

Takımın Çok Büyüdüğünün İşaretleri

Günlük Scrum

Bazen günlük standup olarak adlandırılan günlük saldırı, tüm ekibin sprintin ilerlemesini ve engellerini tartışmak için bir araya gelmesidir. Scrum Kılavuzu, bunları 15 dakika olarak ayarlamanızı önerir ve bu, takım büyüklüğü için iyi bir turnusol testidir. Takımınızın 15 dakikalık süreyi aştığını fark etmeye başlarsanız, bu iki şeyden birini gösterebilir:

• Günlük krizler verimli değil. İnsanlar çok fazla ayrıntıya giriyor. Veya net bir konuşma sırası yoktur ve takım arkadaşlarının konuşması zaman alır. Belki ürün sahibi veya scrum master, sprint ile ilgili olmayan çeşitli güncellemeler sağlamak için günlük scrum'u bir fırsat olarak kullanıyordur.
• Takım çok büyük. Günlük krizler verimliyse, ancak hala 15 dakikayı geçiyorsanız, o zaman takımda çok fazla insan olabilir. Ayrıca, bir kişinin alabileceği bilginin bir sınırı olduğu için insanların ilgisini kaybettiğini fark etmeye başlamalısınız. Çok fazla kişi güncelleme sağlıyorsa, herkesin ilerlemesini takip etmek ve ekibin durumunu anlamak zorlaşır. . Bu, insanların başkalarına yardım etme fırsatlarını aramak yerine içe dönmelerini ve yalnızca ilerlemeleri üzerinde düşünmelerini sağlar.

Bakım ve Sprint Planlama

Hem bakım hem de sprint planlaması, kullanıcı hikayelerini parçalamak ve teslimat sürelerini veya boyutlarını tahmin etmekle ilgili faaliyetlerdir. Daha fazla kişiye sahip olmak ekibin daha iyi kararlar almasına yardımcı olurken, çok fazla kişiye sahip olmak ekibi çıkmaza sokabilir. Aynı görevi gerçekleştirmenin her zaman farklı yolları vardır ve her iki taraftaki argümanların sayısı ekipteki kişi sayısıyla birlikte artar.

Günlük saldırıda olduğu gibi, verimsiz bir planlama oturumunu ekibin çok büyük olmasıyla karıştırmayın. Sonuç olarak, scrum törenlerinin verimli ve etkili olmasını sağlamak scrum ustasının işidir.

retrospektif

Geriye dönük bir inceleme sırasında, ekip üyeleri herhangi bir tartışmayı veya çatışmayı çözebilir ve çalışma süreçlerini iyileştirmenin yollarını bulabilir. Retrospektifler, farklı taraflar arasında ortak bir zemin aramamızı sağladığı için bize uzlaşma sanatını öğretir. Bir ekip, üyelerinin farklılıklarından taviz vermeye istekli olduğu kadar güçlüdür.

Ancak, sprint planlamasında olduğu gibi, çok fazla ekip üyesi çok fazla bağlantı oluşturur ve bunların tümü potansiyel çatışma noktalarıdır. Retrospektifler sırasında daha az ortak nokta bulup bulmadığınızı fark etmeye başlayın. Takımın çok büyük olduğunun ve bölünmenin fayda sağlayacağının bir işareti olabilir.

Takım Nasıl Bölünür

Görünüşte, ekibi bölmek nispeten kolay bir iştir. Ekip üyelerini iki gruba ayırın, her birinin benzer deneyimli kişilere sahip olduğundan emin olun ve yeni ekiplerin hedeflerini tanımlayın. Ancak, yeni ekiplerin gelecekteki başarısı üzerinde büyük etkisi olabilecek dikkate alınması gereken birkaç şey var.

Takım Morali

Muhtemelen akılda tutulması gereken en önemli şeylerden biri takım moralidir. Günün sonunda, yeni kompozisyonda çalışması gereken ekipteki insanlar. Takım Çevik ilkeler açısından olgunsa, o zaman bölünmeyi kendileri yapabilmelidir. Bu en çok arzu edilen sonuçtur çünkü ekip üyeleri kendi iç ilişkilerini en iyi bilirler - kim kiminle en iyi çalışır ve kim ayrı ekiplerde olmaktan kim yararlanabilir.

İşlevler Arası Ekipler

Scrum, "bir ürün parçası oluşturmak için gerekli tüm becerilere sahip bir ekip olarak" çapraz işlevli ekipleri teşvik eder. Bu, iki veya daha fazla takıma ölçeklenirken geçerlidir. Pek çok geliştirici için, özellikle de Agile konusunda yenilerse, doğal eğilim teknik hatların yanında düşünmektir. Örneğin, ekipler genellikle arka uç ve ön uç ekipler olarak ayrılmak ister. Bu, bazı nadir durumlarda mantıklı olabilir, ancak bir ürün yöneticisi olarak çoğu zaman buna karşı tavsiyede bulunmalısınız. Ön uçlarla dolu bir ekip, kendi başına bir ürün artışı sağlayamaz ve doğal olarak, onları birleştiren teknik kapasite hakkında daha fazla düşünmeye başlar. Bunun yerine, müşteriye ve ihtiyaçlarının nasıl karşılanacağına odaklanmalıdırlar.

Bir başka ilginç düşünce, takımdaki gelişim dışı rollerdir. Çeşitli durumlarda, bir ekip bir tasarımcı, iş analisti veya bir QA uzmanı içerebilir. Bir ekibi böldüğünüzde, özellikle çok fazla yeni insanı işe almıyorsanız, bu rollerle ne yapılacağı konusunda bir ikilem ortaya çıkar. Zamanlarını takımlar arasında mı bölmeliler? Yalnızca bir takıma atanacak yeni insanları işe almalı mısınız? Geliştirme ekipleriyle mi çalışmalılar yoksa ürün ekibinin bir parçası mı olmalılar?

Bunun için gerçekten tek bir iyi tavsiye yok çünkü her ürün çok farklı. Bu kararlar en iyi şekilde ekiple birlikte verilir ve yol boyunca rotayı düzeltmeniz gerekebileceğini unutmayın.

Takımların Ayrı Birikmeleri Olmalı mı?

Bir ekip bölünürse, doğal soru, aynı biriktirme listesi üzerinde mi çalışmalı yoksa ayrı ekiplere mi sahip olmaları gerektiğidir. Rehberlik için Ölçekli Çevik Çerçeveye bakabiliriz.

Scrum@Ölçek

Scrum@Scale, Scrum Kılavuzunun yaratıcısı tarafından geliştirilmiş bir metodolojidir. Scrum@Scale çok kuralcı değildir ve ürün biriktirme listelerinin nasıl ele alınacağını özellikle belirtmez. Ancak iki noktaya dikkat çekiyor:

• Takım düzeyindeki süreç, Scrum Kılavuzunda belirtilenle aynıdır.
• Ürün sahipleri, tek bir birleşik biriktirme listesi oluşturdukları bir ürün sahibi ekibi oluşturur. Bu, işin tekrarını önlemek ve şirket içinde görünürlük yaratmak için yapılır. Aynı zamanda, ekiplerin birleşik biriktirme listesinden öğeleri besleyen ayrı biriktirme listeleri vardır.

Yani özünde, Scrum@Scale yeni ekipleri kendi PO'ları ve biriktirme listeleriyle birlikte görüntüler. Sadece ekipler arasındaki işi koordine etmek için bazı ek yapılar ekler. Scrum@Scale birkaç, onlarca veya yüzlerce ekiple en iyi şekilde çalışır ancak iki ekiple çalışıyor olsanız bile bazı değerli bilgiler sağlayabilir.

Büyük Ölçekli Scrum (LeSS)

LeSS, ürün birikimine ilginç bir yaklaşımı teşvik eder. LeSS'de bir ürün sahibi iki ila sekiz ekiple çalışır. Bir PO'nun bu kadar çok ekiple çalışması imkansız görünebilir. LeSS felsefesi, PO'nun soyut bir düzeyde çalışması ve ürün biriktirme listesi kalemi iyileştirme sorumluluklarını ekiplere devretmesidir. Bu durumda, işlevler arası geliştirme ekipleri, bir ürün artışı sunabilmek için iş alanı bilgisini de içermelidir. LeSS'de yalnızca bir biriktirme listesi vardır.

Nasıl Güncel Tutulur?

Bir ürün yöneticisi için birden fazla ekip, ilerlemeyi izlemek ve sorguları yanıtlamak için daha fazla iş anlamına gelir.

Toplantılara Öncelik Verin

Tek bir takımın günlük scrumlarına katılıyorsanız, bu alışkanlığı sürdürmek büyük olasılıkla verimsiz olacaktır. Takımların nabzını tutmak ve onlara tartışmalara hazır olduğunuzu hatırlatmak için günlük kavgaları bir şans olarak düşünün.

Sprint planlama oturumlarına katılımınız ekiplerin olgunluğuna bağlı olacaktır. Ekipler çok sayıda yeni yüz içeriyorsa veya Agile ile uzun süredir çalışmıyorlarsa, sizin tarafınızdan biraz rehberlik gerekli olacaktır. Ekibin katılımınız olmadan plan yapmasına izin vermekten emin olsanız bile, herhangi bir sorunuz olursa, planlama sırasında ekiple görüşmeye veya sesli sohbet etmeye hazır olduğunuzdan emin olun.

Sprint incelemeleri en büyük önceliğiniz olarak kalmalı ve hepsine katılmanız gerekir. Sprint incelemeleri, mevcut paydaşlardan ve ekibin kendisinden ilk elden geri bildirim alma şansıdır. Bu, varsayımların doğrulandığı ve kaçırılmaması gereken bir zamandır.

Scrum Masters ile Daha Fazla Katılım Sağlayın

Bazı scrum törenleriyle olan ilişkinizi azaltıyor olsanız da, scrum master ile olan ortaklığınızı ikiye katlamalısınız. Takım bölündükten sonra birden fazla kişi olabilir, bu durumda hepsiyle yakın çalışmanız gerekir.

Takımın ilerlemesi ve sprintler sırasında ortaya çıkan sorunlar hakkında dürüst bir görüş vermeleri için onlara güvenebileceğinizden emin olun. Bu ilişkiler, tüm scrum törenlerine katılmanıza gerek kalmadan güncel kalmanıza izin verecektir.

Scrum of Scrum'ı Tanıtın

Bazen meta scrum olarak adlandırılan bir scrum of scrum, tipik olarak scrum süreçleri ölçeği olarak tanıtılan yeni bir törendir. Daha yüksek bir seviyedeki günlük hücumun bir kopyasıdır. Her takım, ilerlemeyi ve engelleri tartışmak için her gün bir araya gelen bir elçi belirler. Bu tören aynı zamanda çözülmesi gerekebilecek takımlar arası teknik sorunları vurgulamak için de kullanılır.

Ürün Ekibini Genişletmeyi Düşünün

Scrum kurulumunuz, ürün yöneticisinin ekiple aktif olarak etkileşime girmesini gerektiriyorsa, ürün tarafına daha fazla insan eklemeyi düşünün. Buna yaklaşmanın birkaç yolu var.

Genç ürün yöneticileri. Bir yol, günlük işlerin bazılarını halletmek için genç ürün yöneticileri eklerken kendiniz için daha stratejik bir rol üstlenmektir. Kalite güvencesi (QA), kullanıcı hikayeleri için spesifikasyonlar yazmak veya yeni özellikler için üst düzey örnekler oluşturmak gibi bazı görevleri üstlenebilirler.

İş analistleri. Başka bir yol, bir veya daha fazla iş analistinin ekiplerde veya ekiplerle birlikte çalışmasını sağlamaktır. Ürün yöneticisi, ürün varsayımlarını belirlemek için iş analistleriyle birlikte çalışabilir ve ardından iş analistlerinin araştırma veya yeni özellikler yoluyla bunları doğrulamanın yollarını bulmasına izin verebilir.

Çözüm

Ekibiniz büyüdükçe, özellikle şu durumlarda çok büyüdüğüne dair bazı işaretler fark etmeye başlayacaksınız:

• Günlük koşuşturma. Günlük krizler sırasında 15 dakikalık zaman dilimini aşıyorsanız ve insanların ilgisini kaybetmeye başladığını görüyorsanız.
• Sprint planlaması. Sprint planlaması sırasında daha sık çıkmaza girerseniz.
• Retrospektif. Retrospektifler sırasında uzlaşmaya varmanın zorlaştığını fark etmeye başlarsanız.

Tüm bunlar, ekibi bölmeniz gerekebileceği gerçeğine işaret ediyor. Bir ekibi bölmek görünüşte kolay bir iştir, ancak bunun kalıcı sonuçları da vardır ve her ürün yöneticisinin bunu yaparken dikkate alması gereken birkaç şey vardır:

• Takım morali. İdeal olarak, hurdaya ayrılan iyi çalışma ilişkilerinin sayısını en aza indirmek için ekibin nasıl ayrılmak istediğine karar vermesine izin vermelisiniz.
• Çapraz fonksiyonlu ekipler. Ekipler, bir ürün parçası oluşturmak için gerekli tüm becerilere sahip olmalıdır.
• Ürün birikimi. Ekiplerinizin ayrı mı yoksa tek bir birleşik biriktirme listesi mi olacağına karar verin.

İki veya daha fazla takımı takip etmek, öncelik vermenizi gerektirecektir. Etkili bir ürün yöneticisi, yeni ekiplerle nasıl güncel kalacaklarını planlamalıdır:

• Toplantılara öncelik verin. Hangi Çevik törenlerin zaman ayırmaya değer olduğunu ve hangilerinin göz ardı edilebileceğini düşünün.
• Scrum ustalarıyla etkileşim kurun. Ekibinizin proxy'leri olarak scrum master'ları kullanın ve onlardan bilgi toplayın.
• Ürün ekibini genişletin. Sizinle çalışacak ve günlük tekrarlanan görevlerde yardımcı olacak veya kullanıcı araştırması ve pazar analizi yapacak kişileri ekleyin.

Bu önerileri kullanarak, temiz bir ekip bölünmesine sahip olabilirsiniz. Ekipleriniz büyümeye devam ediyorsa ve gelecekte daha fazla ekip ekleyecekseniz, Agile için geniş ölçekte yapı ve süreç önerileri sağlayan Scaled Agile Framework hakkında bilgi edinmelisiniz.