Nexus Framework: Menskalakan Scrum untuk 3 hingga 9 Tim

Oleh Tara Minh · Diperbarui 10 Oktober 2026

Nexus adalah framework dari Scrum.org untuk sekitar tiga hingga sembilan Scrum Team yang bekerja bersama pada satu produk. Nexus mempertahankan aturan Scrum dan hanya menambahkan yang diperlukan untuk mengelola dependensi: sebuah Nexus Integration Team, beberapa event tambahan, dan satu Integrated Increment bersama yang dikontribusikan setiap tim di setiap Sprint.

Sebagian besar masalah saat menskalakan bukan soal menulis kode lebih cepat. Masalahnya adalah dua tim menyentuh modul yang sama, tim ketiga menunggu keduanya, dan tidak ada yang menyadarinya hingga akhir Sprint. Nexus dibangun untuk menjawab masalah itu. Nexus tidak meminta Anda merombak struktur perusahaan. Nexus meminta Anda membuat dependensi terlihat sejak dini dan memberi seseorang tanggung jawab yang jelas atas integrasi.

Fakta Utama

• Nexus dikembangkan oleh Ken Schwaber dan Scrum.org, dan Nexus Guide telah terbit dalam edisi 2015, 2018, dan 2021.
• Nexus Guide terkini (Januari 2021) menggambarkan sebuah Nexus sebagai sekitar tiga hingga sembilan Scrum Team dengan satu Product Owner dan satu Product Backlog.
• Nexus Integration Team terdiri dari Product Owner, seorang Scrum Master, dan satu atau lebih Nexus Integration Team Member.
• Panduan ini tidak menetapkan timebox yang baku untuk event Nexus. Durasinya dipandu oleh event Scrum yang sepadan.
• Edisi 2021 mengganti nama Refinement menjadi Cross-Team Refinement.
• LeSS mencakup 2 hingga 8 tim, sehingga kedua framework ini banyak tumpang tindih dalam jumlah tim dan berbeda terutama pada seberapa besar perubahan organisasi yang diminta.

Apa itu Nexus framework?

Nexus adalah framework untuk mengembangkan dan menopang pengiriman produk berskala besar. Nexus memperluas Scrum secara minimal. Tim tetap menjalankan Sprint, memiliki satu Product Owner dan satu Product Backlog, serta tunduk pada nilai-nilai Scrum yang sama. Yang berubah adalah kelompok tersebut menghasilkan satu Integrated Increment, bukan beberapa increment yang hanya longgar kaitannya, dan sekelompok kecil orang memikul akuntabilitas untuk mewujudkan integrasi itu.

Kata "nexus" berarti titik hubung, dan framework ini sebagian besar tentang koneksi: antar-item backlog, antar-tim, dan antara pekerjaan yang dianggap Done oleh setiap tim dengan apa yang benar-benar dirilis bersama.

Tiga gagasan menopang sebagian besar bebannya:

• Satu produk, satu backlog. Semua tim mengambil dari Product Backlog yang sama, yang dimiliki oleh satu Product Owner.
• Dependensi adalah musuh aliran kerja. Uraikan dan hilangkan dependensi lewat refinement sebelum Sprint, lalu lacak yang tersisa.
• Integrasi terjadi di setiap Sprint. Nexus harus menghasilkan Increment yang berfungsi dan terintegrasi setidaknya sekali per Sprint, bukan di akhir fase rilis.

Peran Nexus: Nexus Integration Team

Nexus tidak menambah lapisan manajemen baru. Nexus menambah satu tim. Menurut Nexus Guide, Nexus Integration Team terdiri dari:

Kesalahpahaman yang umum adalah anggapan bahwa Integration Team yang melakukan integrasi. Bukan demikian. Setiap Scrum Team tetap mengerjakan integrasinya sendiri. Integration Team berkoordinasi, membimbing, dan menyingkirkan hambatan, serta bertanggung jawab agar Integrated Increment benar-benar ada dan memenuhi Definition of Done. Tim ini juga memegang Definition of Done bersama untuk Integrated Increment. Masing-masing tim boleh menerapkan standar yang lebih ketat, tetapi tidak boleh lebih longgar.

