Area Fokus: Scaling Scrum

Kompetensi: Memahami dan Menjalankan Scrum

Photo by Adam Birkett on Unsplash

Nexus

Nexus adalah framework untuk scaling Scrum. Nexus, seperti Scrum, terdiri dari roles, events, artifacts, dan rules. Nexus dapat diterapkan untuk 3–9 Scrum Teams. Semua tim dalam Nexus bekerja terhadap satu Product Backlog, menghasilkan (satu) Increment yang terintegrasi, dan terutama mempunyai satu tujuan bersama (common goal).

Tujuan Nexus adalah menciptakan koneksi antar tim, dan terlebih menjaga kelangsungan bottom-up intelligence.

Fondasi dari Nexus adalah transparansi dan scaling dengan cara yang seseragam mungkin.

Nexus sebaiknya dijalankan jika sudah ada hasil positif dari 1–2 tim yang menjalankan Scrum.

Background

Saat bekerja dengan banyak tim, kendala utama yang dihadapi adalah ketergantungan (dependencies). Ketergantungan dapat terkait dengan:

• Requirements: Dapat terjadi scope overlap, juga urutan implementasinya dapat saling mempengaruhi.
• Domain Knowledge: Pengetahuan terkait bidang yang sedang dikerjakan, baik secara bisnis dan sistem, sering kali terbagi-bagi dalam beberapa tim.
• Software and test artifacts: Requirement akan terlihat pada software yang dihasilkan.

Framework Nexus lebih memperhatikan ketergantungan-ketergantungan ini dan juga pekerjaan antara beberapa Scrum Team.

Roles

Setiap Scrum Team akan memiliki Role sesuai dengan Scrum seperti biasanya. Ada tambahan role dalam Nexus, yaitu Nexus Integration Team (NIT). NIT terdiri dari PO yang dedicated, SM yang dapat berasal dari tim lainnya dalam Nexus, dan beberapa anggota representatif dari tim-tim dalam Nexus. Semua harus mengutamakan pekerjaan dari NIT.

Tugas utama dari tim ini adalah menentukan integrated “Done.”

Artifacts

Dalam satu Nexus hanya akan ada satu Product Backlog. Dalam Backlog Grooming, akan diputuskan backlog mana yang akan dikerjakan oleh tim mana.

Events

Event dalam Nexus ada yang ditambahkan, ada yang dibuat di sekitar, dan ada yang menggantikan event Scrum.

Proses

Refine the Product Backlog

Saat melakukan refinement, kita mengidentifikasi ketergantungan. Kemudian kita perlu memilah (slice) backlog yang ada. Akhirnya, kita menentukan tim mana yang paling tepat untuk mengerjakan masing-masing backlog. Tujuan utama dari proses ini adalah mengurangi atau bahkan tidak ada ketergantungan. Selain itu, menentukan urutan pengerjaan backlog yang ada.

Lebih lanjut mengenai cross-team refinement ini, 2 hal yang perlu dibicarakan adalah:

1. Tim mana yang akan mengerjakan pekerjaan apa
2. Bagaimana urutan pengerjaan yang terbaik jika diatur dalam Sprints dan kepada semua tim, di mana tercapai keseimbangan antara delivery of value dibandingkan dengan resiko dan kompleksitas?

Untuk melakukan refinement, secara garis besar dapat dilakukan dalam 2 langkah:

1. Pemecahan (decompose) dan pengurutan PBI
   Pemecahan dan pengurutan PBI dapat dilakukan dengan mempertimbangkan skills yang dimiliki oleh anggota tim-tim yang ada. Selain itu, yang paling mendasar adalah mempertimbangkan Sprint Goals yang ditentukan oleh NIT Product Owner.
2. Visualisasi dan pengelolaan ketergantungan
   Untuk ini, kita dapat terlebih dahulu mengkategorikan ketergantungan menjadi 3:

• Urutan pengembangan
• Orang dan keterampilan mereka
• Eksternal

Rob Maher dan Patricia Kong menjelaskan lebih detil tentang visualisasi ketergantungan dalam artikel ini.

Untuk membantu dalam meminimalisir dan menghilangkan resiko beberapa solusi yang dapat ditempuh:

• Pindahkan pekerjaan antar tim.
• Pindahkan anggota antar tim.
• Mengatur kembali pekerjaan tersebut. Untuk ini, Nexus dapat meng-explore solusi lain untuk men-deliver value.
• Strategi berbasis resiko. Ada Nexus yang mungkin akan menghilangkan atau menghindari ketergantungan pekerjaan dalam Sprint yang sama. Ada yang mungkin akan fokus menyelesaikan terlebih dahulu pekerjaan yang menjadi ketergantungan untuk banyak tim.

