Terlalu Besar untuk Diskalakan – Panduan Ukuran Tim Scrum yang Optimal

Dengarkan versi audio dari artikel ini

Baik Anda bekerja di perusahaan rintisan kecil atau pada produk baru di perusahaan besar, kemungkinan besar Anda akan sampai pada titik ketika Anda memiliki terlalu banyak orang dalam satu tim. Mengidentifikasi tanda-tanda sejak dini akan menyelamatkan Anda dari mencapai tahap tim yang paling tidak efisien.

Setiap produk berbeda dan begitu pula tim yang mengerjakannya. Dengan demikian, membagi tim juga akan mengharuskan Anda membuat beberapa keputusan yang mencerminkan keadaan Anda. Beberapa hal yang perlu dipertimbangkan adalah:

• Bagaimana menjaga integritas pengetahuan ketika rekan tim tidak lagi bekerja sama
• Haruskah Anda membagi fungsi (misalnya, tim front-end dan back-end)?
• Haruskah tim baru memiliki backlog terpisah?
• Haruskah tim manajemen produk tumbuh sesuai dengan itu?

Kapan Anda Harus Mulai Membuat Tim Kedua?

Indikasi paling jelas untuk mulai memikirkan pembagian tim atau menambahkan tim baru adalah ketika anggaran Anda meningkat. Ini mungkin terjadi pada putaran investasi baru di startup atau tujuan baru untuk produk Anda di perusahaan. Jika peningkatan anggaran sangat besar sehingga tim Anda akan tumbuh 3x atau lebih, maka Anda harus membagi tim Anda saat ini untuk mendistribusikan pengetahuan. Namun, keputusan menjadi tidak begitu jelas ketika peningkatan anggaran meningkat dan Anda akhirnya menambahkan beberapa orang baru ke dalam daftar. Jika, katakanlah, Anda memiliki rencana untuk mengembangkan tim Anda dari 7 menjadi 11 orang, apakah itu memerlukan perpecahan? Agile mempromosikan tim kecil tetapi juga mempromosikan individu dan interaksi melalui proses dan alat. Memiliki dua atau lebih tim pasti menciptakan lebih banyak proses untuk dapat bekerja secara sinkron.

Apa Kata Para Ahli?

Jeff Bezos, pendiri Amazon, telah menggunakan aturan dua pizza untuk rapat dan tim. Itu berarti bahwa masing-masing hanya boleh memiliki orang sebanyak dua pizza yang bisa diberi makan saat makan siang.

Panduan Scrum menyarankan untuk memiliki antara tiga dan sembilan anggota tim yang benar-benar menjalankan sprint backlog. Itu berarti Anda tidak akan menyertakan pemilik produk atau master scrum secara total kecuali salah satu dari mereka menerapkan item sprint backlog.

Angka-angka ini tampaknya masuk akal secara intuitif tetapi ada juga beberapa matematika di baliknya. Jika Anda berpikir tentang tim, setiap orang seperti simpul dan mereka terhubung ke simpul lain. Ini adalah hubungan interpersonal antara rekan satu tim. Mereka bisa ramah, kompetitif, dengki, atau peduli. Apa pun hubungan antara dua orang, itu tetap merupakan tautan yang membutuhkan beberapa kapasitas mental dari setiap orang. Seiring pertumbuhan tim, jumlah tautan ini tidak bertambah secara linier. Rumus untuk link antar node adalah \(n(n-1)/2\). Berikut adalah grafik pertumbuhan tautan:

Bagan tersebut dengan jelas menggambarkan dari sudut pandang matematis mengapa tim beroperasi paling efisien ketika mereka tidak terlalu besar. Jika kami mengambil 3 hingga 9 anggota tim yang disarankan oleh Panduan Scrum, kami akan mendapatkan antara 3 dan 36 tautan. Jika kami berkembang menjadi 15 orang, kami akan memiliki lebih dari 100 tautan. Sebuah tim ini hanya dapat beroperasi secara efisien jika tugas mereka didefinisikan dengan sangat baik dan jarang tumpang tindih atau jika ada beberapa sub-kelompok tidak resmi. Tidak demikian halnya atau diinginkan ketika bekerja berdasarkan prinsip Agile.

Tanda-tanda Tim Menjadi Terlalu Besar

Scrum Harian

Kadang-kadang disebut sebagai standup harian, scrum harian adalah pertemuan seluruh tim untuk membahas kemajuan dan hambatan sprint. Panduan Scrum menyarankan untuk mengatur waktu ini pada 15 menit dan itu adalah tes lakmus yang baik untuk ukuran tim. Jika Anda mulai memperhatikan bahwa tim Anda melampaui batas 15 menit, maka itu dapat menunjukkan salah satu dari dua hal:

• Scrum harian tidak efisien. Orang-orang masuk ke terlalu banyak detail. Atau tidak ada urutan berbicara yang jelas dan butuh waktu bagi rekan satu tim untuk angkat bicara. Mungkin pemilik produk atau scrum master menggunakan scrum harian sebagai kesempatan untuk memberikan berbagai pembaruan yang tidak terkait dengan sprint.
• Tim ini terlalu besar. Jika scrum harian efisien, tetapi Anda masih melebihi 15 menit, maka Anda mungkin memiliki terlalu banyak orang dalam tim. Anda juga harus mulai memperhatikan bahwa orang-orang kehilangan minat karena ada batasan seberapa banyak informasi yang dapat diterima seseorang. Jika terlalu banyak orang yang memberikan pembaruan, menjadi sulit untuk melacak kemajuan setiap orang dan memahami status tim . Hal ini membuat orang berbalik ke dalam dan hanya merenungkan kemajuan mereka daripada mencari peluang untuk membantu orang lain.

Grooming dan Perencanaan Sprint

Baik perawatan dan perencanaan sprint adalah aktivitas yang terkait dengan memecah cerita pengguna dan memperkirakan waktu atau ukuran pengiriman mereka. Meskipun memiliki lebih banyak orang dapat membantu tim mencapai keputusan yang lebih baik, memiliki terlalu banyak orang dapat membuat tim menemui jalan buntu. Selalu ada cara berbeda untuk menyelesaikan tugas yang sama dan jumlah argumen di setiap sisi meningkat seiring dengan jumlah orang dalam tim.

Seperti halnya scrum harian, jangan bingung dengan sesi perencanaan yang tidak efisien dengan tim yang terlalu besar. Pada akhirnya, tugas master scrum adalah membuat upacara scrum menjadi efisien dan efektif.

Retrospektif

Selama retrospektif, anggota tim dapat menyelesaikan argumen atau konflik apa pun dan menemukan cara untuk meningkatkan proses kerja mereka. Retrospektif mengajari kita seni kompromi karena membuat kita mencari titik temu di antara berbagai pihak. Sebuah tim sama kuatnya dengan anggotanya yang mau berkompromi atas perbedaan mereka.

Namun, seperti halnya perencanaan sprint, terlalu banyak anggota tim membuat terlalu banyak tautan, yang semuanya merupakan titik potensial konflik. Mulailah memperhatikan jika Anda menemukan kesamaan yang semakin berkurang selama retrospektif. Ini mungkin pertanda bahwa tim terlalu besar dan akan mendapat manfaat dari perpecahan.

Cara Membagi Tim

Sekilas, membagi tim adalah tugas yang relatif mudah. Bagilah anggota tim menjadi dua kelompok, pastikan masing-masing memiliki orang yang sama-sama berpengalaman, dan tentukan tujuan tim baru. Namun, ada beberapa hal yang perlu dipertimbangkan yang dapat berdampak besar pada kesuksesan tim baru di masa depan.

Semangat Tim

Mungkin salah satu hal terpenting yang perlu diingat adalah moral tim. Pada akhirnya, orang-orang dalam timlah yang harus bekerja dalam komposisi baru. Jika tim sudah matang dalam hal prinsip Agile, maka mereka harus bisa membuat perpecahan sendiri. Ini adalah hasil yang paling diinginkan karena anggota tim paling mengetahui hubungan internal mereka—siapa yang bekerja paling baik dengan siapa dan siapa yang dapat memperoleh manfaat dari berada dalam tim yang terpisah.

Tim lintas fungsi

Scrum mempromosikan tim lintas fungsi “dengan semua keterampilan sebagai tim yang diperlukan untuk menciptakan peningkatan produk.” Ini berlaku saat menskalakan ke dua atau lebih tim. Bagi banyak pengembang, terutama jika mereka baru mengenal Agile, kecenderungan alaminya adalah berpikir di samping garis teknis. Misalnya, tim sering ingin dibagi menjadi tim back-end dan front-end. Ini mungkin masuk akal dalam beberapa kesempatan yang jarang terjadi, tetapi sebagai manajer produk, Anda harus sering kali menyarankan untuk tidak melakukannya. Sebuah tim yang penuh dengan front-ender tidak dapat memberikan peningkatan produk sendiri dan secara alami akan mulai lebih memikirkan kapasitas teknis, yang menyatukan mereka. Sebaliknya, mereka harus berfokus pada pelanggan dan bagaimana memenuhi kebutuhan mereka.

