---

Bagaimana Memperluas Scrum untuk Proyek Besar dan Terdistribusi? Ini Mungkin Mengejutkan!

Scrum yang dijelaskan sejauh ini paling sesuai untuk satu tim di satu lokasi. Namun, satu tim sering tidak dapat melaksanakan seluruh proyek atau anggotanya harus tersebar di beberapa lokasi.

Jika kebutuhan produk melebihi kemampuan satu tim, organisasi dapat menambah tim. Persebaran geografis saja tidak menuntut penambahan, dan lebih banyak orang dapat meningkatkan biaya koordinasi. Kami juga sering melihat tim tersebar di lokasi atau benua berjauhan.

Alasan organisasi menyebarkan tim antara lain:

• Alasan Teknis: Pengetahuan membangun komponen tertentu tidak tersedia di kantor pusat,
• Alasan Keahlian: Kemampuan seperti otomatisasi pengujian, desain antarmuka, atau integrasi software internal dengan vendor lain mungkin memerlukan ahli di luar pusat,
• Alasan Ukuran: Proyek membutuhkan lebih banyak orang untuk tenggat tertentu, melebihi ukuran wajar satu tim. Solusinya beberapa tim kohesif, bukan satu tim yang diperbesar tanpa batas,
• Alasan Bisnis: Tenaga dari lokasi berbiaya rendah atau kesinambungan kerja melalui zona waktu berbeda dapat memberi alasan bisnis yang baik.

Karena komunikasi merupakan bagian inti Scrum, setiap anggota perlu mengatasi tantangan proyek terdistribusi. Semua anggota juga memerlukan alat komunikasi, termasuk konferensi audio/video dan berbagi layar.

Alat proyek umum mendukung komunikasi sehat dan berkelanjutan: Product Backlog, Sprint Backlog, daftar insiden, dan berbagi pengetahuan atau berita.

Organisasi Proyek: Beberapa Tim

Cara termudah memperluas Scrum dalam proyek besar ialah menambah tim di lokasi yang sama.

Jika beberapa tim perlu bekerja bersama, tambahkan jumlahnya secara bertahap.

Apa artinya bagi Anda?

Beberapa Tim di Satu Lokasi

Pertumbuhan bertahap lebih terkelola daripada membentuk sepuluh tim sekaligus. Mulai dengan satu tim. Setelah beberapa Sprint berhasil, tambahkan satu atau dua. Setelah memastikan beberapa tim ini (selengkapnya tentang Beberapa Scrum Team) bekerja baik bersama, terus tambahkan tim dalam organisasi terdistribusi Anda.

Menambah Jumlah Tim

Dua cara umum membentuk tim baru:

• Membagi tim yang ada menjadi beberapa tim dan menambah anggota bila diperlukan,
• Membentuk tim dari pengembang baru yang belum terlibat proyek.

Pembagian memanfaatkan anggota yang sudah berpengetahuan dan berpengalaman dalam proyek.

Tim baru biasanya langsung cukup produktif. Kekurangannya, tim lama yang berfungsi penuh kini terbelah dua, yang dapat memengaruhi motivasi. Terutama jika tanpa pemberitahuan dan penjelasan pimpinan serta kesiapan mental dan teknis anggota.

Dengan tim sepenuhnya baru, tim lama mempertahankan struktur dan Sprint. Koordinasi, orientasi, dan integrasi tetap diperhatikan. Namun, pembangunan pengetahuan serta momentum tim baru memerlukan lebih banyak waktu.

Apa pun cara menambah tim, ingat prinsip berikut:

• Mulai dengan sedikit Scrum Team,
• Tambah secara bertahap,
• Jaga kesinambungan kerja dan kelancaran penyerahan software serta nilai bisnis selama perubahan,
• Selesaikan masalah besar yang menghambat produktivitas dan kesinambungan sebelum memperluas jumlah tim.

Organisasi Proyek: Tim Terdistribusi