Proses refinement ini harus secara terus-menerus berjalan dengan tujuan untuk memiliki rencana untuk kira-kira 3 Sprint ke depan.

Nexus Sprint Planning

Event ini dihadiri oleh perwakilan dari tiap squad, dimana akan ditentukan Nexus Sprint Goals, lalu Nexus Sprint Backlog. Masing-masing perwakilan akan membawa backlogs yang sudah ditentukan dan goals yang terkait. Setelah itu, masing-masing Scrum Team akan melakukan Sprint Planning berdasarkan yang dibawa oleh perwakilannya, sehingga menghasilkan Team Sprint Goals dan Backlogs.

Pekerjaan Pengembangan (Development)

Untuk memastikan pekerjaan antar tim, semua Scrum Team harus sering (frequently) mengintegrasikan pekerjaan mereka dan melakukan tes. Perlu dipertimbangkan penggunaan source code management seperti Git beserta proses kerjanya.

Nexus Daily Scrum

Pekerjaan harian dimulai dengan Nexus Daily Scrum yang dihadiri perwakilan dari setiap tim yang akan membicarakan jika ada masalah integrasi. Pembicaraan ini akan dibawa saat Team Daily Scrum, sehingga tim terkait dapat merencanakan pekerjaan hari itu untuk memprioritaskan penyelesaian masalah integrasi dulu.

Nexus Sprint Review

Event ini menggantikan event Scrum biasanya, artinya masing-masing tim tidak akan mengadakan Sprint Review, melainkan semua tim akan bergabung untuk mengadakan Nexus Sprint Review. Dalam event ini, semua tim akan bertemu dengan stakeholders dan melakukan review terhadap Integrated Increment.

Masalah yang sering dihadapi saat Sprint Review, terutama yang lebih besar seperti Nexus Sprint Review, antara lain:

• Sprint Review hanya menjadi Demo, yang artinya hanya satu arah. Demo boleh saja dilakukan dalam Sprint Review, tapi harus dijaga untuk tetap terjadi komunikasi dua arah, yaitu dengan feedback dari stakeholder yang hadir.
• Stakeholder yang hadir terlalu banyak.
• Para developer tidak lagi menghadiri.

3 ide untuk dicoba agar menghindari masalah di atas:

1. Selenggarakan demo bulanan selain Sprint Review dua mingguan
   Demo diharapkan lebih membawa alignment, sedangkan Sprint Review diharapkan menjadi wadah mendapatkan feedback.
2. Selenggarakan Sprint Review yang terpisah untuk “lingkaran kecil” dan “lingkaran besar”
   Lingkaran kecil adalah mereka yang akan berkomunikasi harian, dan juga seperti biasanya pada Sprint Review. Lingkaran besar dapat diselenggarakan 6 minggu sekali (3 Sprint) dengan mengundang stakeholders yang lebih luas.
3. Jalankan review secara berkesinambungan, di luar Sprint Review
   Lakukan “as soon as done” review untuk mendapatkan persetujuan dan feedback yang detil. Sprint Review tetap dilakukan, yang diharapkan bukan hanya feedback, namun jika ada concern lain dari stakeholder yang lebih luas, untuk visibility, dan mengkonfirmasi ulang roadmap berdasarkan kemajuan software yang bekerja dengan baik.

Nexus Sprint Retrospective

Retro dimulai dengan Nexus Sprint Retrospective, di mana perwakilan dari masing-masing tim akan membicarakan tantangan yang dihadapi. Lalu, masing-masing tim akan melakukan Sprint Retrospective. Akhirnya, para wakil tim akan berkumpul kembali untuk membicarakan tindakan yang perlu dilakukan terhadap tantangan bersama sebagai bentuk bottom-up intelligence.

Karena berbeda dengan biasanya, dalam Nexus Sprint Retrospective perlu dibicarakan hal-hal berikut:

• Apakah ada pekerjaan yang tidak diselesaikan? Apakah Nexus menghasilkan technical debt?
• Apakah untuk semua artifact, terutama code, sering diintegrasikan dengan sukses?
• Apakah software cukup sering di-build, tes, dan deploy dengan sukses untuk menghindari penumpukan ketergantungan tidak terselesaikan yang berlebihan?

Untuk pertanyaan-pertanyaan di atas, jawab juga jika perlu:

• Mengapa ini terjadi?
• Bagaimana memperbaiki tech debt ini?
• Bagaimana supaya hal ini tidak terjadi lagi, tidak berulang?

First things first

Scrum mudah untuk dipelajari, namum sulit untuk dikuasai. Dengan memperhatikan ini, saat kita merencanakan scaling kita perlu menanyakan:

• Apa bisa kita perbaiki saja cara kita bekerja sekarang? Sehingga kita tidak perlu scale.
• Berapa tim yang sebenarnya kita butuhkan? Mengapa?
• Bagaimana kita akan membagi misi dari masing-masing tim?
• Apakah kita akan memerlukan 3 atau lebih tim?

Dengan lebih banyak orang, akan lebih mempersulit koordinasi, workflow, dan kolaborasi. Menambahkan jumlah tim terlebih meningkatkan kompleksitas.

Nexus+

Nexus+ adalah jika kita mempunyai lebih dari 1 Nexus, yang artinya kita punya lebih dari 9 Scrum Team yang bekerja membangun produk yang besar. Dalam skala ini, suatu organisasi sudah harus dapat mengimplementasikan praktek-praktek yang sesuai dengan kondisi dan kebutuhannya, serta sudah memiliki panduan untuk mendapatkan feedback dengan cepat.

Self-Selection di Net Health

Dalam video ini, kita dapat mendengar pengalaman dari perusahaan Net Health dalam menerapkan Nexus dengan proses self-selection, yaitu orang-orang memilih sendiri akan menjadi bagian dari tim mana.

Exercise ini menunjukkan self-organization yang tinggi yang didukung oleh perusahaan tersebut dalam persiapan menjalankan Nexus.

Scaling Scrum by Angga Pratama

Slide Presentasi: http://bit.ly/2TGeIPM

Sebelum menjalankan scaling Scrum, inspeksi. Apakah kita sudah menjalankan Scrum dengan baik? Karena dalam banyak situasi, alasan mengapa kita mau scaling, sebenarnya dapat diperbaiki dengan menjalankan Scrum dengan lebih baik.

Scaling Scrum hanyalah Scrum. Berikut beberapa prinsip saat melakukan scaling Scrum:

1. Scaling dengan mempertimbangkan simplicity
   Jika tim sudah terlalu besar, maka kompleksitas sangat tinggi. Sehingga perlu dilakukan scaling untuk menyederhanakan cara kerja.
2. Hanya satu Product Backlog
3. Maksimalkan nilai produk
   Hanya satu Product Backlog untuk memaksimalkan nilai yang ingin kita deliver. Satu misi untuk semua tim.
4. Beberapa Scrum Team bekerja bersama berbasis produk
   Gantinya bekerja dengan project-mindset, semua tim harus memiliki product-mindset.
5. Sprint Release dalam suatu produk yang terintegrasi
   Hasil dari masing-masing tim harus diintegrasikan, dites, dan akhirnya di-release sebagai suatu kesatuan.
6. Sprint Review mendemonstrasikan keseluruhan produk
   Dalam Sprint Review yang di-review adalah keseluruhan produk, bukan lagi sebagian yang menjadi hasil masing-masing tim.
7. Scale up to scale down

Salah satu contoh scaling dapat dilihat dalam model Spotify. Spotify model terdiri dari squad yang otonom, tribes yang menyatukan visi banyak squad, chapter dan guild yang meningkatkan komunikasi, Scrum in Scrums sesuai kebutuhan, arsitektur yang mendukung, dan System Owner yang memiliki (own) sistem yang membentuk arsitektur yang digunakan squads.

Selain Spotify model, ada framework scaling lainnya seperti SAFe, LeSS, dan Nexus.

Framework manapun bukanlah jawaban dari semua masalah, utamakan mengembangkan kultur kerja yang baik. No silver bullet for scaling your scrum.

Kesimpulan. Nexus adalah framework untuk scaling Scrum yang dapat digunakan untuk 3–9 Scrum Teams. Roles, events, artifacts, dan rules disesuaikan untuk skala yang lebih besar. Hal yang penting sebelum memutuskan melakukan scaling antara lain adalah apakah bisa kita perbaiki saja cara kita bekerja untuk lebih baik mencapai nilai yang diperlukan, tanpa scaling.

Slide Presentasi: https://speakerdeck.com/alternat0/scaling-scrum

Credits:

• Translated to Indonesian based on Scrum Master Learning Path, Understanding and Applying Scrum competency, Scaling Scrum focus area by scrum.org
• Some explanation based on discussion with Joshua Partogi
• A section based on a talk by Angga Pratama