Pertimbangan lain yang menarik adalah peran non-pengembangan dalam tim. Dalam berbagai situasi, tim mungkin termasuk desainer, analis bisnis, atau spesialis QA. Setelah Anda membagi tim, terutama jika Anda tidak mempekerjakan terlalu banyak orang baru, muncul dilema mengenai apa yang harus dilakukan dengan peran ini. Haruskah mereka membagi waktu mereka di antara tim? Jika Anda mempekerjakan orang baru, siapa yang akan didedikasikan untuk satu tim saja? Haruskah mereka bekerja dengan tim pengembangan atau menjadi bagian dari tim produk?

Benar-benar tidak ada saran tunggal yang baik untuk ini karena setiap produk sangat berbeda. Keputusan ini paling baik dibuat bersama dengan tim, dengan mengingat bahwa Anda mungkin perlu mengoreksi arah di sepanjang jalan.

Haruskah Tim Memiliki Backlogs Terpisah?

Jika sebuah tim terpecah, maka pertanyaan alaminya adalah apakah mereka harus mengerjakan backlog yang sama atau memiliki yang terpisah. Kita dapat melihat ke Scaled Agile Framework untuk panduan.

Scrum@Skala

Scrum@Scale adalah metodologi yang dikembangkan oleh pembuat Panduan Scrum. Scrum@Scale tidak terlalu menentukan dan tidak menjelaskan secara spesifik bagaimana menangani product backlog. Namun, ia mencatat dua poin:

• Proses di tingkat tim sama dengan yang dijelaskan di Panduan Scrum.
• Pemilik produk membentuk tim pemilik produk, di mana mereka membuat satu backlog terpadu. Hal ini dilakukan untuk menghindari duplikasi pekerjaan dan untuk menciptakan visibilitas dalam perusahaan. Pada saat yang sama, tim memiliki backlog terpisah yang memasukkan item dari backlog terpadu.

Jadi intinya, Scrum@Scale menggambarkan tim baru dengan PO dan backlog masing-masing. Itu hanya menambahkan beberapa struktur tambahan untuk mengoordinasikan pekerjaan di antara tim. Scrum@Scale bekerja paling baik dengan beberapa, puluhan, atau ratusan tim tetapi dapat memberikan beberapa wawasan berharga bahkan jika Anda bekerja dengan dua tim.

Scrum Skala Besar (LeSS)

LeSS mempromosikan pendekatan yang menarik untuk backlog produk. Di LeSS, seorang pemilik produk bekerja dengan dua hingga delapan tim. Tampaknya mustahil bagi satu PO untuk bekerja dengan begitu banyak tim. Filosofi KURANG adalah bahwa PO bekerja pada tingkat abstrak dan mendelegasikan tanggung jawab penyempurnaan item backlog produk kepada tim. Dalam hal ini, tim pengembangan lintas fungsi juga harus menyertakan pengetahuan domain bisnis agar dapat memberikan peningkatan produk. Di LeSS, hanya ada satu backlog.

Cara Tetap Terkini

Untuk manajer produk, banyak tim berarti lebih banyak pekerjaan yang melacak kemajuan dan menanggapi pertanyaan.

Prioritaskan Rapat

Jika Anda menghadiri scrum harian satu tim, melanjutkan kebiasaan ini kemungkinan besar tidak akan produktif. Pertimbangkan scrum harian sebagai kesempatan untuk mampir untuk mendapatkan denyut nadi tim dan mengingatkan mereka bahwa Anda tersedia untuk diskusi.

Kehadiran Anda dalam sesi perencanaan sprint akan tergantung pada kematangan tim. Jika tim memiliki banyak wajah baru atau mereka sudah lama tidak bekerja dengan Agile, maka beberapa panduan dari pihak Anda akan diperlukan. Bahkan jika Anda merasa percaya diri dalam membiarkan tim merencanakan tanpa kehadiran Anda, pastikan untuk tersedia untuk mampir atau mengobrol dengan tim selama perencanaan mereka jika ada pertanyaan yang muncul.

Ulasan sprint harus tetap menjadi prioritas utama Anda dan semuanya harus dihadiri. Ulasan sprint adalah kesempatan untuk mendapatkan umpan balik langsung dari pemangku kepentingan saat ini dan tim itu sendiri. Saatnya asumsi divalidasi dan tidak boleh dilewatkan.