Kompleksitas utama muncul saat tim tersebar di berbagai lokasi: hambatan komunikasi, koordinasi pekerjaan, dan salah paham tentang norma proyek bersama hanyalah beberapa contohnya.

Beberapa Tim di Beberapa Lokasi

Mengabaikannya membawa konsekuensi serius.

Perusahaan membuang miliaran dolar anggaran TI akibat kurangnya kemampuan Kepemimpinan Organisasi dan Keahlian Scrum Berskala.

Empat saran penting untuk mengatasinya:

• Pastikan anggota baru dilatih dalam Scrum sebagai Scaled Scrum Expert,
• Perkenalkan proyek dengan baik agar mereka memahami tujuan teknis dan nilai bisnis serta dapat memutuskan cara meningkatkan kontribusinya,
• Tetapkan norma proyek tingkat lebih tinggi, seperti norma komunikasi, perencanaan, dan pelaksanaan satu tim, agar semua tim beroperasi, memecahkan masalah, dan menyerahkan nilai bersama.
• Pastikan anggota baru bekerja bersama yang berpengalaman, setidaknya sementara. Kunjungan lokasi dan pelatihan langsung wajar bahkan diinginkan. Pengetahuan berpindah lancar dan dialog pribadi dua arah terbentuk lintas tim serta lokasi.

Tim Virtual

Tim terdistribusi juga dapat beranggotakan orang dari beberapa lokasi. Ini disebut «Tim Virtual».

Tantangan utamanya komunikasi tanpa hambatan. Semua acara Scrum tetap dilakukan untuk koordinasi meski tidak semua berada dalam satu ruangan.

Tim Virtual

Anggota satu lokasi dapat berbagi ruang bila berguna, sambil memastikan partisipasi penuh anggota jauh. Tim lebih bergantung pada alat kolaborasi dan komunikasi. Mereka dapat mengikuti acara dari satu ruang dan menghubungkan anggota lain melalui video.

Tim Scrum Product Owner

Komunikasi rutin Product Owner dan Scrum Team sangat penting bagi penyerahan proyek berhasil.

Tim di lokasi berbeda membutuhkan akses efektif pada keputusan produk. Satu produk berbagi satu Product Owner, Product Goal, dan Product Backlog. Product Owner boleh mendelegasikan dukungan tetapi tetap bertanggung jawab; tidak perlu penanggung jawab Product Owner terpisah tiap tim.

Edisi ini menjelaskan «Scrum Product Owner Team» dan «Chief Scrum Product Owner» sebagai pola kolaborasi organisasi. Delegasi dan ahli produk boleh mendukung, tetapi gelar ini bukan akuntabilitas tambahan atau pengganti satu Product Owner penanggung jawab produk.

Dengan dukungan ini, Product Owner memastikan:

• Produk yang tepat dibuat untuk memenuhi permintaan pelanggan,
• Kolaborasi efektif bersama delegasi membantu tim menciptakan nilai bisnis dan teknis.

Product Owner tetap bertanggung jawab atas backlog efektif. Pekerjaan persyaratan pendukung dapat memakai kompetensi lain dan masukan pemangku kepentingan. Termasuk perwakilan kasus bisnis, pihak terkait, arsitek perusahaan, dan arsitek teknologi.

Tim satu produk bekerja dari satu backlog terurut menuju Product Goal bersama. Tiap tim menyerahkan sebagian cerita, tetapi cerita tertentu tetap memerlukan perhatian serta hasil beberapa tim.

Tim Komponen dibanding Tim Fitur

Pekerjaan dapat dibagi menurut tanggung jawab komponen atau fitur tertentu. Karena itu disebut «Tim Komponen» atau «Tim Fitur».

Tim Komponen

Setiap tim hanya mengimplementasikan komponen khusus dari keseluruhan sistem. Cerita biasanya dibagi menjadi bagian kecil untuk satu komponen. Dependensi antarkomponen membuat integrasi berkelanjutan wajib bagi penyerahan berhasil.