Keanggotaan dapat berganti seiring perubahan pekerjaan. Panduan menyatakan bahwa posisi seseorang di Integration Team diutamakan di atas keanggotaannya di tim selama tanggung jawab Integration Team terpenuhi, yang secara halus berarti peran tersebut didahulukan ketika keduanya bertabrakan.

Event Nexus

Nexus mempertahankan event Scrum yang standar dan membungkusnya dengan versi lintas tim. Berikut cara kerja masing-masing menurut Nexus Guide.

Beberapa catatan praktis tentang bagaimana event ini berjalan:

Cross-Team Refinement adalah event yang paling terbayar. Jika tim-tim Anda baru menemukan di Sprint Planning bahwa Tim B membutuhkan perubahan skema dari Tim A, berarti refinement gagal. Perlakukan ini sebagai pekerjaan berkelanjutan, yang erat kaitannya dengan refinement backlog biasa tetapi dengan tugas khusus mendeteksi dan mengecilkan dependensi lintas tim.

Nexus Sprint Planning adalah saat perwakilan tim bertemu untuk memastikan urutan pekerjaan dan penugasan tim, lalu setiap tim menjalankan sprint planning normalnya pada bagiannya sendiri. Nexus Sprint Backlog yang dihasilkan adalah pandangan bersama atas semua yang sedang berjalan.

Nexus Daily Scrum diperuntukkan bagi perwakilan, bukan semua orang. Singkat, berfokus pada integrasi, dan keluarannya berupa penyesuaian pada Nexus Sprint Backlog dan rencana masing-masing tim.

Artifact Nexus

Nexus memakai artifact Scrum dan menambahkan beberapa versi bersama:

Panduannya memakai istilah "Nexus Goal" pada edisi-edisi awal dan mengubahnya menjadi Nexus Sprint Goal pada 2018, agar sesuai dengan penamaan Scrum. Jika Anda membaca tulisan blog lama, bersiaplah menemui istilah yang lama.

Nexus vs SAFe, LeSS, Scrum of Scrums, dan Disciplined Agile

Nexus berada di separuh ringan dari spektrum scaling. Berikut perbandingannya dengan opsi yang biasa ditimbang orang.

Dua perbandingan layak mendapat satu kalimat masing-masing. Dibanding SAFe, Nexus adalah komitmen yang lebih kecil: Anda tidak mengadopsi kadensi perencanaan untuk seluruh perusahaan, Anda menambahkan satu tim koordinasi pada tim-tim yang sudah berbagi satu produk. Dibanding LeSS, bedanya ada pada seberapa jauh Anda bersedia menata ulang organisasi. LeSS meminta tim fitur dan satu Product Owner dengan otoritas nyata atas semuanya, sedangkan Nexus mengasumsikan Anda sudah memiliki dasar-dasar itu dan butuh bantuan pada sambungan integrasi.

Scrum of Scrums adalah opsi paling ringan. Ini adalah rapat berkala tempat perwakilan tim berbagi dependensi, dan sering menjadi apa yang dilakukan tim sebelum mengadopsi sesuatu yang formal. Nexus dapat dibaca sebagai versi yang lebih terstruktur dari gagasan itu, dengan event, artifact, dan kelompok akuntabel di belakangnya.

Cara mulai menggunakan Nexus

Berikut urutan yang sesuai dengan cara tim biasanya mengadopsinya.