Terlibat Lebih Banyak dengan Scrum Masters

Meskipun Anda mungkin mengurangi keterlibatan Anda dengan beberapa upacara scrum, Anda harus menggandakan kemitraan Anda dengan master scrum. Mungkin ada lebih dari satu sekarang setelah tim terpecah, dalam hal ini, Anda harus bekerja sama dengan mereka semua.

Pastikan Anda dapat mempercayai mereka untuk memberikan pandangan jujur ​​tentang kemajuan tim dan masalah apa pun yang muncul selama sprint. Hubungan ini akan membuat Anda tetap up to date tanpa perlu terlibat dalam semua upacara scrum.

Perkenalkan Scrum dari Scrum

Kadang-kadang disebut meta scrum, scrum scrum adalah upacara baru yang biasanya diperkenalkan sebagai skala proses scrum. Ini adalah replika dari scrum harian di tingkat yang lebih tinggi. Setiap tim menunjuk seorang duta besar, yang semuanya bertemu di scrum scrum setiap hari untuk membahas kemajuan dan hambatan. Upacara ini juga digunakan untuk menyoroti masalah teknis lintas tim yang mungkin perlu diselesaikan.

Pertimbangkan Memperluas Tim Produk

Jika pengaturan scrum Anda mengharuskan manajer produk untuk terlibat secara aktif dengan tim, pertimbangkan untuk menambahkan lebih banyak orang ke sisi produk. Ada beberapa cara untuk mendekati ini.

Manajer produk junior. Salah satu jalurnya adalah mengambil peran yang lebih strategis untuk diri Anda sendiri sambil menambahkan manajer produk junior untuk menangani beberapa tugas sehari-hari. Mereka dapat melakukan beberapa tugas seperti jaminan kualitas (QA), menulis spesifikasi untuk cerita pengguna, atau membuat maket tingkat tinggi untuk fitur baru.

Analis bisnis. Cara lain adalah meminta satu atau lebih analis bisnis bekerja di dalam atau di samping tim. Manajer produk dapat bekerja dengan analis bisnis untuk mengidentifikasi asumsi produk dan kemudian membiarkan analis bisnis menemukan cara untuk memvalidasinya baik melalui penelitian atau fitur baru.

Kesimpulan

Saat tim Anda tumbuh, Anda mungkin mulai memperhatikan beberapa tanda bahwa tim Anda menjadi terlalu besar, terutama di:

• Scrum harian. Jika Anda melampaui jangka waktu 15 menit selama scrum harian dan melihat bahwa orang-orang mulai kehilangan minat.
• Perencanaan lari cepat. Jika Anda berakhir di kebuntuan selama perencanaan sprint lebih dan lebih sering.
• Retrospektif. Jika Anda mulai memperhatikan bahwa semakin sulit untuk mencapai kompromi selama retrospektif.

Semua ini menunjukkan fakta bahwa Anda mungkin perlu membagi tim. Memisahkan tim tampaknya merupakan tugas yang mudah tetapi juga memiliki konsekuensi yang bertahan lama dan setiap manajer produk memiliki beberapa hal yang perlu dipertimbangkan saat melakukannya:

• Semangat tim. Idealnya, Anda harus membiarkan tim memutuskan bagaimana mereka ingin berpisah untuk meminimalkan jumlah hubungan kerja yang baik yang dibatalkan.
• Tim lintas fungsi. Tim harus memiliki semua keterampilan yang diperlukan untuk menciptakan peningkatan produk.
• jaminan produk. Putuskan apakah tim Anda akan memiliki backlog terpisah atau tunggal.

Melacak dua atau lebih tim akan mengharuskan Anda untuk memprioritaskan. Manajer produk yang efektif harus merencanakan bagaimana mereka akan mengikuti perkembangan tim baru:

• Prioritaskan pertemuan. Pikirkan upacara Agile mana yang sepadan dengan waktu Anda dan mana yang dapat diabaikan.
• Terlibat dengan master scrum. Gunakan scrum master sebagai proxy tim Anda dan kumpulkan informasi dari mereka.
• Perluas tim produk. Tambahkan orang untuk bekerja dengan Anda dan bantu dengan tugas berulang setiap hari atau lakukan riset pengguna dan analisis pasar.

Dengan memanfaatkan saran-saran ini, Anda harus dapat memiliki tim yang bersih. Jika tim Anda terus berkembang dan Anda akan menambahkan lebih banyak tim di masa mendatang, Anda harus membaca tentang Scaled Agile Framework, yang memberikan saran struktur dan proses untuk Agile dalam skala besar.