Tim Scrum Product Owner

Dependensi dapat menyulitkan fitur lengkap per Sprint. Kolaborasi dan integrasi tetap harus menghasilkan Increment terintegrasi, berguna, dan memenuhi Definition of Done bersama.

Ukuran batch dan waktu tunggu pekerjaan yang belum terintegrasi meningkat. Ini kurang baik karena target Scrum ialah increment siap diserahkan dalam batch kecil dan waktu singkat.

Keunggulannya, fokus dan keahlian detail arsitektur serta desain komponen lebih mudah dibangun. Ini sangat bermanfaat bagi komponen yang memerlukan penemuan dan inovasi.

Namun, anggota hanya menguasai komponen tertentu. Mereka dapat kehilangan gambaran besar dan alasan bisnis fitur.

Pelanggan membayar fitur untuk menjalankan bisnis, bukan komponen. Tanpa fokus fitur, optimalisasi menyeluruh dan integrasi memerlukan waktu tambahan. Keputusan yang mengoptimalkan satu komponen dapat menciptakan hambatan tak terlihat bagi keberhasilan serta kinerja solusi keseluruhan.

Tim Komponen

Tim Fitur

Tim fitur bertanggung jawab penuh atas implementasi cerita dalam Product Backlog. Tidak lagi dibagi menurut komponen, tiap tim menyerahkan fitur berfungsi penuh dan nilai bisnisnya.

Tim Fitur

Anggota lintas fungsi bertindak semandiri mungkin untuk penyerahan cepat. Pengetahuan sistem tetap terpelihara sehingga integrasi fitur dengan keseluruhan lebih mudah.

Namun, pengetahuan komponen cukup mungkin lebih sulit dibangun. Membentuk tim otonom yang cepat dan mandiri membutuhkan waktu karena tim interdisipliner tidak mudah terbentuk. Meski demikian, merekalah tim berkinerja tinggi yang menyelesaikan pekerjaan di banyak organisasi, mungkin termasuk Anda.

Bagaimana Memilih Tim Komponen atau Tim Fitur?

Dalam praktiknya, organisasi besar biasanya memakai Tim Komponen khusus sekaligus Tim Fitur.

Tim Komponen dan Tim Fitur

Tim C pada diagram adalah Tim Komponen yang menyediakan infrastruktur terencana maupun sesuai permintaan bagi Tim Fitur. Tim C tidak langsung mengimplementasikan cerita secara menyeluruh, melainkan kebutuhan cerita yang dikomitmenkan Tim Fitur.

Ini meminimalkan jumlah orang dalam Tim Fitur yang harus menguasai komponen tersebut.

Scrum Master dalam Lingkungan Proyek Terdistribusi

Dalam proyek terdistribusi, Scrum Master semakin penting karena:

• Diperlukan usaha tambahan untuk menyelaraskan nilai Scrum antartim,
• Norma atau standar tim dan proyek yang memengaruhi banyak tim lebih lama dibentuk,
• Dependensi antartim dan hasilnya bertambah sehingga hambatan lebih banyak.

Scrum Master harus mudah diakses dan efektif mendukung tim. Lokasi bersama dapat membantu tetapi bukan syarat Scrum; dukungan jarak jauh dimungkinkan. Pengaturan terdistribusi harus memungkinkan:

• Membantu menghilangkan hambatan kemajuan,
• Membantu menetapkan kesepakatan kerja efektif, dan
• Meningkatkan penggunaan kerangka Scrum.

Beberapa organisasi memakai Lead atau Primary Scrum Master untuk coaching dan koordinasi lintas tim. Ini pola opsional, bukan hierarki wajib atau pengganti akuntabilitas tiap Scrum Team.

Setiap Scrum Team tetap memiliki akuntabilitas Scrum Master serta membutuhkan dukungan untuk acara, pengelolaan mandiri, dan perbaikannya.