1. Pastikan prasyaratnya terpenuhi. Anda sebaiknya memiliki tiga tim atau lebih yang membangun satu produk, satu Product Owner, dan tim-tim yang sudah bisa menjalankan Sprint yang layak sendiri. Nexus tidak akan memperbaiki tim yang belum menjalankan Scrum.
2. Bentuk Nexus Integration Team. Tunjuk Product Owner, pilih seorang Scrum Master, dan pilih satu atau dua orang berpengalaman dari tim-tim sebagai Integration Team Member. Sepakati apa yang diharapkan dari mereka dalam kesepakatan kerja singkat.
3. Tulis satu Definition of Done bersama. Buat agar mencakup integrasi, bukan hanya penyelesaian di tingkat tim, sehingga "Done" berarti berfungsi bersama semua yang lain.
4. Mulai Cross-Team Refinement. Pilih slot rutin setiap minggu. Telusuri bagian atas backlog, tandai dependensi, dan potong item hingga sebagian besar dapat diselesaikan oleh satu tim.
5. Jalankan Nexus Sprint Planning. Pilih Nexus Sprint Goal, tugaskan item ke tim, dan susun Nexus Sprint Backlog dengan dependensi yang tersisa terlihat.
6. Pelihara papan dependensi. Gunakan template di bawah dan tinjau dalam Nexus Daily Scrum.
7. Adakan satu Nexus Sprint Review dan Retrospective. Tunjukkan satu Integrated Increment, bukan lima demo, dan perbaiki cara tim-tim bekerja bersama.
8. Inspeksi dan sesuaikan. Jika masalah integrasi terus muncul terlambat, perbaiki refinement lebih dulu, baru komposisi tim.

Template: papan dependensi lintas tim

Salin ini ke tracker Anda dan perbarui setiap hari. Inilah artifact yang paling sering diminta orang ketika memulai dengan Nexus.

Catatan kolom:

• Membutuhkan dari / Dibutuhkan oleh menjaga arah dependensi tetap eksplisit. Tanpanya, papan berubah menjadi daftar kekhawatiran.
• Dibutuhkan pada tanggal sebaiknya berupa hari Sprint, bukan "segera" yang samar. Inilah yang ditinjau dalam Nexus Daily Scrum.
• Status hanya butuh empat nilai: Belum dimulai, Sedang berjalan, Terhambat, Selesai.
• Risiko jika terlambat memberi Integration Team peringkat cepat untuk menentukan apa yang dikejar lebih dulu.

Kebiasaan yang baik adalah menghitung baris yang masih terbuka pada Nexus Sprint Planning dan lagi setelah Cross-Team Refinement. Jika jumlahnya tidak menurun dari Sprint ke Sprint, berarti refinement tidak menghilangkan dependensi dan struktur tim menjadi tersangka berikutnya.

Contoh berdasarkan fungsi

Nexus lahir dari dunia perangkat lunak, tetapi mekanismenya berlaku untuk produk apa pun yang dibuat oleh beberapa tim yang bekerja dalam Sprint.

Do's and don'ts

Kapan Nexus adalah pilihan yang salah

Nexus tidak cocok jika Anda memiliki kurang dari tiga tim, karena Scrum ditambah sinkronisasi ringan sudah cukup. Nexus juga tidak cocok jika Anda mengoordinasikan banyak produk yang tidak terkait, bukan satu produk, atau jika tim Anda belum berhasil menjalankan Scrum satu tim. Dan jika Anda membutuhkan pendanaan portofolio, perencanaan perusahaan, dan tata kelola yang berat, framework seperti SAFe mencakup wilayah yang lebih luas. Nexus membawa Anda dari tiga tim hingga sembilan. Nexus tidak berpura-pura menjadi model operasi untuk seluruh perusahaan.

Jika tim-tim Anda sudah menjalankan Scrum dan terus saling bertabrakan menjelang akhir Sprint, Nexus adalah perubahan kecil dengan risiko rendah: tunjuk Integration Team, mulai lakukan refinement untuk dependensi, dan tinjau satu Integrated Increment bersama. Mulailah dari sana, dan tambahkan struktur hanya ketika papan memberi tahu Anda bahwa itu perlu.